This is the text of the official announcement for the Cloverfield project as posted on comp.lang.tcl on January 18, 2008.
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.