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:48:48 GMT
Damn, hit send too soon :-)

Stefano Mazzocchi wrote:

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

I agree.

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

No, and I don't care.

This is *NOT* what I'm trying to solve. I don't care if users user java 
or not, what I care is that cocoon committers are not afraid of the core 
or that they are not adding java components to the system because 
writing them in javascript is faster and easier (been there, done that).

I want to make it easier to go back into hacking cocoon itself, because 
innovation is happen on the outside and I think this is dangerous in the 
long run to the solidity of the internals.

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

No, no way. Not the 2.0 syndrome over again.

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

For one thing, they don't depend on 218 libraries :-/ which also means 
they are way less powerful.. but power comes with a price.

Here blocks will help tremendously.... yet we need to 'aggregate' the 
source code + javadocs in one place because our own internals are 
scattered around many projects, some of which dead and some of which 

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

Agreed, but honestly I'm not concerned about users... because that's 
what everybody is concerned about... and where the money is, so things 
will improve.

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

The cocoon core isn't sexy and its million-lines-long stacktraces don't 
help at all.

Also, having dependencies on a million little jars, api and impl, each 
with 3 classes each is stupid, brain damaged, a thing of the past, the 
ultimate overdesign and abstraction masturbation.... and the are no docs 
about those, no javadocs, no browsable source code with the right 
version number.

It's ridicoulous.

But starting over is creating more problems than it solves.

I have an itch to scratch: I want to be able to work on and in cocoon, 
in java, with the simplicity and productivity of a scripting language.

This requires me to have all the dependent source code + javadocs 
available at my (eclipse-powered) fingertips, or I won't be able to do it.

This also requires me to have 'development' strategies: where to place 
my code, how to reload fast, how to inject changes at debug time using 
hot code (thanks Vadim, but for some reasons it doesn't work on a mac 
:-( still investigating), how to make eclipse compiled classes be picked 
up by the cocoon classloader, how to deploy remove my blocks, my code 
and my libraries... and so on.

No classloading isolation, no hot deployment, no transparent proxying of 
polymorphic aspects, nothing fancy: just more flexibility and a well 
designed (and documented) development workflow for committers, that 
users can use to become more 'powerful' users (would their need emerge).

And we'll see people going back to code in there... and hopefully the 
dust will be removed a little bit at a time, just like Carsten and 
Sylvain are already doing.


View raw message