After attending the VHLL Symposium at Santa Fe where zillions of languages
were showed off and talked about, I've been thinking about this new
universal scripting language that RMS proposes, the one that's supposed to
obsolete all other scripting languages in existence. I now believe doomed
his plan to make a universal scripting language, especially one derived
from scheme. He would like this language to be used by any application
wanting embeddability or extensibility will employ. Essentially, it will
fail due to lack of consideration of these issues:
* a developer's requirement to use whatever they feel like
* substantial inertia favoring existing practice
* sysadmins want easy extensions/config files
* sysadmins are more used to shellish languages than lispish ones
* little languages are best for configlike files
The only points RMS makes which I recall to have substantial weight are
that you need a fully-featured and reasonably fast language for real-world
applications and that tcl isn't very good at this. Well, maybe the latter
is indeed true, but given that people are using tcl for this and are doing
so with reasonable efficacy proves it works sufficiently well for this
purpose. tk and expect prove that. Please remember that as a glue
language, tcl doesn't need to handle large 50,000-line programs well.
Making it do so could in fact impair its being good glue language.
If the language is good for generating and parsing things like .Xdefaults
or Makefiles or .cliprc files, fine, but if this just forces sysadmins to
code in scheme or rush or something, they'll just laugh at you. Well,
until they're FORCED to use it, at which point they'll kick and scream for
something easier.
Declarative languages, perhaps with escapes into code (a la yacc, escaping
into C or perl), are the best way of handling a lot of problems, and both
yacc and tcl make it easy create these, and perl certainly is good at
parsing such files. There's no reason for all config syntaxes to to be
the same. To the contrary: problems are just too varied for one
declarative syntax describing them. And that's ok.
I'll tell you a place the FSF can perhaps help. Consider the benefit from
the perl<->ksh portability dialog, or better, the refined and streamlined
C API for tk that I presume will come out of the tkperl<->tkpython
dialog. This is the kind of thing we need. It's good to have a common C
API. If GNU can standarize things like that, then great. But telling
someone they must use language GNU Blah for an extension language, well,
get real: it really just isn't going to happen.
I genuinely don't see that there's enough substantially wrong with the
way we make little languages now, either for extension or embeddability,
that a huge niche will suddenly be filled by gnu script. GNU only
succeeds when there's a technical niche to fill, not when there's a
political need to fill.
We'll all just keep using yacc and tcl and perl for these (and maybe even
ksh and python) and we'll all be happy. They've decades of combined use
to hone and perfect. GNU script will not have that. Without TREMENDOUS
incentives, nothing will change. Can you imagine all dot files and config
files and macro files and rc files all being in one syntax? This will
never happen. And if you try to enforce it, it'll blow up in your face.
Straitjacketing won't win you friends.
In summary, I truly fear you're wasting a great deal of time attempting to
create something no one wants or needs badly enough to put up with. In
other words: it's not broken, so don't try to fix it.
--tom
-- Tom Christiansen Perl Consultant, Gamer, Hiker tchrist@mox.perl.comif (shm == (char *)-1) /* I hate System V IPC, I really do */ --Larry Wall, from doio.c in the v5.0 perl distribution