cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <>
Subject Re: Where is Cocoon 3 going to?
Date Wed, 26 Nov 2008 22:04:13 GMT
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
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
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
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.
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
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
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
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)
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
execute actions that are meant to check whether your code follows the behaviour you intended
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
a language that is immune to most of simple bugs in code we make because it simply does not
at level were this bugs are made?

I happen to attend lectures on mathematical logic and subject called "Languages, Automata
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
languages can be powerful enough to express your needs so precisely that unit testing and
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

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

> 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
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
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
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

View raw message