Simone Gianni pisze: > Hi Grzergorz, > I've been reading of this thing of "write the same stuff using just a > few lines, not like in java" all over in the last two years, and I > tested it out using a large number of these languages, from Python to > Ruby to Scala, and I can assure you that it is mostly FALSE.
I don't know Python enough to formulate any strong claims but it looks to me that Python, Ruby and Scala does not have feature "lazy evaluation". I consider this feature as one the most important if IMHO if you try a language without it then you are playing with not a pure (fully) functional languages. This leads to different conclusions and experience, obviously. Actually, the whole claim about the number of lines of code was more to spur a discussion than a real argument. I'm sure that everyone would stop reading my mail as soon as I would start talking about how mathematical models can be very easily expressed in functional languages or how we can easily _reason_ on functional statements. This all results in better code but I didn't wanted to write an e-mail full of details that nobody would read. > On one side, surely Java IS a verbose language, and surely there can be > more concise ones, but the entire idea of line counting is an error. I > can pretty well write Xalan in a single line of Java code, it's just a > matter of executing s/\n// on the whole source code :) :) Have a look at the code of that processor, it's readable, really. > In fact : > - Many tools out there (CLOC just to mention one) consider also the > closing bracket a line of code, while obviously it is not. > - Using chaining (like A.b().c().d().e().f()) will reduce 5 "lines of > code" to one, but in reality you are always writing 5 calls .. same > amount of headache and possible bugs, or even more cause your code is > less readable. Of course, you can play tricks or you can have sexy syntax so you get less lines of code. However, can you think of a syntax that is readable and compresses your code by factor of 100? What I wanted to say using argument of LoC is that it looks like functional languages lets you to express the essential idea leaving out the details. Functional languages operate on a different level of abstraction. This is something different than having 5 methods calls in one line or declaring or not getters and setters for a object's field for example. > Also considering a better metric, like the number of join points or > branches or whatever else, there are a number of reasons why these > claims are at least exaggerated : > - Many of these languages have huge libraries, with hundreds of methods > that accomplish most tasks that would require you to write lines of code > in java. This is not a bad thing in itself, but to make an appropriate > count of lines of code you should put all these stuff in a separate > library (commons is there for this reason), and see how many "lines of > code" are present in your CORE code. If there is a core library that can be useful for every application and reduces size of your code so much then it only proves the power of expressiveness of the language in which such a library has been implemented. > - Most of these libraries are not customizable in any way, they do work > perfectly 90% of times which is good, but you will end up having to > re-implement part of these. Java went the opposite way : the bare > minimum on the common library, no facades except where really really > useful, which will require a lot of code from the programmer. None of > the two is the perfect way, both have drawbacks. I have lesser practical experience with libraries from functional languages but up to know I have seen only extremely generic libraries in Haskell. They are so generic that you cannot compare then to Java mainly because they are just higher-order functions. > - Many of these libraries are tiny in number of lines because they are > also tiny in functionalities. For example : > ... They don't implement what they claim to completely, or implement an > early version of it, partially and in a buggy way. > ... Have not gone thru the pain of adding all the features users will > ask you to add, which can make a simple one-man-show library grow up to > thousands of hundreds of lines in a few years. > ... Have not gone thru any test or bugfixing, and bugfixing WILL > ENORMOUSLY increase the "size" of code (and also make it a mess). I wholeheartedly disagree with the last statement. I've written lots of code in Java which has been buggy and you can easily point your finger at the very specific line of code where the particular bug has been made and this way prove that it was entirely my fault. I don't want to dismiss that simple fact but I do bring into question if it's not a tool (Java) that makes it too easy for me to make simple bugs. These days it's rather common saying that if you write a big application in Java you have to cover it with both test-cases and integration tests in order to avoid obscure bugs and long debugging sessions. I was the one saying the same, actually. However, I started to realize that this approach seems to be broken to some extent. In test-case you execute actions that are meant to check whether your code follows the behaviour you intended to describe in original code. What about a language that is precise and abstract enough that lets you describe what it should really do (read what you really mean) instead of what kind of actions it should perform? What about a language that is immune to most of simple bugs in code we make because it simply does not operate at level were this bugs are made? I happen to attend lectures on mathematical logic and subject called "Languages, Automata and Computations" which give me lots of insights into the subject we are discussing. Even if my understanding of the subject is at introductory level I've got more and more reasons to think that languages can be powerful enough to express your needs so precisely that unit testing and similar surrogates are not needed in most situations. This is only heuristic claim based on some theorems I've learned, though. > ... Usually does not have all the fluff around the basic core, like > utilities, error messages, handling of special cases or exceptions, and > so on ... that will also make your code multiply in size. Actually the XSLT processor follows specification when it comes to error reporting. Anyway, you are right that in general all boring details make our code bigger but still not 100 times bigger or so... > Obviously, there are languages which are easier than Java, more concise, > more performant and all the rest, functional approach is easier than > passing Runnables, there are no doubt about the fact that our industry > is young and there is huge space for new technologies, and probably > Cocoon would greatly benefit from some of them. Yep, that's my whole idea. This community used to be very innovate (maybe not so good at marketing but we all know that already) and I would like to put at least some parts of Cocoon at bleeding edge again. Neither I'm a salesman trying to sell you a hype nor I feel like a chosen one to change a world of programming. I simply believe that Cocoon community would benefit from a little bit of functional programming. > But take these revolutionary claims for what they are : propaganda, not > necessarily real facts, or at least not THAT MUCH as they try to > demonstrate. Actually, as I've already said I've cited such claims to spur a discussion and I have more deep insights into whole subject. Anyway, we both understand that nobody here wants to listen to a _very_ abstract talk on language theory that would support my current interests and the whole excitement about them. Moreover, I take into account that I might be simply wrong and there is no added value coming with functional languages. However, we'll never know until we experiment with some real world application. Cocoon's reimplementation looks like a perfect chance and here I simply ask if others are interested in experimenting. PS. Thanks for your comments Simone. It's been a long time since we talked last time! -- Best regards, Grzegorz Kossakowski
