cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: Where is Cocoon 3 going to?
Date Wed, 26 Nov 2008 13:48:49 GMT
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.

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

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.

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

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.

But take these revolutionary claims for what they are : propaganda, not
necessarily real facts, or at least not THAT MUCH as they try to

Just my 2 cents.


Grzegorz Kossakowski wrote:
> Reinhard Pötz pisze:
>> Grzegorz Kossakowski wrote:
>>> Cocoon 3.0 started by Reinhard looked promising to me but now I
>>> realize that the main idea of its existence is to more or less
>>> rewrite C2.2 and add some RESTful features.
>> Yes, that's explained by the first paragraph of the Cocoon 3 website.
> Ahhh right, I've looked at source code of C3 but forgot about the website. Apparently,
I have to
> check recent developments of C3.
>> You probably have missed it but with Simone we actually have one very
>> active committer and I know that many other people are fond of the
>> Cocoon 3 pipeline module.
> Yes, sort of.
>> Currently the main problem is that most developers don't know that there
>> is such a simple thing as the Cocoon 3 pipeline library. I've already
>> started to provide documentation but haven't got very far yet. But be
>> assured that it has a very high priority on my opensource todo list.
> Good to hear that. Some advertising company on e.g. Pipeline library that would show
us it's
> potential would be useful but it might be that I ask for way too much. ;-)
>>> Has anyone here thoughts on this topic or it's only me who has a
>>> problem?
>> When I started Cocoon 3 my main goal was to solve two problems: 1)
>> provide a plain and simple pipeline API that is easily usable from
>> within any Java environment 2) make Cocoon a simple platform for RESTful
>> services.
>> This made *me* excited about it and solves *my* problems. I haven't done
>> any market research about what would have excited others.
> It would be very nice if you could provide some more details how it solved your problems
and what
> kind of problems. I suspect that you have lots of ideas how this thing should evolve
and what kind
> of new opportunities it brings to us.
> I would really like to help you with building up the community but before I can start
doing that I
> need a solid background, a vision so I can guide others. That's why I'm asking for all
of that all
> of the time.
>> Anyway, I don't think that it makes much sense to talk about what an
>> anonymous mass of people might want. So Grzegorz and all others reading
>> this, what would make *you* excited about Cocoon 3 so that *you* would
>> be willing to contribute?
> Actually, I find myself at the crossroads now. I haven't done anything really pleasant
that would
> make me happy with C2.2. The COCOON-2216 issues almost killed my whole motivation when
it comes to
> C2.2. I feel like the time I can hack C2.2's core is over for me. Until someone helps
me with this I
> will probably stay away of C2.2 completely because this issue blocks most of my plans
when it comes
> to C2.2.
> That's a reason for me to look for something new.
> SSF should get some attention so SAX forwarding is implement and some caching bugs are
> Anyway, I would like to leave this task for someone else as it's a bad situation that
it looks like
> only me and you have an idea what's going on there. I want someone else to become involved.
> So the only thing left is C3. What would make me excited? The best thing would be to
rewrite C3 in
> some pure functional language like Haskell. ;-)
> Ok, that's a joke but an introduction to something more serious. I've been off-line a
while which
> was a perfect chance to read some books and papers. Let's start with a quote from a master
> "Implementing an XSLT processor for the Haskell XML Toolbox" by Tim Walkenhorst[1]:
> "The processor is written in a purely in Haskell 98 and does not make use of any advanced
> libraries. [...] It might be possible to make the implementation even shorter and more
concise by
> using this features; however, the basic implementation should enable interested volunteers
> to gain familiarity with the code rather quickly. The entire implementation has about
> lines of code and is thereby 192 times smaller than the XALAN Java implementation which
> has about 347000 lines of code.[...]
> Of course, we could not implement the full functionality of
> such a huge tool within one master thesis; however, it should be possible to perform
> most common kinds of stylesheet transformations within the subset of XSLT we
> implemented."
> You read it correctly. The XSLT processor implemented with 1800 lines of Haskell vs 347000
lines of
> Java. I've checked features and parts of specification that are not implemented and I
found that
> they don't form a big portion of the whole specification and seemed to be rather trivial
> Of course, this processor does not additional features of Xalan like support for debugging,
> Anyway, can you think of almost complete implementation of XSLT 1.0 spec. in 2000 lines
of Java? I
> cannot.
> Even more surprising, I can moderately easily read that code even if I'm not fluent in
Haskell. I
> guess I'm not the only one realizing that a reason for such a phenomenon must be something
more than
> just a fancy syntax.
>                                  --------------  o0o  --------------
> Of course, proposing to reimplement something like Cocoon would be just a joke because
there is only
> a little industry support for Haskell and Apache is definitively industry-oriented. However,
> is a compromise solution called Scala[2]. The main advantage (and disadvantage at the
same time) of
> Scala that it's been designed from scratch to play well with Java but at the same time
> functional programing features and ideas.
> It's looks to me that in C3 the idea of using scripting language for flow/controller
has been
> abandoned. I've never been a great supporter of scripting languages with weak typing
> Javascript. At the same time, I can understand those people that see scripting languages
> Obviously, there are some constructs that are awkward and verbose (thus overly complicated)
in Java
> and much simpler counterpart in some scripting language. On the other hand, lack of refactoring
> need for extensive unit-testing for every little-stupid-thing is a major problem with
> languages. A nice paragraph[3] on that can be found in "Real World Haskell" that has
just hit the
> shelves and additionally is available for free online.
> Anyway, there is a third option provided by functional languages which *are* strongly
typed (at
> least those that I'm aware of) but at the same time provide flexibility found in scripting
> languages. Therefore I would like to work on integrating Scala into Cocoon.
> This idea is rather fresh and I'm only starting with Scala but idea would be to implement
two parts
> of Cocoon in Scala:
> 1. Sitemap (or something corresponding)
> 2. Controllers
> I guess this e-mail is already long enough to cut it here. If you are interested in my
ideas on
> providing functional implementation of sitemap (that would be inspired by some characteristics
> bash) I could write a little bit more on it with some details.
> If there is no interest in such subject and I do not find any other interesting thing
to do I'll
> probably start a fork of C3 at GitHub so it won't interfere with your work here.
> Having pipelines as capable higher-order functions seems to be a neat idea...
> [1]
> [2]
> [3]
> [4]

Simone Gianni            CEO Semeru s.r.l.           Apache Committer

View raw message