cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Anderson <benanderson...@gmail.com>
Subject Re: where is the box?
Date Sat, 10 Dec 2005 14:08:05 GMT
So I guess the best of both worlds would be jruby.  I'm not real sure
where this project is at, but I know it's been getting at least some
lovin.

On 12/6/05, Irv Salisbury <irv.salisbury@gmail.com> wrote:
> 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.
>
>  Irv
>
>
> On 12/6/05, Tim Larson <tim@keow.org> 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
> >
>
>

Mime
View raw message