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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > >
