Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 6 Dec 2005 05:52:03 +0000
From: Tim Larson <tim@keow.org>
To: dev@cocoon.apache.org
Subject: where is the box?
Message-ID: <20051206055203.GC25600@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i

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