On Tue, 15 Feb 2005 11:37:18 -0500, Stefano Mazzocchi <[EMAIL PROTECTED]> 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 effort. 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. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
