cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] How scripting made me hate java
Date Tue, 15 Feb 2005 22:35:41 GMT
On Tue, 15 Feb 2005 11:37:18 -0500, Stefano Mazzocchi
<> wrote:

> Obviously, it doesn't.... the stacktrace is a million lines long... most
> of this code I don't recognize anymore, it's like looking at somebody
> else's project now and it's big and massive. And the logs were all
> fragmented (I fixed that :-)
> So, all right, fix the code in eclipse, change to the terminal, run ant,
> hit cocoon-reload (twice! that stupid ehcache thing in the way), say
> "thanks sylvain" ten times (instead of a thousand, that's why you say
> that ;-), another stacktrace... go back to square one. One modification
> per minute... and I'm used to one modification every 5/10 seconds in
> debug mode.

Here I have to agree with Ugo. Unit testing can make a change: since I
started committing myself to write code which can be tested in
isolation, the number of try/fail cycles has happily decreased. But
this is like watching the finger pointing to the moon: yes, there is a
clear issue in the (overly?) complex architecture of Cocoon. My day
job is basically promoting Cocoon around, and I'm really used  to the
"Cocoon is a scary beast" meme: I have developed techniques and tricks
to prove the opposite, but I can clearly see how there is a problem
and why Cocoon is perceived as a scary beast and/or an academic

However, I'm also strongly convinced that Cocoon is the most
impressive incarnation of rapid development and try/fail cycle when it
comes to webapps:  there is nothing like Cocoon which allows to
develop really complex stuff without even touching Java. Of course
there is a price for that: whenever you have to go under the hood, you
find an incredible amount of complexity that tends to scare the
average developer away.

> Scripting taught me (spoiled me?) with incredible high productivity but
> I think there is a problem when people are not able to go back and fix
> the underlying object model that the scripting is a glue for... because
> it forces people to hack things in their glue layer, which reduces reuse
> and *prevents* contributions to get back in the system!!!

It's the good old balance, and the hardest line to draw ever:
personally I still belong to the party of those who think that the
power of a framework is in the amount of guidance that it gives you
and in the mistakes it avoids, rather than in the flexibility it
allows. I'm not sure I'm technically willing to trade flexibility for
protection, but with my community hat on I can see your point. The
Cocoon community is alive and kicking, but it resembles more and more
a closed circle: Daniel's figures sure made me wonder.

 > I'm in *desperate* need to reduce that try/fail cycle in cocoon or I
> simply won't be able to touch its code anymore. Which is very
> frustrating, given the amount of things I could get done if I only could
> go back to it.

Believe me, 95% of the time the try/fail cycle in Cocoon is the
shortest ever, since you don't touch a single line of Java code.
Dynamic compilation might fill the remaining space, helping people
getting back to Java, but are we really sure this is what we need when
the real blocker is the frightening learning curve whenever you have
to go past a simple sitemap component?
The Cocoon core is clearly at risk of collapsing because of its
complexity: unfortunately the only solution I can foresee is the clean
slate one, AKA Cocoon 3.0. And even then, I don't really think it will
be that easy to build an understandeable machinery: we are doing
complex stuff, and it's impressive the amount of complexity we managed
to hide to the user. I'm not sure that things like environment
handling, context switching, continuations machinery and sitemap
interpretation can be more accessible than they are now.

Not only that: my gut feeling is that even other frameworks (Struts,
Tapestry) have a complex inside machinery: their advantage is that the
perceived complexity is much lower and the user doesn't ever need to
fire a Java IDE. I think that's the case for Cocoon as well, but this
is not the common perception.

So, in the end, I see two main issues compromising the future of
Cocoon: entry barrier for new users and learning curve for core
developers. How to solve both? Well, for users it all boils down to
usability improvements, clear guidance and toolsets: for one, the
configuration system as it stands now is a sore pain. What seemed to
be a good thing (using the role shorthand as the main configuration
element) ended up in a real mess of undocumentable, unvalidatable and
un"tooleable" XML blob: <component-instance> all over the place could
have been less readable, but in the long run it could have been much
more manageable. And if you think about it, this is FS biting us hard:
a more rigid configuration system could have brought us a set of tools
to manage our needingly complex configuration system.

Developers are different. There is no way on earth you can turn
sky-high challenges into blatantly simple code, but at a very least
you can make it interesting. The Cocoon core isn't sexy anymore:
people wants easy isolation development, testing tools, up-to-date IoC
techniques and, most of all,  they don't want to have to learn a ton
of non-standard technologies just to itch their own scratch. The clean
slate, if ever going to happen, should take all that (and possibly
more) into account. As you can see, I sincerely believe that the java
try/fail cycle is really just a small corner of the overall picture.
But yes, we have a problem.
Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance:
(blogging at

View raw message