gnu`way vs Tcl 1994

6.21:
Richard Stallman (rms@gnu.ai.mit.edu) Sep 94:

Why you should not use Tcl
As interest builds in extensible application programs and tools,
and some programmers are tempted to use Tcl,
we should not forget the lessons learned from the first widely used
extensible text editor --Emacs:
a language for extensions should not be a mere "extension language".
It should be a real programming language,
designed for writing and maintaining substantial programs
. Because people will want to do that!
[and his vision for the tcl replacement,
was a full-featured interactive system like lisp,
but which included an an algebraic syntax
(what I would call mathy-english friendly language) ]

and comments to his remark:

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:
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.
[7.6: you just need a transaction-based system:
if a continuation is requested during a call to a foreign function,
then the continuation would be rolled back to before that call . ]

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 (the way c does it)
for building large, reliable programs.
[7.6: the high-security language Spark, based on Ada,
consider Ada`exceptions to be a burden to security ]

RPC Support: [remote procedure call]
Support for making calls across address spaces easily.

... :
Rather than define specific features for the core language,
it should focus on inter-operability
. For example, the core language should use something like the OMG's
version of 'IDL' to define interface specifications
. Automated tools could then generate stubs and interface code
. This simplies the process of 'importing' functionality into the interpreter.

tcl`creator (John Ousterhout (ouster@tcl.eng.sun.com) 26 Sep 1994)
points out that Stallman's choice of Lisp
is ironic since people have already voted that out .
[. I'd qualify that by pointing out that Lisp, like tcl,
has a glaring lack:
it has a syntax only for its symbolic expr'trees
-- it has no mathy-english language to cover those etrees!
. I believe Stallman agreed with this, and was refering to it when he said
that gnu's other lang, besides lisp, should be an "(algebraic) one . ]

[. one great reason for mentioning lisp during talk about replacing tcl,
is that a glue language should be using etrees, not strings, for messaging .
. assuming tcl looks easy like Basic,
a great language should be putting a real skin like tcl
on a real language like lisp .
. the reason it uses strings is to "(make it really easy to drop down into C)
-- C has a convention of passing strings to main;
however, C also allows access to binary files,
and these could be used for messaging . ]

Wayne Throop (throopw%sheol.uucp@dg-rtp.dg.com) 27 Sep 1994:
I think that expressing things primitively in text
leads to simpler and more fluent notational innovation
than does expressing things in s-expressions.

[the 2-lang system:
. there is significant agreement that there should be a 2-lang solution,
where one is used for scripting, and another for mature or low-level code .
. the primary assumption here though,
is that the best low-level code is c,
and obviously c is not a good scripting lang .
. lisp has a single-lang solution:
your scripting lang is compiled or translated into c .
. some caveats here include:
the scripting lang is easy because it doesn't include details
but you need those details to code efficiently .
. most of the diff's between scripts and c,
are like the diff's between c and assembler:
asm had a very simple lang primarily so the compiler could
fit into very tight amounts of memory .
. c was created to fit into just double that tight space,
so while it could afford a nice syntax,
it was still lacking a lot of bug-catching support .
. bottom line is that c solved the fundamental problem:
the portable algorithm language .
... well almost:
people are still having to create add-on lib's for some
very fundamental features: the gui events, dynamic linking, and multi-threading .]