ANNOUNCE: Project Cloverfield
=============================
I am pleased to announce the birth of Project Cloverfield. The goal of
this project is to develop a new Tcl-related language with the following
goals:

 - Keep maximum compatibility with the Tcl language syntax whenever
possible, and reuse the vast library of Tcl extensions and source code;
 - Perpetuate the philosophy of Tcl and capitalize on its many strengths;
 - Address the most common criticisms made to Tcl;
 - Achieve a greater visibility than Tcl in the industry, and extend
its community;
 - Take over the world.

In its current state, Cloverfield is not meant to become a replacement
to Tcl but a testbed for new ideas, although its ultimate achievement
would be of course to eventually become Tcl 9.

WHY "CLOVERFIELD"
=================
This project is the fruit of personal reflections on Tcl I developed
over my many years as a Tcl user, augmented with reflections from other
Tcl developers. In the past few weeks I felt the need to start a public
discussion on all these issues with fellow Tcl developers so as to
initiate a movement on more formal bases. It happens that the date of
the present announcement coincides with the release of J. J. Abrams'
long-awaited mystery movie once codenamed 1-18-08, hence the name
"Cloverfield".  I hope this will be a monster project ;-)

RATIONALE
=========
In the past years, a number of new languages and platforms have emerged,
some gaining a high momentum, such as Python, Ruby or PHP. In the
meantime, Tcl has achieved maturity but lagged behind in term of
popularity. A totally unscientific popularity test with Googlefight
gives Tcl widely defeated by all other similar languages, and Tcl is
hardly mentioned along with its competitors in articles or discussions
around dynamic languages. The general consensus in the industry is that
Tcl is dead or moribund.

In the evolutionary sense of the term this is close to the truth:
although the recent release of the long-awaited version 8.5 proves that
the community is still at work to improve Tcl, the language seems to
have reached a plateau of perfection from which hardly any further
significant progress can be made. This gives an impression of immobility
that new users find unexciting compared to the frenzy that agitates
other communities.

As a long time Tcl user I can't resign to see Tcl being the industry's
best kept secret any longer. In my professional career I have too often
seen Tcl being ruled out in favor of supposedly better solutions under
various reasons, such as obsolescence when compared to newer
technologies such as Python, or inadequation to the task when compared
to "serious", more "Enterprise-y" solutions such as C++ or Java. I
always felt frustrated by the lack of regard given to Tcl, the need to
justify my choice, and the near impossibility to use Tcl in my everyday
work.

I came to the conclusion that what Tcl needs is PR above technical
merits, which it already has. To do so, Tcl needs to die and reborn with
a new, catchy name. I am conscious that this might sound like blasphemy
to many, and I know that this will generate controversy, but we have to
keep in mind that the name "Tcl" is synonymous for "some dead language"
pretty much everywhere, so let's use one of the marketing people's
favorite stunts: let's change the name and keep selling the same stuff.

On the technical side, Tcl also needs to evolve and address long-lasting
issues, sometimes at the price of deep changes to the language itself.
One of the most frequent criticisms heard about Tcl is the way comments
work, and while all seasoned Tcl users know that the way Tcl treats
comments is totally consistent, and can explain why, most people outside
of the community designate Tcl as the language where comments don't work
as expected (read: as other languages treat them). Addressing many of
these issues often require totally incompatible changes to the language,
which explains why these changes cannot (and haven't) be made on current
versions. From the outside of the community, the inability to address
this problem is seen as a lack of commitment from community members
locked in their ivory tower.

The last major point of the project is related to implementation and low
level issues. The existing Tcl implementation is notoriously solid,
however some changes are too radical to be performed on the current code
base, so a reimplementation is certainly needed on vast portions. For
example, the string representations, object structures, and virtual
machines will certainly require complete rewrite to accommodate with the
needed changes, which means that a lot of code won't be reused. However
vast portions of library code and algorithms certainly will (clock scan,
bigint, regexp...), as well as the high coding standards and QA that are
the trademarks of our beloved language.

I am conscious that this project is controversial by nature, and the
risks of not reaching a wide consensus are pretty high. It also implies
that if these changes were to be rejected, then the outcome of this
project will be a distinct new language with a life on its own, like for
example the Tcl-inspired Hecl, and probably a one-person project.

On a personal level, this is a risk I'm ready to take, and the present
announcement coincides with improvements in my personal life that will
give me more free time to work on such a far-reaching project (unlike
some of my previous projects that I had to keep on hold for the past
years). But the ultimate goal of this project is really to reach the
wider consensus in the Tcl community without sacrificing crucial points.

CURRENT STATUS
==============
At present Cloverfield is essentially vaporware with a wiki page located
here:

    https://wiki.tcl-lang.org/Cloverfield 

This page should be the entry point for all discussion regarding the
project. Discussion on comp.lang.tcl should be avoided whenever possible
for practicality (*), and in order not to disrupt the regular flow of
messages there.

Comments welcome!

(*) I lack regular access to a NNTP server and am forced to post via
Google Groups most of the time.