cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Irv Salisbury <>
Subject Re: where is the box?
Date Tue, 06 Dec 2005 13:57:48 GMT
What I write here is just one vote, but maybe others think the same.

For all of our enterprise projects we have done in Cocoon, if it hadn't been
Java, we wouldn't have been allowed to use it.  Our customers understand
Java and it is currently equated with enterprise.

Now, it is difficult enough to get enterprise customers to even allow Cocoon
as it is something they haven't heard of.  To me, adding in the fact that it
isn't written in Java only makes this worse.

I realize at one point in time Java suffered from this as well, as do all
new programming languages.  Just wanted to throw this out there.  It
certainly doesn't mean Ruby, or Python, or whatever won't be the next Java.

I can say that when connecting to other enterprise messaging systems, EAI,
etc, there are lots of mature Java solutions we have made use of from within
cocoon.  With our applications in cocoon, having the components in Java
allowed us to write custom transformers that used these third party apis.
For me, it was Java that is the strength of cocoon, not its weakness.


On 12/6/05, Tim Larson <> wrote:
> I have been sitting back listening to the cocoon evolution/revolution
> discussion, while happily coding with something else...
> The development of open source is dominated by emergent properties,
> which like their counterparts in chemistry and physics are not
> greatly affected by many types of environmental changes and are
> difficult or impossible to predict from base causes.  The trick is
> to recognize that you are dealing with emergent properties and not
> a set of well-behaved laws, and then to deal with the patterns that
> present themselves.
> Where is the recent bottleneck in Cocoon?  Is it the number of
> languages, the complexity of the core, the multi-step development
> process, the inability to use a common debugger across it all, the
> lack of a full test suit, incomplete or out of date documentation...
> ...or is there something more basic that is strongly contributing
> to all of these issues?
> Since we are taking a moment to "think outside the box," perhaps
> we should pause to figure out where the box is and of what it is
> made.  When Cocoon was started there were not many viable choices
> for cross-platform programming languages, so Java had much going
> in its favor.  Now the situation has changed.  Cross-platform
> scripting languages have become common.  Java is a fairly static
> and verbose language compared with these new offerings...and much
> of the work in Cocoon lately seems to be in trying to work around
> this.  Java has become the box.
> People moving to Rails hardly seem to notice the language change
> that comes with it.  Is that because of the Rails hype (which
> wears off quickly) or because the language stays out of the way?
> Tutorials teach you the framework first, and let you pick up the
> language along the way because it is so easy.
> With Cocoon we are already dealing with a variety of languages,
> Java, Javascript, numerous XML dialects, and a sprinkling of
> Scheme to name a few.  Perhaps Cocoon is ready to spawn a new
> breed with a Ruby core, where the language is succinct and more
> friendly to more dynamic code.  Domain languages become possible
> without sacrificing a common syntax, debugger, and test suit.
> Pause and think about how the choice of a base language affects
> the development of a project...the more words and steps it takes
> to write code, the harder it gets to write, modify, document,
> and decipher the project.  There are many ways to work around a
> verbose and predominately static language to make it seem more
> concise and dynamic, but each step taken in this effort diverges
> you further from common knowledge of the base language and
> complicates the core of the project...every line of code reflects
> the design decisions of the language used, until the project
> implodes.
> Let's find a new box, that is bigger and will fit all of our
> toys (we want to bring them with us, right?)  There are a lot
> of great ideas in Cocoon, but I have come to the conclusion
> that Java has become to constricting to effectively develop
> them much further in a timely manner.  I suggest we seriously
> consider Ruby as that larger, less constricting box.
> --Tim Larson

View raw message