Tcl has a peculiar syntax that appeals to hackers because of its
simplicity. But Tcl syntax seems strange to most users. If Tcl does
become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
I wholeheartedly agree. (See also:
"Why Tcl Doesn't Scale"
$Id: why-tcl-doesnt-scale.html,v 1.1 1994/06/20 16:47:53 connolly Exp $
http://www.hal.com/users/connolly/drafts/why-tcl-doesnt-scale.html
)
But first, I think RMS's article fails to give credit where credit is
due. Tcl is a great contribution and serves many purposes. Dr. John
Osterhout has written some excellent code which helps a lot of folks
get a lot of stuff done. I fear that the lack of acknowledgement
in RMS's article will spawn a great volume of flames... let's hope
not.
Now that that's done with... what will GNU software use? Where can I
find more details?
For example, tcl/expect is used in DejaGnu, the regression testing
tools. Tcl seems well suited to this task. Certainly expect is the
best available tool of its kind. Is the plan to replace tcl with some
other scripting language in that toolset? That would seem to imply
that all the test suites would have to be revised. (Is dejagnu
considered GNU software, or is it like gnuplot in that it just uses
the GNU name?)
I gather that scheme is a contender. I like schemes formal grounding,
but scheme standards (R^4RS etc.) leave a lot of parts of a software
development platform unspecified. As a result, scheme code tends to
not be portable between implementations. Unlike large bodies of
common lisp code, large bodies of scheme code tend to need "tweaking"
and "porting" to run on various scheme implementations.
* I'm not advocating common lisp.
** I don't have a lot of experience developing in scheme --
I've just looked at lots of net distributions.
Have folks looked at Scheme48? See:
"Scheme 48 home page"
http://www-swiss.ai.mit.edu/~jar/s48.html
Has python been considered? I like the language, though the
implementation has some limitations. (for details, see
comp.lang.python or
http://www.cwi.nl/ftp/python/index.html
)
Here are some of the issues I find important in a modern programming
language, with a comparison of some of the options:
Threads: for interactive programs -- especially distributed applications
which are now the rule more than the exception -- thread support
in the language/runtime greatly simplifies development
Modules: or packages or whatever: some mechanism to help maintain
the namespace is a must.
Continuations: the all-powerful construct from which anything can be
derived. Makes foreign-function interfaces a mess, though.
Perhaps continuations or even objects are enough...
Good FFI: Foreign Function Interface. A way to bind C functions.
"Good" in the sense that lots of folks have used it to
build useful applications.
Exceptions: You can't rely on a style of checking return codes for
building large, reliable programs.
RPC Support: Support for making calls across address spaces easily.
Embedded Languages:
Tcl Scheme48 Python Perl4 Obliq
Threads ???(1) YES YES(2) NO YES
Modules NO YES YES YES NO
Continuations NO YES NO NO YES
Good FFI YES NO YES NO YES
Exceptions YES YES YES YES YES
RPC Support YES NO YES(3) NO YES
(1) I think Tcl as a language is consistent with a multithreaded
implementation, but I don't think the current implemention
is thread-safe. Certainly there is no language support for threads.
(2) The python threads support is kinda funky and not too stable.
(3) Python includes support for automatic marshalling of basic types,
plus socket support. It's not a complete RPC system, but it's close...
"Systems programming" Languages:
CommonLisp C++ Modula-3
Threads NO NO YES
Modules YES YES(4) YES
Continuations NO NO NO
Good FFI ???(6) YES YES
Exceptions YES YES(5) YES
RPC Support NO NO(7) YES
(4) Using classes as namespaces is a messy hack.
(5) C++ exceptions are a messy hack.
(6) Various common lisp implementations probably have good FFI's.
(7) There are several C++ based RPC systems based on COBRA.
I also consider it important that the language lend itself to static
alalysis -- whether that means something like Modula-3's excellent
type system and strong static typing, or even scheme's formal
semantics and static scoping which make thinks like type inference and
program proving somewhat practical.
Static analysis enables things like code browsers and optimizing
compilers (or even source-to-source optimizers...). For an interesting
example, see the Modula-3 library source code at:
http://www.research.digital.com/SRC/m3sources/html/INDEX.html
Mow imagine doing that with a body of C++ code -- if the C preprocessor
was used with great discipline, perhaps. But in real life...
Dan
-- Daniel W. Connolly "We believe in the interconnectedness of all things" Software Engineer, Hal Software Systems, OLIAS project (512) 834-9962 x5010 <connolly@hal.com> http://www.hal.com/%7Econnolly/index.html