> Why you should not use Tcl
RMS rests his argument on two assertions:
I.
> Tcl was not designed to be a serious programming language.
II.
> Tcl has a peculiar syntax
And then goes on to suggest
III.
> we [ GNU Project] want to provide two languages, similar in
> semantics but with different syntaxes. One will be Lisp-like...
I & II are both undeniably true, but they should be taken in context:
Lets assume for the moment that we want a language that meets the
following minimal specifications (which tcl is supposed to provide)
(1) convenient for script writing
(2) interpreted
(3) embeddable
(4) composable
(5) portable
The question now becomes: can you do any better than tcl---i.e,
can you meet those specs, as well as support:
(7) full featured modern programming language
(8) friendly syntax
As for the dual language solution, III:
This does not seem like a good solution to me! Two language with
the same capabilities but vastly different syntaxes??? It
seems like the natural evolution of such a system will be that
either one language or the other will greatly dominate in
use---which defeats the purpose of having two, since one becomes
the defacto standard---or most projects will be written in
bits and pieces of both, which just means everyone has to know
all of them, and constantly switch back and forth between
different languages that do nearly the same thing
(much like the situation with the various unix shell languages
these days: sh, csh, tcsh, ksh, bash, rc...).
_If_ you want a viable two language solution,
one should play a subordinate role to the other, i.e. be built
on top of the other, as a higher level, somehow simplified
language (like C on top of assembly, for e.g..)
Qusetion1: Aside from the two dual language issue, why schould one
of them be lisp? This seems motivated solely by historical bias.
Question2: doesn't Python essentially provide what RMS wants?
Why doesn't GNU just adopt Python as its defacto language?
-- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet; NeXTMail is welcome)