Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 36749 invoked from network); 6 Dec 2005 13:58:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Dec 2005 13:58:14 -0000 Received: (qmail 45670 invoked by uid 500); 6 Dec 2005 13:58:10 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 45585 invoked by uid 500); 6 Dec 2005 13:58:10 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 45571 invoked by uid 99); 6 Dec 2005 13:58:10 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Dec 2005 05:58:10 -0800 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of irv.salisbury@gmail.com designates 66.249.82.207 as permitted sender) Received: from [66.249.82.207] (HELO xproxy.gmail.com) (66.249.82.207) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Dec 2005 05:58:09 -0800 Received: by xproxy.gmail.com with SMTP id s18so37440wxc for ; Tue, 06 Dec 2005 05:57:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=XTN44XJP0RX9BPDm+OKkafvsYQUR4sqJmPHHEVAp8ZJEUCvqElab3xFUHgolr1lMq8wyxlBHr90ubrHM7T5L3sqH8nDGLp/YJlvHD74hEE5Zx2xFtydWW1raqDtruGKzEAOU2c1vZGGN6SM70QFkMX72NhmH7f7FLEkQmnhdmy4= Received: by 10.70.44.5 with SMTP id r5mr632234wxr; Tue, 06 Dec 2005 05:57:48 -0800 (PST) Received: by 10.70.82.2 with HTTP; Tue, 6 Dec 2005 05:57:47 -0800 (PST) Message-ID: <8b8d97d20512060557n8241355i81044565527b328b@mail.gmail.com> Date: Tue, 6 Dec 2005 08:57:48 -0500 From: Irv Salisbury To: dev@cocoon.apache.org Subject: Re: where is the box? In-Reply-To: <20051206055203.GC25600@localhost> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6432_21463226.1133877468029" References: <20051206055203.GC25600@localhost> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_6432_21463226.1133877468029 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 bee= n 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 Cocoo= n as it is something they haven't heard of. To me, adding in the fact that i= t 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 withi= n 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 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 > ------=_Part_6432_21463226.1133877468029 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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<= /a>> wrote:
I have been sitting back listening to the cocoon evolution/revolution
di= scussion, while happily coding with something else...

The developmen= t of open source is dominated by emergent properties,
which like their c= ounterparts in chemistry and physics are not
greatly affected by many types of environmental changes and are
diff= icult or impossible to predict from base causes.  The trick isto recognize that you are dealing with emergent properties and not
a se= t of well-behaved laws, and then to deal with the patterns that
present themselves.

Where is the recent bottleneck in Cocoon?&nb= sp; Is it the number of
languages, the complexity of the core, the = multi-step development
process, the inability to use a common debugger a= cross 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 al= l of these issues?

Since we are taking a moment to "think outsi= de the box," perhaps
we should pause to figure out where the box is and of what it is
mad= e.  When Cocoon was started there were not many viable choicesfor 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 sta= tic
and verbose language compared with these new offerings...and muchof 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 changethat comes with it.  Is that because of the Rails hype (whichwears off quickly) or because the language stays out of the way?
Tutori= als 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.  Perh= aps Cocoon is ready to spawn a new
breed with a Ruby core, where the language is succinct and more
frie= ndly to more dynamic code.  Domain languages become possible
w= ithout sacrificing a common syntax, debugger, and test suit.

Pause a= nd 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 o= f 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
th= at 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 Larso= n

------=_Part_6432_21463226.1133877468029--