When this whole Perl6 business started four years ago, one of the goals was to attempt to share and converge our engineering efforts across programming language communities. It's stupid for Tim Bunce to do a whole mess of work with DBI only to have some poor Python or Ruby developer reimplement all that work to get something vaguely similar available in another programming language. Ditto things like combining Mailman and SpamAssassin together (written in Python and Perl respectively).
That was the theory. There will always be people who use an old version of Perl, Python or whatnot regardless of what new releases are available, whether they are patches against a prior release or total reimplementations on top of Parrot, the JVM or the .net CLI. And that's a good thing -- since you are using open source, you have control over your destiny, including the choice to stick with 5.005 for another few years. But new development should converge quickly on a Parrot-hosted framework, which will allow us to share our code across languages.
In Perl, we generally upgrade fairly easily from version to version. There are new features in the language, but generally speaking, the quirks remain present in future releases. Occasionally the XS interface changes, which may present a barrier to upgrading, but that's not terribly common or very long lasting. The main reason why apps remain on old versions of Perl is because they are working, and the old release is part of a fully tested system. Changing the interpreter changes the system and could possibly introduce bugs or unexpected changes in behavior -- something you don't want on a production system.
But with both Perl and Python, there is a tremendous amount of new development going on, and that new development tends to happen in a recent release of the language. The same is true with PHP. However, from my recent experience, this is not the case with Tcl.
From what I've seen, Tcl projects tend to be in maintenance mode, bound to an old release of the language. In projects that track the current releases, those projects tend to have a deeper dependency on Tcl internals than a Perl project has on Perl internals. Because it is so easy to write a C-based Tcl module, replacing the current codebase with something hosted in Parrot is strikes me as undesirable, since the dependencies on the implemenation characteristics of Tcl will break.
From a technical perspective, Tcl usage isn't very different from Perl or Python usage. Sure, the community of active users is much smaller, and if no Tcl programmers switch to Parrot, it's only a loss of a few hundred users, so it's not really worring about from the point of view of Parrot developers. By extension, no one should be offended if Forth, Haskell or Intercal programmers don't flock to Parrot by the dozen. That's not to say that Tcl-on-Parrot isn't a useful exercise, or that no one will use it. It's just that the Tcl community at large doesn't seem to want or need such a beast.
But the really interesting thing is that the difference seems to be entirely social. The difference is in how Tcl hackers view and use Tcl compared to how Perl programmers view and use Perl, and so on. And while those characteristics are different from Perl, the social nature of Tcl is almost the exact opposite of the social nature of PHP. So, if my gut is right here, then Tcl programmers will by and large ignore Parrot, while PHP programmers will flock to it (even if they don't know or care one bit about Parrot).
Re:turn of phrase
KLB on 2004-09-29T17:51:09
*thhhhhhhhbpth* -Will Coleda
