cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] How scripting made me hate java
Date Tue, 15 Feb 2005 23:32:46 GMT
Gianugo Rabellino wrote:
> 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:

I took one generator, merged it with another, and updated the library 
that they used (because I needed a new feature) and now it throws 

'unit' testing is about testing units, isolated functional pieces that 
can be considered passive and tested independently.

Cocoon's internals are *far* from being that kind of unit. You can't 
test a single method of a SAX content handler, that gives you nothing!

You can test the input and output of a pipeline, but this is exactly 
what I do with my browser when I hit it! Sure I can automate that when 
it's ready to know what is broken or not later on, but it's not unit 
testing, is functional testing... and helps when you are doing 
modifications, but doesn't help at all when you are implementing new 
features (or merging different existing ones).

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

It *is* scary. The library dependency chain is 28 levels deep! There are 
more levels dependencies in cocoon than in a 747 airplane! It took gump 
3 years to compile it a single time out of fresh CVS! Some of its 
dependencies are gone, the sourcecode not even tagged in the code 
repository (stupid excalibur doesn't tag the component releases!), the 
javadocs scattered allover, there are libraries in our lib directory 
that *nobody* knows what they are used for (the pizza compiler, for 
example) and there are no more than 4 people that ever touched the core 
in the last 18 months.

Wake up people, the sum of all this is dangerous.

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

This is fine. I don't mind that. What bothers me is that it's not cocoon 
that scares me away, it's the development model induced by it: so simple 
and rapid on top, so complex and irritating inside.

This gap might prevent us from aquiring new talents, since they will all 
remain at the scripting level, patching there instead of inside.

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

People keep talking about documentation.... but let's get real: we know 
that the code is the place to look, you can 'control-click' in eclipse 
on a method and see what it does, you don't need documentation if you 
are a cocoon committer to stop being afraid.

The documentation will never be good enough... but the code can be 
improved too!

>  > 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.
> Ciao,


View raw message