Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Extension/Scripting language comparisons

379 views
Skip to first unread message

Joe Mueller

unread,
Jul 6, 1995, 3:00:00 AM7/6/95
to
I'm in the workgroup within the CAD Framework Inititiative (a standards organization
for CAD tool developers/users) that is responsible for Extension Language selection.
Some time ago we selected Scheme as the standard extension language for this organization
but have lately come under fire for not selecting/considering Tcl and Perl as alternatives
to "ugly" Scheme. I would like to get a list of pros/cons for Scheme, Tcl, and Perl
as extension/scripting languages to (hopefully) better defend the choice of Scheme.

Some time ago there was a raging debate over the virtues of Tcl vs. Scheme
as an extension/scripting language. Unfortunately I did not capture the
major pros/cons at that time. Could someone send me a synopsys of the major points?

What about a comparison of Perl to Scheme?

Any help would be appreciated,

Joe_M...@mentorg.com

Alan Bawden

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
In article <3thlus$i...@hpbab.wv>
jo...@aardvark.mentorg.com (Joe Mueller) writes:

I'm in the workgroup within the CAD Framework Inititiative (a standards
organization for CAD tool developers/users) that is responsible for
Extension Language selection. Some time ago we selected Scheme as the
standard extension language for this organization but have lately come
under fire for not selecting/considering Tcl and Perl as alternatives to
"ugly" Scheme. I would like to get a list of pros/cons for Scheme, Tcl,
and Perl as extension/scripting languages to (hopefully) better defend

the choice of Scheme....

You can't defend the indefensible -- Scheme is a terrible choice. The most
important thing about a extension/scripting language is that it be
-simple-. It must have a simple easy-to-understand semantics, it must have
simple easy-to-use data structures, and it must have simple easy-to-read
syntax. Scheme has none of these, while Tcl and Perl have them all. Let's
take these aspects of simplicity one at a time:

Semantics. Tcl and Perl are based on string substitution. What could be
simpler? Scheme has closures and continuations. Even graduate students at
MIT are confused by that stuff.

Data structures. Tcl and Perl have strings. And basically, that's -all-
they have. But strings are universal -- you can represent anything using
strings. And strings are simple. Heck, if everything is a string, you
don't even need a garbage collector! Furthermore, everything else in a
modern computer is based on tools that consume and produce strings, so Tcl
and Perl fit right in. Scheme doesn't even have a foreign function
interface, so you can't glue a Scheme program together with -anything-.

Syntax. We all learned infix syntax in grade school. `x + 2*y' is
concise, familiar and easy-to-read. In Scheme you have to write
`(+ x (* 2 y))'. Only an idiot would prefer to write that.

Wise up. Flush Scheme.
--
Alan Bawden Al...@LCS.MIT.EDU
617/492-7274 06BF9EB8FC4CFC24DC75BDAE3BB25C4B

Tom Gordon

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to jo...@aardvark.mentorg.com

Dear Joe,


I think the CAD Framework Initiative should stick to Scheme.
There are many reasons. Here are some of the more important ones:

1. It is already a international (IEEE) and national (ANSI) standard.

2. It is also used by the ISO DSSSL standard (Document Style and Semantics
Specification Language), which is adds programmability to SGML, the language
used for the World Wide Web. (HTML is an SGML application.)

3. Scheme has been chosen for to be the basis for the GNU extension language,
GUILE.

4. There are many Scheme implementations, for every operating system. Many of
these are free. Similarly, there are a variety of different kinds of implementations,
suitable for different jobs, from small, embeddable interpreters to native code compilers.

5. Scheme is well documented and understood. Becuase of its widespread use
in Computer Science education, there are many excellent textbooks.

6. Scheme is very flexible and adaptable. It is no accident that Scheme (and other Lisp
dialects) are so often used for prototyping new programming langauges and paradigms.
Object-oriented programming, rule-based programming, logic programming, data flow programming,
and constraint programming can all be done in Scheme, and have been done in Scheme.
Presumably, many of these programming techniques will be useful in the context of
computer-aided drafting.

To sum up, Scheme is a safe, conversative choice for a *standard* extension language.
It is not new or fashionable, but then new languages are not ripe for standardization.
It may not be perfect, or everyone's ideal language, but there is no question about
it being suitable and appropriate.

Tom Gordon

p.s. About Scheme being "ugly". Experience shows that there is no point in arguing this
issue. Many, including myself, find Scheme elegant and beautiful --- especially compared
to baroque languages like TCL and Perl.

Steven L Jenkins

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
In article <3thlus$i...@hpbab.wv>,

Joe Mueller <jo...@aardvark.mentorg.com> wrote:
>I'm in the workgroup within the CAD Framework Inititiative (a standards organization
>for CAD tool developers/users) that is responsible for Extension Language selection.
>Some time ago we selected Scheme as the standard extension language for this organization
>but have lately come under fire for not selecting/considering Tcl and Perl as alternatives
>to "ugly" Scheme. I would like to get a list of pros/cons for Scheme, Tcl, and Perl
>as extension/scripting languages to (hopefully) better defend the choice of Scheme.
>
>Some time ago there was a raging debate over the virtues of Tcl vs. Scheme
>as an extension/scripting language. Unfortunately I did not capture the
>major pros/cons at that time. Could someone send me a synopsys of the major points?
>
>What about a comparison of Perl to Scheme?

Let me preface this by saying that I personally prefer Scheme over just about
any other language. However, in my daily duties as a systems administrator
I use Tcl/Tk and Perl constantly, but never Scheme. But I haven't looked at
Guile, and the version of scsh I looked at was quite primitive. I have
played around a good bit with STk, but as it doesn't include a lot of Unix
systems calls, I haven't used it for any 'systems' work.

Perl is my language of choice for systems work as it has nearly every system
call I use, plus lots of bells and whistles. To me, that's its strongest
feature. Another reason others use it is that there is quite a large, active
user-base for it (compare traffic on the comp.lang.perl.* with
comp.lang.scheme). I personally don't think it's any panacea, but it gets
the job done w/o a lot of fuss (although Perl5 looks pretty overloaded with
features to me).

Tcl/Tk is nice because it is so tiny (like Scheme), but it has (IMO) an
annoying set of syntax rules (or rather, lack thereof). I usually use Tcl/tk
to actually build a GUI, then Tcl or Perl to do the guts of my applications.

Disclaimer: this is based on my experience as a Systems Administrator writing
tons of little programs to gather & analyze data, not extending any existing
applications, unless you consider the shell an application.


Robert P. Goldman

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
Steven Jenkins' discussion of the relative merits of perl and scsh
is of interest to those who, like him, are using scripts to automate
systems administration chores.

However, I would like to recall the discussion to Joe Mueller's
original question. Remember, he's asked about Scheme vs. Perl
vs. Tcl for the purposes of an embedded extension language. That's
in fact a very different question! Off-hand, I wouldn't be
surprised if some of the things that Steven likes (and I like!)
about perl as a scripting language would not be appropriate for an
extension language...

Also, I would implore the group not to get lost in arguments about
infix vs. prefix syntax! It's just a rewrite away! Prefix can
easily become infix!

Actually, there has been some argument that simple prefix notation
is inherently better for writing macros...


Erik Naggum

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
[Alan Bawden]

| Syntax. We all learned infix syntax in grade school. `x + 2*y' is
| concise, familiar and easy-to-read. In Scheme you have to write
| `(+ x (* 2 y))'. Only an idiot would prefer to write that.

I'm surprised that those who argue against Scheme only use computers to do
arithmetic exercises from grade school. that is such a lame criticism that
I wonder about the mental capacity with which those who make such arguments
must be endowed.

seriously, prefix syntax for heavy arithmetic is known to be a pain, but
it's always interesting to see how people compare prefix, infix and postfix
syntax. Eyvind Ness of the OECD Halden Reactor Project showed me that it's
much more effective to show them with multiple arguments:

postfix: j k l m n + + + +
infix: j + k + l + m + n
prefix: (+ j k l m n)

infix and postfix are restricted to binary operators, whereas prefix can be
n-ary for an arbitrarily large n. code becomes cleaner when this is used,
and is thus easier to debug. this becomes more pronounced with more
complex arguments, of course.

| Semantics. Tcl and Perl are based on string substitution. What could
| be simpler? Scheme has closures and continuations. Even graduate
| students at MIT are confused by that stuff.

this is like saying that Microsoft Word is as easy as clicking on menus and
"what you see is all you get", compared to LaTeX where it's so hard to
write new styles that only a handful of people worldwide can hack it.

you'll do great in marketing, Alan.

folks, you should look at the intellectual honesty of the critics of the
various suggested languages. beware of those who criticize something for
being more powerful than you need the first few weeks of using it. if a
language can be exhaustively learned in, say, 21 days, worry about the
_upper_ limit to what you can do in that language. ease of learning comes
at the cost of pain in non-trivial use. that doesn't mean that that which
is hard to learn is necessarily any less painful at non-trivial problems.

#<Erik 3014143758>
--
NETSCAPISM /net-'sca-,pi-z*m/ n (1995): habitual diversion of the mind to
purely imaginative activity or entertainment as an escape from the
realization that the Internet was built by and for someone else.

br...@liverpool.ac.uk

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
>>>>> "Alan" == Alan Bawden <al...@lcs.mit.edu> writes:

> In article <3thlus$i...@hpbab.wv> jo...@aardvark.mentorg.com (Joe
> Mueller) writes:

>> I'm in the workgroup within the CAD Framework Inititiative (a
>> standards organization for CAD tool developers/users) that is
>> responsible for Extension Language selection. Some time ago we
>> selected Scheme as the standard extension language for this
>> organization but have lately come under fire for not
>> selecting/considering Tcl and Perl as alternatives to "ugly"
>> Scheme. I would like to get a list of pros/cons for Scheme, Tcl,
>> and Perl as extension/scripting languages to (hopefully) better

>> defend the choice of Scheme....

> Semantics. Tcl and Perl are based on string substitution. What
> could be simpler? Scheme has closures and continuations. Even
> graduate students at MIT are confused by that stuff.

Scheme is based on list evaluation: it has a very simple semantics,
uncluttered by restrictions. String substitution can be surprisingly
subtle: look at the Tcl FAQ for some simple mistakes that just about
every Tcl user makes every now and again.

> Data structures. Tcl and Perl have strings. And basically, that's
> -all- they have.

That's unfair: Perl has lots more than just strings. And Tcl
(explicitly borrowing from Lisp) has good support for lists. For a
CAD extension language, I'd want something that can support numbers,
and can support them efficiently. Tcl has major problems in that
area, with conversions happening all over the place slowing things
down. Often this isn't significant (I'm using Tcl at the moment, and
its speed is just fine) but sometimes it is, and my guess is that for
a CAD extension language that's going to be used for significant
extensions, it would be.

> Scheme doesn't even have a foreign function interface, so you can't
> glue a Scheme program together with -anything-.

Choose an implementation. For example, Guile. Gosh, it's got two
foreign function interfaces, one compatible with Tcl's.

> Syntax. We all learned infix syntax in grade school. `x + 2*y' is
> concise, familiar and easy-to-read. In Scheme you have to write `(+
> x (* 2 y))'. Only an idiot would prefer to write that.

Or rather [expr $x+2*$y]. But yes, it's still better. But Guile has
(or will have RSN) a C-like syntax, translated automatically to Scheme.
--
Bruce Institute of Advanced Scientific Computation
br...@liverpool.ac.uk University of Liverpool
http://supr.scm.liv.ac.uk/~bruce/


Larry Wall

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
In article <3tio9c$t...@omega.gmd.de>, Tom Gordon <thomas...@gmd.de> wrote:
: p.s. About Scheme being "ugly". Experience shows that there is no

: point in arguing this issue. Many, including myself, find Scheme
: elegant and beautiful --- especially compared to baroque languages
: like TCL and Perl.

While I do consider the adjective "baroque" to be a compliment, I must
point out that Perl is actually more of a romantic piece, with allusions
to various classical motifs. My favorite composer is Mahler, which should
surprise no one.

Larry Wall
lw...@netlabs.com

Chak Tan

unread,
Jul 7, 1995, 3:00:00 AM7/7/95
to
Joe Muller (JM) writes:
JM> I'm in the workgroup within the CAD Framework Inititiative
JM> (a standards organization for CAD tool developers/users) that
JM> is responsible for Extension Language selection. Some time
JM> ago we selected Scheme as the standard extension language for
JM> this organization but have lately come under fire for not
JM> selecting/considering Tcl and Perl as alternatives to "ugly"
JM> Scheme. I would like to get a list of pros/cons for Scheme,

I would imagine that Perl packs too much extra baggage for a CAD
extension language. Perl has many powerful features specialized for
manipulating streams of data and performing system related
operations. Are these features important for a CAD extension
language? Also, unless one is very familiar with Perl, the sheer
abundance of features and tricks can be confusing. For instance, the
context dependent semantics and the various special characters makes
me uncomfortable. I must say though, once you've got the hang of it,
Perl is very handy for certain types of programming.

Tcl has many cleanly engineered low level C routines (I use the
hashtables frequently), but suffers from a few drawbacks as a high
level language. All the upvar and global/local stuff seems a little
too adhoc to me. Also, Tcl is slow because of all that string
conversions coupled with numerous hashtable lookup for everything. If
the goal is to provide a high level command-line interface to
low-level code within your CAD program, then Tcl would be okay; but,
if you want to expose CAD specific structures (like netlists) to a
high level language for interactive processing, then Tcl would not be
high on my list of languages.

Scheme seems like a very good choice -- minimal scheme is lightweight
and not tailored for any specific purposes so you can customize scheme
for a specific purpose without any extra baggage. Also, in my
opinion, scheme is elegant, expressive, and fun.

I think the choice of languages will be decreasingly important in the
future with the emergence of language neutral tools like ILU form PARC
Xerox, Guile from FSF, and the JavaVM from Sun. Perhaps your group
can concentrate on building a scheme interface to ILU or get involved
with Guile or Java and resolve the language problem by looking towards
the future.

JM> Tcl, and Perl as extension/scripting languages to (hopefully)
JM> better defend the choice of Scheme....

Alan Bawden (AB) replies:
AB> You can't defend the indefensible -- Scheme is a terrible
AB> choice. The most important thing about a extension/scripting
AB> language is that it be -simple-. It must have a simple
AB> easy-to-understand semantics, it must have simple easy-to-use
AB> data structures, and it must have simple easy-to-read syntax.
AB> Scheme has none of these, while Tcl and Perl have them all.

Well, I disagree here. Scheme, too, is simple and elegant, has very
straight forward and consistent semantics, is structure on the concept
of simple pairs as the main data structure, and is easy too read
after one takes time to learn it.

AB> Let's take these aspects of simplicity one at a time:

AB> Semantics. Tcl and Perl are based on string substitution.
AB> What could be simpler? Scheme has closures and continuations.

Hmm, when I'm on a Mac or PC many of the strings are mapped
differently than on a Unix system. String subsitiution often gives me
grief when I'm trying to perform tasks on different platforms. So I
guess string substitution is not so simple for me. I find closures
and continuations easier to handle.

AB> Even graduate students at MIT are confused by that stuff.

I know/knew undergraduate and even highschool students who understood
these "confusing" ideas, what's the point of this argument? Some
people get it, some people don't. Are you saying that scheme is
inherently harder to learn?

AB> Data structures. Tcl and Perl have strings. And basically,

I think Perl has scalars, arrays of scalars, and associative arrays of
scalars where scalars can be a string, a number, and a reference which
are internally represented in a efficient manner (i.e. not as strings).

AB> that's -all- they have. But strings are universal -- you can
AB> represent anything using strings. And strings are simple.

Same with ones and zeros. Strings are representations of ones and
zeros that most humans find easy to work with. However, they are not
efficient as far as the computer is concern (waste lots of space and
computational cycles to process). Why not let the computer work
efficiently and only resort to strings when they have to communicate
with the user? Why not use structures that encompass strings? A CAD
program may have lists that contain millions of nodes, should I use
'NODE1' 'NODE2' ... 'NODE1000000' to enumerate all my nodes?

AB> Heck, if everything is a string, you don't even need a garbage
AB> collector! Furthermore, everything else in a modern computer

Can you explain this to me? How does using only strings eliminate the
need for a garbage collector? I'll have to think about this one.

AB> is based on tools that consume and produce strings, so Tcl and
AB> Perl fit right in. Scheme doesn't even have a foreign

Isn't most of the text-base tools from the last generation? I thought
serialization/marshalling/pickeling or whatever it's call is the new
way of interprocess/interobject sharing of data. Also, isn't HTTP-NG
trying to move away form a text-based protocal for WWW (the most
recent example of a text-base protocal).

AB> function interface, so you can't glue a Scheme program
AB> together with -anything-.

I think Elk 2.2, Guile, Libscheme, SIOD all have FFIs. I'm hard press
to think of a publically available scheme that does not have an FFI.

AB> Syntax. We all learned infix syntax in grade school. `x +
AB> 2*y' is concise, familiar and easy-to-read. In Scheme you
AB> have to write `(+ x (* 2 y))'. Only an idiot would prefer to
AB> write that.

Hey, I'm an idiot then. I learned 'x + 2 * y' in grade shcool,
'y 2 * x +' in college, and '(+ x (* 2 y))' in graduate school. What
are my teachers doing to me! Turning me into an idjit!?

-- Chak Tan

AB> Wise up. Flush Scheme. -- Alan Bawden Al...@LCS.MIT.EDU
AB> 617/492-7274 06BF9EB8FC4CFC24DC75BDAE3BB25C4B


Darius Bacon

unread,
Jul 8, 1995, 3:00:00 AM7/8/95
to
al...@lcs.mit.edu (Alan Bawden) writes:

>Semantics. Tcl and Perl are based on string substitution. What could be
>simpler? Scheme has closures and continuations. Even graduate students at


>MIT are confused by that stuff.

I know a guy with an MSCS who's confused by *recursion*. If we're going to
make the world safe for cookbook programmers, a sound semantic model with a
minimum of pitfalls for the unwary is essential. From that viewpoint Scheme
looks pretty good compared to Perl and Tcl; and of course you can do plenty
with it without knowing diddly about continuations. SML might have been an
even better choice.

>Syntax. We all learned infix syntax in grade school. `x + 2*y' is
>concise, familiar and easy-to-read. In Scheme you have to write
>`(+ x (* 2 y))'. Only an idiot would prefer to write that.

Score another for SML, at least in this audience.

>Wise up. Flush Scheme.

Good one! For a moment there I thought you were serious...

-Darius

R.S. Nikhil

unread,
Jul 8, 1995, 3:00:00 AM7/8/95
to
In article <19950707...@naggum.no>, er...@naggum.no (Erik Naggum) writes:
|> seriously, prefix syntax for heavy arithmetic is known to be a pain, but
|> it's always interesting to see how people compare prefix, infix and postfix
|> syntax. Eyvind Ness of the OECD Halden Reactor Project showed me that it's
|> much more effective to show them with multiple arguments:
|>
|> postfix: j k l m n + + + +
|> infix: j + k + l + m + n
|> prefix: (+ j k l m n)
|>
|> infix and postfix are restricted to binary operators, whereas prefix can be
|> n-ary for an arbitrarily large n. code becomes cleaner when this is used,
|> and is thus easier to debug. this becomes more pronounced with more
|> complex arguments, of course.

This is a false comparison of prefix vs. postfix-- it really has to do using parentheses for
grouping. With parentheses for grouping, postfix is as concise as prefix:

postfix: (j k l m n +)


prefix: (+ j k l m n)

Without parentheses for grouping, prefix is as verbose as postfix:

postfix: j k l m n + + + +

prefix: + + + + j k l m n

In each case, without parentheses, you have to fix an arity for the operator; with parentheses,
they can have variable arity.

Rishiyur Nikhil (nik...@crl.dec.com)

Larry Wall

unread,
Jul 8, 1995, 3:00:00 AM7/8/95
to
In article <3tkdc2$4...@tesla.ee.rochester.edu>,
Chak Tan <t...@tesla.ee.rochester.edu> wrote:
: I think Perl has scalars, arrays of scalars, and associative arrays of

: scalars where scalars can be a string, a number, and a reference which
: are internally represented in a efficient manner (i.e. not as strings).

This is correct. Perl also has closures, though not continuations.

Larry Wall
lw...@netlabs.com

Stephen Benson

unread,
Jul 8, 1995, 3:00:00 AM7/8/95
to

In article <3thlus$i...@hpbab.wv>, Joe Mueller (jo...@aardvark.mentorg.com) writes:
>I'm in the workgroup within the CAD Framework Inititiative (a standards organization
>for CAD tool developers/users) that is responsible for Extension Language selection.
>Some time ago we selected Scheme as the standard extension language for this organization
>but have lately come under fire for not selecting/considering Tcl and Perl as alternatives
>to "ugly" Scheme. I would like to get a list of pros/cons for Scheme, Tcl, and Perl
>as extension/scripting languages to (hopefully) better defend the choice of Scheme.
>
>Some time ago there was a raging debate over the virtues of Tcl vs. Scheme
>as an extension/scripting language. Unfortunately I did not capture the
>major pros/cons at that time. Could someone send me a synopsys of the major points?
>

I think this is what you were referring to... it caused major ructions on the
tcl group:

>REPLY-TO: r...@gnu.ai.mit.edu
>¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
>
>
>[Please redistribute wherever appropriate.]
>
>
>
> Why you should not use Tcl
> Richard Stallman, GNU Project
>
>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.
>
>The principal lesson of Emacs is that 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!
>
>Extensions are often large, complex programs in their own right, and
>the people who write them deserve the same facilities that other
>programmers rely on.
>
>The first Emacs used a string-processing language, TECO, which was
>inadequate. We made it serve, but it kept getting in our way. It
>made maintenance harder, and it made extensions harder to write.
>Later Emacs implementations have used more powerful languages because
>implementors learned from the problems of the first one.
>
>Another lesson from Emacs is that the way to make sure an extension
>facility is really flexible is to use it to write a large portion of
>the ordinary released system. If you try to do that with Tcl, you
>will encounter its limitations.
>
>Tcl was not designed to be a serious programming language. It was
>designed to be a "scripting language", on the assumption that a
>"scripting language" need not try to be a real programming language.
>So Tcl doesn't have the capabilities of one. It lacks arrays; it
>lacks structures from which you can make linked lists. It fakes
>having numbers, which works, but has to be slow. Tcl is ok for
>writing small programs, but when you push it beyond that, it becomes
>insufficient.
>
>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.
>
>For these reasons, the GNU project is not going to use Tcl in GNU
>software. Instead we want to provide two languages, similar in
>semantics but with different syntaxes. One will be Lisp-like, and one
>will have a more traditional algebraic syntax. Both will provide
>useful data types such as structures and arrays. The former will
>provide a simple syntax that hackers like; the latter will offer
>non-hackers a syntax that they are more comfortable with.
>
>Some people plan to use Tcl because they want to use Tk. Thankfully,
>it is possible to use Tk without Tcl. A Scheme interpreter called STk
>is already available. Please, if you want to use Tk, use it with STk,
>not with Tcl. One place to get STk is from
>ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
>
>

--
: stephen benson : : : : : : : : step...@scribendum.win-uk.net


Robin Windels

unread,
Jul 8, 1995, 3:00:00 AM7/8/95
to
lw...@netlabs.com (Larry Wall) wrote:

>Larry Wall
>lw...@netlabs.com

<chuckle> But Mahler's 2nd - 'Resurrection' requires two full orchestras
to perform, whereas most Handel can be performed with half the orchestra
missing (ok make sure you've got at least one of each).

To be sure, Mahler's work is brilliant in concept and construction, but
there is a high cost in execution. OTOH, there are others equal in
brilliance but more accessible. (oh dear, the metaphor is breaking down)

Speaking to the original question, for suitability as an embedded language,
I'd have to go with Scheme. The overhead of the language is low and the
structure is rich.

/Robin Windels

Jurgen Botz

unread,
Jul 9, 1995, 3:00:00 AM7/9/95
to
In article <ALAN.95J...@parsley.lcs.mit.edu>,
Alan Bawden <al...@lcs.mit.edu> wrote:
>You can't defend the indefensible -- Scheme is a terrible choice.

Oh boy! Flame city... ;-)

>The most important thing about a extension/scripting language is that
>it be -simple-. It must have a simple easy-to-understand semantics,
>it must have simple easy-to-use data structures, and it must have
>simple easy-to-read syntax. Scheme has none of these, while Tcl and
>Perl have them all.

Scheme was designed to be simple, like Tcl (but unlike Perl) and in the
oppinion of many it succeeded brilliantly.

>Let's take these aspects of simplicity one at a time:
>

>Semantics. Tcl and Perl are based on string substitution.

Tcl is, Perl is not.

Also, this is more syntax than semantics. And you've hit upon a
central issue, because a lot of people's /perception/ of simplicity
comes from syntax rather than semantics. And, it turns out, some
people are a lot more comfortable with strings and others are a lot
more comfortable with parenthesized lists.

>What could be simpler? Scheme has closures and continuations. Even
>graduate students at MIT are confused by that stuff.

Closure is not any more complicated a concept than object
encapsulation. Unfortunately it is rarely explained well and because
not many languages use closure many people have only a vague notion of
what it is or why it is useful. And it is /very/ useful for such a
simple concept!

>Data structures. Tcl and Perl have strings. And basically, that's -all-
>they have.

Strings are fundamental types, not structures.

All three languages have a small set fundamental types.

But I really think you should learn Perl before spouting off about it
like this. Perl does not represent everything as strings.

>But strings are universal -- you can represent anything using
>strings. And strings are simple. Heck, if everything is a string, you
>don't even need a garbage collector!

Bzzzt. How you manage your memory has nothing to do with what your
fundamental types are. And btw., in case you haven't noticed, you
can ``represent anything'' as binary numbers, too. That doesn't mean
you'd want to.

>Furthermore, everything else in a

>modern computer is based on tools that consume and produce strings, so Tcl
>and Perl fit right in. Scheme doesn't even have a foreign function
>interface, so you can't glue a Scheme program together with -anything-.

Bzzzt. There are several Scheme packages that embed into C programs
much the same way as Tcl. Unless you want to do your linking
dynamically where you don't know the target language until run-time
(in which case you get into an area of active research and standards
battles) this is purely an issue of the specific implementation.

Back to simple data structures; Scheme (like Lisp) has the ordered pair
as a fundamental type and all data structures are built from this. It is
a very simple concept that lets you build anything you want. My experience
with Lisp in college was that the typical student learned to build complex
data structures and abstract types much more quickly with Lisp than with
C/Pascal. Also people tend to use abstraction more effectively with Lisp,
especially in small programs (such as you would write a lot in an extension
language) because it is simpler (and less verbose) to do so.

>Syntax. We all learned infix syntax in grade school. `x + 2*y' is
>concise, familiar and easy-to-read.

I used an HP calculator in grade school. Reverse-polish. I found it
easier then and still do.

Not that I have a problem with infix on the level of `x + 2*y', but
when you're talking about all the types of expressions you typically
find in a programming language, most people can't seem to remember all
the precedence rules. Look at some random source code... a lot of
expressions are over-parenthesized because the author wasn't sure of
precedence and rather than wasting time looking it up played it safe.
Sure, you can do that and never bother learning the precedence rules,
but if you're parenthesizing everything anyway, where's the difference
from Lisp?

In any case, syntax is a lot more than the form of arithmetic
expressions. Scheme's syntax is arguably the simplest possible:
everything is a parenthesized list, there are no special cases, no
exceptions, no precendence rules. What could be simpler? ;-)

>In Scheme you have to write
>`(+ x (* 2 y))'. Only an idiot would prefer to write that.

Since I prefer ``to write that'' (at least in the general sense of
more complicated expressions), you are calling me an idiot. You, Sir,
are an asshole.

>Wise up. Flush Scheme.

Wise up. Learn that a) a lot of your perceptions stem from ignorance
and you don't even understand what the fundamental differences and
similarities of these langauges are, and b) different people have
>different preferences.

P.S.: I like Perl a lot and do a lot more Perl programming than
Scheme. But this is because I'm a sysadmin and Perl lends itself
better to my problem domain in most cases. As a general purpose
extension language I prefer Scheme. Also, you do Perl a great
discredit by equating it with Tcl througout your post.


Erik Naggum

unread,
Jul 9, 1995, 3:00:00 AM7/9/95
to
Alan Bawden wrote me to tell me he didn't mean a word of what he wrote, and
that he wanted to sound like a Scheme-hater. well, he did. others also
commented that Alan has written many articles in defense of Scheme. I did
get somewhat suspicious by the LCS.MIT.EDU address, but posted, anyway,
since it was impossible to detect the sarcasm unless one more or less knew
Alan personally. a newsgroup should be less personal than that, or we end
up wasting a lot of time not "getting" inside jokes. anyway...

[Jurgen Botz]

| Back to simple data structures; Scheme (like Lisp) has the ordered pair
| as a fundamental type and all data structures are built from this.

the vector is also a fundamental type, and may be more useful for building
data structures than lists. many new Lisp and Scheme programmers tend to
think of the list as the only fundamental type, often causing slow code.

#<Erik 3014294464>

Marcus Daniels

unread,
Jul 9, 1995, 3:00:00 AM7/9/95
to
>>>>> "Erik" == Erik Naggum <er...@naggum.no> writes:
In article <19950709...@naggum.no> er...@naggum.no (Erik Naggum) writes:

Erik> since it was
Erik> impossible to detect the sarcasm unless one more or less knew
Erik> Alan personally. a newsgroup should be less personal than that,
Erik> or we end up wasting a lot of time not "getting" inside jokes.
Erik> anyway...

Alan Bawden should consider the cartoon business. He could really
give Scott Adams some competition!

Stefan Monnier

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
In article <19950709...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
] since it was impossible to detect the sarcasm unless one more or less knew
] Alan personally. a newsgroup should be less personal than that, or we end

Sorry, but it seemed obvious to me he was kidding (even though I don't know him
at all. Of course the lcs.mit.edu was a confirmation): the arguments were so
"true" (I really enjoyed the "even graduates get confused") !

Thanks Alan,


Stefan

Stefan Monnier

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
In article <19950710...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
] up over his article. he _did_ give an exceedingly good impression of a
] Scheme hater. but now we'll think that rabid Scheme haters are only
] joking, and I think that's going to cause those who don't know the Scheme

Nope. A scheme hater wouldn't talk about "easy-to-understand semantics", he
wouldn't know continuations exist and finally wouldn't be able to tell the
difference between a language and an implementation (which rules out the "scheme
doesn't even have an FFI"). The post was to well informed to be from some idiot
believing the Tcl or Perl is simple !


Stefan "who's tired of having to add smileys everywhere because there's
always someone not wise enough to discover sarcasm"

br...@liverpool.ac.uk

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
>>>>> "Matthias" == Matthias Blume <bl...@dynamic.cs.princeton.edu> writes:

> We've been through this. Guile is *not* Scheme. It may be based on
> Scheme, but don't call it Scheme! (Otherwise I will no longer say I
> like Scheme.. :)

It's very close to Scheme, though. Close enough that I suspect most
people won't notice the differences. The extensions are noticeable,
of course, but that's not a surprise.

Jurgen Botz

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
In article <19950709...@naggum.no>, Erik Naggum <er...@naggum.no> wrote:
>| Back to simple data structures; Scheme (like Lisp) has the ordered pair
>| as a fundamental type and all data structures are built from this.
>
>the vector is also a fundamental type, and may be more useful for building
>data structures than lists.

Good point. The heat of the moment...

>many new Lisp and Scheme programmers tend to
>think of the list as the only fundamental type, often causing slow code.

*grin*... not as slow as when "all you have" are strings.

-j


Matthias Blume

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to

> Scheme doesn't even have a foreign function interface, so you can't
> glue a Scheme program together with -anything-.

Choose an implementation. For example, Guile. Gosh, it's got two


foreign function interfaces, one compatible with Tcl's.

We've been through this. Guile is *not* Scheme. It may be based on


Scheme, but don't call it Scheme! (Otherwise I will no longer say I
like Scheme.. :)

> Syntax. We all learned infix syntax in grade school. `x + 2*y' is
> concise, familiar and easy-to-read. In Scheme you have to write `(+


> x (* 2 y))'. Only an idiot would prefer to write that.

Or rather [expr $x+2*$y]. But yes, it's still better. But Guile has


(or will have RSN) a C-like syntax, translated automatically to Scheme.

Yikes!

--
-Matthias

Matthias Blume

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
In article <19950707...@naggum.no> er...@naggum.no (Erik Naggum) writes:

[Alan Bawden]

| Syntax. We all learned infix syntax in grade school. `x + 2*y' is
| concise, familiar and easy-to-read. In Scheme you have to write
| `(+ x (* 2 y))'. Only an idiot would prefer to write that.

I'm surprised that those who argue against Scheme only use computers to do


arithmetic exercises from grade school. that is such a lame criticism that
I wonder about the mental capacity with which those who make such arguments
must be endowed.

Are you guys blind?! Didn't you see all the smileys (or frownies) in
Alan's article?! Knowing Alan's background and the extend of his
contributions to Scheme I can't imagine him advocating _Tcl_ (for
crying out loud!) over Scheme. He may have his gripes with the current
state of affairs in Scheme (and rightfully so), but still...

folks, you should look at the intellectual honesty of the critics of the
various suggested languages.

Erik, DON'T accuse Alan Bawden of intellectual dishonesty, please!

--
-Matthias

Erik Naggum

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
[Matthias Blume]

| Are you guys blind?! Didn't you see all the smileys (or frownies) in
| Alan's article?! Knowing Alan's background and the extend of his
| contributions to Scheme I can't imagine him advocating _Tcl_ (for
| crying out loud!) over Scheme.

right. that's what I said in a followup, as well: you have to know Alan's
background and the extent of his contributions to Scheme to understand that
he was joking.

of course, it's embarrassing to fail to understand very good inside jokes,
but I find some consolation in the fact that more people than I got worked


up over his article. he _did_ give an exceedingly good impression of a
Scheme hater. but now we'll think that rabid Scheme haters are only
joking, and I think that's going to cause those who don't know the Scheme

community sufficiently well to know that Alan's was a joke and the others
aren't to hold back their comments, leading to more people actually
believing that Scheme's crap.

I think it's important that people reacted to Alan's article. at least we
have managed to communicate to all of us on the fringes of the community
that we have some darn clever folks in the center of said community, and
that those almost-but-not-quite-absurd criticisms of Scheme weren't real.

sorry for being such a spoilsport, but this is the first time I think I had
a right not to "get" some joke. it was too clever for its own good. OK,
so I didn't pass the secret rites of entry to the community. maybe later.

#<Erik 3014332589>

Alan Bawden

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
In article <MARCUS.95...@plato.icc.pdx.edu>
mar...@icc.pdx.edu (Marcus Daniels) writes:

In article <19950709...@naggum.no>
er...@naggum.no (Erik Naggum) writes:

Erik> since it was impossible to detect the sarcasm unless one more or
Erik> less knew Alan personally. a newsgroup should be less personal
Erik> than that, or we end up wasting a lot of time not "getting" inside
Erik> jokes. anyway...

Damn -- Erik blew my cover! I guess I shouldn't have admitted to him in
private that I was kidding around.

Actually, several people I have never met indicated that they understood
what I was up to: I figured that if we were going to have to sit through
the stupid Scheme-vs-Tcl discussion for the tenth time, this time I'd see
what it was like to be on the other side, and perhaps I could push the
discussion someplace amusing.

The people who pointed out that I didn't know anything about Perl are
probably correct.

Alan Bawden should consider the cartoon business. He could really
give Scott Adams some competition!

High praise indeed. Thanks, man, that's the best
endorsement I've received all year!

Christian Lynbech

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
>>>>> "Robin" == Robin Windels <rwin...@islandnet.com> writes:

Robin> lw...@netlabs.com (Larry Wall) wrote:
>> In article <3tio9c$t...@omega.gmd.de>, Tom Gordon <thomas...@gmd.de> wrote:
>> : p.s. About Scheme being "ugly". Experience shows that there is no
>> : point in arguing this issue. Many, including myself, find Scheme
>> : elegant and beautiful --- especially compared to baroque languages
>> : like TCL and Perl.

>> While I do consider the adjective "baroque" to be a compliment, I must
>> point out that Perl is actually more of a romantic piece, with allusions
>> to various classical motifs. My favorite composer is Mahler, which should
>> surprise no one.

>> Larry Wall
>> lw...@netlabs.com

Robin> <chuckle> But Mahler's 2nd - 'Resurrection' requires two full orchestras
Robin> to perform, whereas most Handel can be performed with half the orchestra
Robin> missing (ok make sure you've got at least one of each).

I think that comparing Perl to a symphony is unfair. Think a piano
piece by Chopin instead, with all its rich expression, and the
metaphor holds better.

Scheme could be a baroque organ piece. Requiring a larger instrument
but still playable by the individual, and though the structure seems
utterly complex to the untrained ear, it still has a strict, almost
mathematic, and highly characteristic form.


------------------------------------------------------------------------------
Christian Lynbech (R0.33) | Hit the philistines three times over the
phone: +45 8942 3217 | head with the Elisp reference manual.
email: lyn...@daimi.aau.dk | - pet...@hal.com (Michael A. Petonic)
------------------------------------------------------------------------------


Paul Haahr

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to Chak Tan
Chak Tan <t...@tesla.ee.rochester.edu> wrote:

> AB> Heck, if everything is a string, you don't even need a garbage
> AB> collector! Furthermore, everything else in a modern computer
>
> Can you explain this to me? How does using only strings eliminate the
> need for a garbage collector? I'll have to think about this one.

Strings can't have circular references, so reference counting or one
copy per string works fine.

Larry Wall

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to
In article <LYNBECH.95...@xenon.daimi.aau.dk>,
Christian Lynbech <lyn...@xenon.daimi.aau.dk> wrote:
: I think that comparing Perl to a symphony is unfair. Think a piano

: piece by Chopin instead, with all its rich expression, and the
: metaphor holds better.

Oh, I dunno. Mahler expressly expressed that he tried to put the whole
world into each of his symphonies. Seems appropriate somehow. :-)

Actually, even Mahler backed off a little in his (relatively) old age.
The 9th and 10th symphonies were more restrained, just as Perl 5 is
more restrained in some ways. Mahler's 10th is my favorite symphony,
probably because I performed it twice in the Seattly Youth Symphony,
once with the 2nd fiddles, and once with the 1st. Lots of fun--seems
the parts that aren't in 6 sharps are in 7 flats...

: Scheme could be a baroque organ piece. Requiring a larger instrument


: but still playable by the individual, and though the structure seems
: utterly complex to the untrained ear, it still has a strict, almost
: mathematic, and highly characteristic form.

If we're going to switch to the instrument metaphor, then I'd say
Scheme is a church organ and Perl is a theatre organ.

Larry

Edwin Petrus

unread,
Jul 10, 1995, 3:00:00 AM7/10/95
to esp
"Scipting" and "Extension" should be seperated for the purposes of discussing
extension language merits for CFI.

I don't know when "scripting" blurs into "extension" but in most cases
where a CAD extension language is deployed, users tend to write large
programs that exercise the depth and breadth of the tools Framework
visible through the language. It is common to see software
packages consisting of tens of thousands of lines of code written
in an extension language (el).

Here are some requirements I would set out for a CAD extension
language (a dynamic and machine architecture independent language is assumed ) :

1. Scalable
For large sized software projects, it is important
for the el deployed to be scalable. The language must
be rich in semantics both for expressing data and control.
e.g. can it present a comprehensible view of an object oriented
database model? Event driven GUIs? Synchronous and
asynchronous networking?

2. Small.
Realize the core implementation in 250-500K size library

3. Extensible
Two levels: foreign function interface & meta-programming.
the second is critical for implementing command languages
to drive tools and specialized languages (e.g. test pattern generators,
procedural database objects)

4. Portable
Should not have dependencies on specific operating system features.
i.e. it should be portable to unix, windows, os2, mac, etc.

6. Public, standard, available, familiar.

These are some requirements I know of. I also know that to try and choose
one language that best fits the requirements will make many people happy and will
leave many others unsatisfied (hence, why we are talking about a CFI el again -
the matter was settled five years ago).

This is a basic problem. How can you accommodate the person who is likely
to write 50K lines of code and at the same time make the 50 lines script
writer productive; or make the ones who are inseperable form their favourite
language of the day happy (e.g. perl, tcl, python, scheme, smalltalk, visual
basic).

I can at least say the answer is not academic. Syntax is a secondary issue.
Foreign function interfaces can be added to any language implementation.

Scheme gives a Framework a powerful, scalable, portable an extensible
foundation. It is easy to start with a very small raw implementation. If
the implementaion is designed well, many other dynamic languages can
be targeted to the same implementation. The tcl follower need not be deprived
(see architecture of GUILE).

The goal for CFI should be to declare a common language that
can meet the above requirements. Users (customers) can vote with
their money for the vendor that best satifies their needs - for extension
and scripting. That is, customer satisfaction is a marketing problem.
For example, A design outfit that relies heavily on, say perl, can
favor the CAD supplier with perl access. Likewise for tcl and others.

It is crucial for CFI to satisfy the technical requirements for
inter-operability. This goal must not be blurred by issues surrounding the
favourite language of the day. Successful vendors will leverage the CFI decision
to satisfy their cusotmers' needs in the areas of tools and Frameworks
extensibility.

-----------------------------------------------------------------------
Edwin S. Petrus
Sr. Engineering Manager,
Cadence Design Systems, Inc.

e...@cadence.com
408-985-4271


Steven D. Majewski

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to
In article <3thlus$i...@hpbab.wv>,

Joe Mueller <jo...@aardvark.mentorg.com> wrote:
>
>Some time ago there was a raging debate over the virtues of Tcl vs. Scheme
>as an extension/scripting language. Unfortunately I did not capture the
>major pros/cons at that time. Could someone send me a synopsys of the major points?
>

There are pointers to archives and material from that debat on my
Programming Languages Critiques Web Page at :
<http://minsky.med.virginia.edu/sdm7g/LangCrit/>

( specifically, in:
<http://minsky.med.virginia.edu/sdm7g/LangCrit/Tcl/>
There are a selection of posts by Richard Stallman, John Ousterhout,
Adam Sah and others, and pointers to Adam Sah's critiques and papers
and to a more full archive of the discussion. )

Re: the comments in this thread that tcl's string substitution is easier
to understand than scheme's continuation and closures:
- string substitution may be a simple *concept*, but in practice, it
is subtle and confusing when you can have several levels of
substitution - especially when some substitutions are explicit
and other are implicit.
- excluding continuations, scheme's evaluation model is remarkably
simple and unambiguous ( simpler that tcl IMHO ). ( Continuations
are also simple in concept, but can get pretty baroque in practice.
In average use, I think you are more likely to manage to avoid the
baroque extremes of scheme continuations that you will be able to
avoid strange side effects of string substitution. )

A string based language may be a good idea for a command language:
it avoids a lot of quoting and unquoting by making the defaults
for commands simpler. That's clearly why tcl followed the unix shells
in that respect. However, this initial simplicity, which works fine
for commands and short scripts, tends to make things even more complex
in less simple programs. So I think it's important to consider what
sort of programs or scripts will be written in this language.


Tcl is good for what it was designed for, but we are seeing it
being used for all sorts of things for which it wasn't designed
and for which it is ill suited. Oh well: "When all you have is
a hammer, everything starts to look like a nail!"


Tcl is not really much less complex that scheme, and certainly not
any easier to understand. However, there *really* are some applications
where a string substitution language makes sense. Nathaniel Borenstein,
for example, chose SafeTcl to build his Enabled Mail system, after
having done an earlier attempt at the same sort of thing with
AtomicMail - which was, I believe, a lisp based system. So I would
suggest you think quite a bit about the requirements and then actually
try prototyping in a couple of the more likely candidate languages.

BTW: Another language to consider is Python - especially if a "user
friendly" syntax and an easy to learn language are requirements.
See <http://www.python.org/>

[ Followup changed to comp.lang.misc and crossposted there. ]

Aaron Watters

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to
In article writes:
>To my mind the most telling arguments favoring Scheme over TCL or Perl
>for scripting use are its superior support for prototyping data structures
>and novel flow-control schemata, and superior reflection: While it is
>simple to represent perl code in strings to be manipulated by perl code,
>it is less trivial to perform the actual manipulations. Providing better
>encouragement for lexical scoping can't hurt either.

Yep, lexical scoping is nice, and nice, general, easily constructed data
structures can be fun, and it's even more fun to create your
own language by inventing (say) your *very own error handling
techniques*. But that last one is a bit problematic because
any two programmers will do error handling differently, and the next
programmer to read the stuff will never figure out what the hell
is going on, not to mention the original programmers four days later.
That last one is also the only one that *Python* lacks, and I
think for collaborative software development this lack is probably a
good thing.

Extension languages must also be easily extended with compiled
extensions. This is the only advantage to tcl in my opinion, and one
disadvantage to perl (as far as I can tell, although I've been told
otherwise by some). Dunno about others [guile,eg], but I do know that
Python is remarkably easy to extend, and many extensions exists to
prove it.

http://www.python.org http://hertz.njit.edu/~aaron

Joe Mueller

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to
In article <ALAN.95Ju...@parsley.lcs.mit.edu>, al...@lcs.mit.edu (Alan Bawden) writes:
|> what I was up to: I figured that if we were going to have to sit through
|> the stupid Scheme-vs-Tcl discussion for the tenth time, this time I'd see
|> what it was like to be on the other side, and perhaps I could push the
|> discussion someplace amusing.

I would be perfectly happy to be pointed to an archive of the TCL vs. Scheme debate. I
hardly call the discussion "stupid" when what's at stake is an industry-wide standard
for extension languages. We picked Scheme, but are now trying to gather information to
defend against the Tcl/Perl fans. If you don't want to read the discussion, skip the
thread (rather than wasting everyone's time by contributing noise).

I've never seen a discussion of Perl vs. Scheme, (or if there has been one, point me
to an archive please).

Tom Lord

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to

jo...@menorg.com writes:

I would be perfectly happy to be pointed to an archive of the TCL
vs. Scheme debate. I hardly call the discussion "stupid" when what's
at stake is an industry-wide standard for extension languages. We
picked Scheme, but are now trying to gather information to defend
against the Tcl/Perl fans. If you don't want to read the discussion,
skip the thread (rather than wasting everyone's time by contributing
noise).

A Scheme interpreter is a good choice for an extensible program
because it is likely to be small, efficient, and amply powerful.
There is lots of historical evidence that lisp dialects are the best
adapted extension languages going.

But it seems likely that there will always be people who dislike lisp
dialects, largely for syntactic reasons but also because lisp is not
{Tcl, Perl, Basic,...}.

A technical solution (that of the Guile project) is to build an interpreter
around Scheme, but then provide translators-from and interfaces-to other
languages. This repeats a tried-and-true pattern:

Unix is a C-based operating system. All of the system libraries and
interfaces are written or specified in C. This is a good, practical
choice that accelerated and helped to organize the development of
Unix.

But today people are able to write Unix programs in Fortran, C++,
Pascal, Cobol, Intercal, Ada or whatever langauge they like. They are
able to because processors are (more or less) language neutral, and
run-time systems can be unified as well. (Those languages implemented
by a translator-to-C have an especially easy time fitting into a
C-oriented environment.)

To make the analogy explicit, a Scheme interpreter can run other
languages as well, or in extreme cases, it can call-out to
interpreters for other languages.

So, choose Scheme as a practical way to accelerate and organize
development around, for example, CAD tools. Then build complementarty
support for other languages to make more users happy.

Something you could say to a fan of a limited (by design) language
like Tcl is: "If we choose Tcl as the standard, everyone who wants a
stronger language is left out in the cold. But by choosing a stronger
language in the first place, even Tcl fans can be accomidated. So,
the choice of Scheme is more democratic and more practical."

-t

http://www.cygnus.com/library/ctr/guile.html

Bill Janssen

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to
In article <3tkdc2$4...@tesla.ee.rochester.edu> t...@tesla.ee.rochester.edu (Chak Tan) writes:

I think the choice of languages will be decreasingly important in the
future with the emergence of language neutral tools like ILU form PARC
Xerox, Guile from FSF, and the JavaVM from Sun. Perhaps your group
can concentrate on building a scheme interface to ILU or get involved

More ILU info at ftp://ftp.parc.xerox.com/pub/ilu/ilu.html.

I'd love to see an Guile support (or ELK, or ...) for ILU. George
Carrette mentioned some time ago that he was looking at doing it for
SIOD, but I haven't heard anything since.

With regard to extension languages, scheme is a good choice compared
to Perl and Tcl, being quite simple, more so than Perl, and quite
powerful, much more so than Tcl (and being also more efficient than
Tcl). Another favorite of mine is Python, which is close to the best
scripting language I've ever come across. The appeal as an extension
language comes from its BASIC heritage, over several removes. More
Python info at http://www.python.org/.

Bill

--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html

Matthias Blume

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to
In article <19950710...@naggum.no> er...@naggum.no (Erik Naggum) writes:

[Matthias Blume]

| Are you guys blind?! Didn't you see all the smileys (or frownies) in
| Alan's article?! Knowing Alan's background and the extend of his
| contributions to Scheme I can't imagine him advocating _Tcl_ (for
| crying out loud!) over Scheme.

right. that's what I said in a followup, as well: you have to know Alan's
background and the extent of his contributions to Scheme to understand that
he was joking.

Well, I have never met Alan personally, but I did read the top section
of R4RS (where they say who contributed). Also, a look at the
bibliography can be very telling...

sorry for being such a spoilsport, but this is the first time I think I had
a right not to "get" some joke. it was too clever for its own good. OK,
so I didn't pass the secret rites of entry to the community. maybe later.

I admit, there's some truth in it, too. Even I briefly wondered if
Alan's article is for real, but then it quickly became obvious that it
isn't. I've been guilty of not being well-informed before posting in
the past myself, and I can't say it won't happen again either. Let it
be a lesson. Take it as a reminder to check who it is who you are
responding to...

Cheers...
--
-Matthias

Tony Kimball

unread,
Jul 11, 1995, 3:00:00 AM7/11/95
to
Chak Tan (t...@tesla.ee.rochester.edu) wrote
: Well, I disagree here. Scheme, too, is simple and elegant, has very
: straight forward and consistent semantics...

Hmm. Wasn't that the *point* of scheme? Simple semantics.

I'd *love* to see a finished formal sematics of Perl5 (plus, say,
Solaris 2.3), but I'd hate to see the lives lost in producing it:-)

: AB> Even graduate students at MIT are confused by that stuff.

I think it's a leg pull.

: AB> Data structures. Tcl and Perl have strings. And basically,

: I think Perl has scalars, arrays of scalars, and associative arrays of
: scalars where scalars can be a string, a number, and a reference which
: are internally represented in a efficient manner (i.e. not as strings).

Yes, typeglobs (selah!) and hard references and soft references and...
Typeglobs, though. May God have mercy on us all.

: AB> Heck, if everything is a string, you don't even need a garbage


: AB> collector! Furthermore, everything else in a modern computer

: Can you explain this to me? How does using only strings eliminate the
: need for a garbage collector? I'll have to think about this one.

Ah, but if you had simply put quotes around it, you wouldn't have *had*
to think about it, see!?!

To my mind the most telling arguments favoring Scheme over TCL or Perl
for scripting use are its superior support for prototyping data structures
and novel flow-control schemata, and superior reflection: While it is
simple to represent perl code in strings to be manipulated by perl code,
it is less trivial to perform the actual manipulations. Providing better
encouragement for lexical scoping can't hurt either.

It is the lack of builtin regexp and structure matching that hurts scheme
in this area more than any other deficiency, along with the failure to
standarize FFIs. Even C++ managed better than Scheme on that last count,
leave alone CL, Sather, Ada, et al. But these areas of deficiency can
be fixed easily, as numerous implementations have demonstrated; whereas
extending TCL or Perl to overcome those of their deficiencies which are
among Scheme's strong points would be a vexatious, if not contradictory,
effort.


Matthias Blume

unread,
Jul 12, 1995, 3:00:00 AM7/12/95
to
In article <HAAHR.95J...@netcom8.netcom.com> ha...@netcom.com (Paul Haahr) writes:

Chak Tan <t...@tesla.ee.rochester.edu> wrote:

> AB> Heck, if everything is a string, you don't even need a garbage
> AB> collector! Furthermore, everything else in a modern computer
>
> Can you explain this to me? How does using only strings eliminate the
> need for a garbage collector? I'll have to think about this one.

Strings can't have circular references, so reference counting or one


copy per string works fine.

Well, again, AB's remark was a *joke*. GC in strings-only languages
isn't needed, because it can't be done at all. Most of these
languages use calls to the interpreter on such strings as a means to
achieve some sort of indirection (or `pointer') through variable
names. Since you never know what the program is going to cook up as a
string that is later passed to EVAL you have to keep *everything* (in
the interpreter's symbol table). That means: back to good old
hand-crafted memory-management.

In a sense strings are used as `addresses' in such languages, and they
are used to `index' into a set of `locations' represented by the
symbol table. Since you can do anything to strings (and therefore to
your `addresses') you face a situation closely resembling
undisciplined C-hacking, where pointers and integers are cast into
each other all the time...

--
-Matthias

Matthias Blume

unread,
Jul 12, 1995, 3:00:00 AM7/12/95
to

>>>>> "Matthias" == Matthias Blume <bl...@dynamic.cs.princeton.edu> writes:

> We've been through this. Guile is *not* Scheme. It may be based on
> Scheme, but don't call it Scheme! (Otherwise I will no longer say I
> like Scheme.. :)

It's very close to Scheme, though. Close enough that I suspect most


people won't notice the differences. The extensions are noticeable,
of course, but that's not a surprise.

`Close' in what metric? IMO, the two are very far apart, since Guile
has given up on simplicity and lack of redundancy.

Scheme-liness is largely determined by what's NOT in the language as
opposed to what's in. If Guile has a subset that's close to Scheme
then this doesn't mean that Guile itself is close to Scheme. The
extensions are indeed noticable, but not necessarily in a positive
sense.

Anyway, this was my last word on this subject in this forum, because I
know what's going to happen... :(

Regards,
--
-Matthias

br...@liverpool.ac.uk

unread,
Jul 12, 1995, 3:00:00 AM7/12/95
to
>>>>> "Matthias" == Matthias Blume <bl...@dynamic.cs.princeton.edu> writes:

> `Close' in what metric? IMO, the two are very far apart, since
> Guile has given up on simplicity and lack of redundancy.

I meant close in the sense of what changes would be needed to a
typical R4RS compliant program for it to run in Guile. I agree Guile
seems to be gathering a lot of cruft (cruft needed to make it similar
to emacs-lisp).

Some things are unnecessary (except for emacs-lisp compatibility), but
some are surely things that'll get into scheme at some point, simply
because they're so useful, and because it's useful to have only one
implementation. Packages spring to mind.

Harley Davis

unread,
Jul 12, 1995, 3:00:00 AM7/12/95
to

In article <ALAN.95J...@parsley.lcs.mit.edu> al...@lcs.mit.edu (Alan Bawden) writes:

In article <3thlus$i...@hpbab.wv>
jo...@aardvark.mentorg.com (Joe Mueller) writes:

I'm in the workgroup within the CAD Framework Inititiative (a standards
organization for CAD tool developers/users) that is responsible for
Extension Language selection. Some time ago we selected Scheme as the
standard extension language for this organization but have lately come
under fire for not selecting/considering Tcl and Perl as alternatives to
"ugly" Scheme. I would like to get a list of pros/cons for Scheme, Tcl,
and Perl as extension/scripting languages to (hopefully) better defend
the choice of Scheme....

You can't defend the indefensible -- Scheme is a terrible choice.

The most important thing about a extension/scripting language is
that it be -simple-. It must have a simple easy-to-understand
semantics, it must have simple easy-to-use data structures, and it
must have simple easy-to-read syntax. Scheme has none of these,

while Tcl and Perl have them all. Let's take these aspects of


simplicity one at a time:

Nice parody.

Semantics. Tcl and Perl are based on string substitution. What
could be simpler? Scheme has closures and continuations. Even


graduate students at MIT are confused by that stuff.

I think CFI's extended subset Scheme explicitly removed continuations
--- less for confusion than for efficiency, I believe.

Data structures. Tcl and Perl have strings. And basically, that's

-all- they have. But strings are universal -- you can represent
anything using strings. And strings are simple. Heck, if
everything is a string, you don't even need a garbage collector!
Furthermore, everything else in a modern computer is based on tools


that consume and produce strings, so Tcl and Perl fit right in.

Scheme doesn't even have a foreign function interface, so you can't
glue a Scheme program together with -anything-.

CFI Scheme defines an FFI.

-- Harley Davis
--

-------------------++** Ilog has moved! **++----------------------------
Harley Davis net: da...@ilog.fr
Ilog S.A. tel: +33 1 49 08 35 00
9, rue de Verdun, BP 85 fax: +33 1 49 08 35 10
94253 Gentilly Cedex, France url: http://www.ilog.com/


Alan Bawden

unread,
Jul 12, 1995, 3:00:00 AM7/12/95
to jo...@aardvark.mentorg.com, sch...@mc.lcs.mit.edu
Date: 11 Jul 1995 17:45:26 GMT
From: Joe Mueller <jo...@aardvark.mentorg.com>

In article <ALAN.95Ju...@parsley.lcs.mit.edu>,
al...@lcs.mit.edu (Alan Bawden) writes:
|> what I was up to: I figured that if we were going to have to sit
|> through the stupid Scheme-vs-Tcl discussion for the tenth time, this
|> time I'd see what it was like to be on the other side, and perhaps I
|> could push the discussion someplace amusing.

I would be perfectly happy to be pointed to an archive of the TCL vs.
Scheme debate.

I don't know if this newsgroup/mailing-list is archived anywhere public.
The FAQ doesn't mention any archives. I believe that the software that
produces the digests for the mailing-list keeps copies, but I don't know
where they go. It would be useful, in cases like this, if the FAQ pointed
to a searchable archive.

I hardly call the discussion "stupid" when what's at stake is an
industry-wide standard for extension languages.

It's not the magnitude of the stakes that makes such discussions stupid.
It's the quality of the arguments. You simply can't have a high quality
discussion of the sort that you want in a newsgroup. You might get one or
two reasonable messages (the last time we had the Scheme/Tcl debate I think
I counted -two-), but 99% of the heat will be generated by people arguing
about parenthesis or parameter passing in ADA or ...

We picked Scheme, but are now trying to gather information to defend
against the Tcl/Perl fans.

Good for you. I suggest you do your research someplace else. I'm doing
you a favor by telling you this. Learn Tcl yourself. Write some Tcl
programs. Write the same programs in Scheme. Think. Read some journal
articles and conference proceedings. Don't just "ask the net".

If you don't want to read the discussion, skip the thread (rather than
wasting everyone's time by contributing noise).

That works both ways. If you don't like what I write, you can delete my
messages too.

I've never seen a discussion of Perl vs. Scheme, (or if there has been
one, point me to an archive please).

Perl always gets dragged into the debate somewhere. I wish I could point
you to archives, but nobody appointed me librarian.

[ The really weird thing about this discussion is that over the last five to
ten years I have devoted significant effort to discussing the fine points
of Scheme in this forum. The subject of inexact numbers alone probably
shortened my life by several years. And then there's the who macro-system
debacle -- hoo boy. In all that time, I've rarely gotten any positive
electronic mail feedback from anyone -- even though I knew there were other
people who agreed with me. But in response to that -one- message where I
was just clowning around I've received numerous pats on the back of the
form: "Very funny! You made my day.". Says something about the role of
humor in human interaction I guess... ]

Martin Cracauer

unread,
Jul 13, 1995, 3:00:00 AM7/13/95
to
Al...@lcs.mit.EDU (Alan Bawden) writes:

> Date: 11 Jul 1995 17:45:26 GMT
> From: Joe Mueller <jo...@aardvark.mentorg.com>

> I would be perfectly happy to be pointed to an archive of the TCL vs.
> Scheme debate.

>I don't know if this newsgroup/mailing-list is archived anywhere public.

It's archived at CMU, somewhere in the Lisp Repository. I've lost the
exact place, but ask Mark Kantrowitz,
lisp-utilit...@cs.cmu.edu in case you don't find it.

Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@wavehh.hanse.de>. No NeXTMail, please.
Norderstedt/Hamburg, Germany. Fax +49 40 522 85 36. This is a
private address. At (netless) work programming in data analysis.

br...@liverpool.ac.uk

unread,
Jul 13, 1995, 3:00:00 AM7/13/95
to
>>>>> "Joe" == Joe Mueller <jo...@aardvark.mentorg.com> writes:

> I would be perfectly happy to be pointed to an archive of the TCL

> vs. Scheme debate. I hardly call the discussion "stupid" when what's
> at stake is an industry-wide standard for extension languages. We


> picked Scheme, but are now trying to gather information to defend

> against the Tcl/Perl fans. If you don't want to read the discussion,


> skip the thread (rather than wasting everyone's time by contributing
> noise).

Try <URL:http://icemcfd.com/tcl/comparison.html> and
<URL:http://www.utdallas.edu/acc/glv/Tcl/war/>.

The latter also contains some discussions of the relevant GNU project,
which intends to produce a Scheme-like (or Scheme superset, if you
like) which will accept extensions written to Tcl, and which will
ultimately include something Rush-like (Rush being a cleaned-up Tcl
which is translated to Scheme).

Dave Love

unread,
Jul 13, 1995, 3:00:00 AM7/13/95
to jo...@aardvark.mentorg.com
>>>>> In article <3tudbm$g...@hpbab.wv>, jo...@aardvark.mentorg.com (Joe Mueller) writes:

> I would be perfectly happy to be pointed to an archive of the TCL
> vs. Scheme debate.

I think there's a pointer through Sah's Tcl critique at
ftp://ginsberg.cs.berkeley.edu/pub/asah/papers/tcl-fear.html. This
group/list is or was archived somewhere at swiss-ftp.ai.mit.edu and
the CMU repository (see FAQ?). However, the impression I got was that
the people who know what they're talking about -- ones who have been
building systems with extension languages for a decade or more, for
instance -- were largely keeping a dignified (amused?) silence.

> We picked Scheme, but are now trying to gather information to
> defend against the Tcl/Perl fans.

I guess the point is that you had good reasons and they're presumably
still valid. What isn't clear is whether these proponents want `the'
Tcl and Perl implementations or some vaguely look-alike more-or-less
grotty language. If the latter, then Scheme is a perfectly fine
language in which to implement the new one. One of the touchstones of
a good extension language IMHO should be the extent to which you can
build a system entirely within it (which might imply it's compilable
to native code). [Guile currently seems to be letting the side down
here.]

If people want Tcl/Perl -- why not Python, at least? -- as defined by
their (current?) implementations, then assuming these really can be
cleanly embedded and your CAD system can load random library code,
presumably there's nothing to stop them embedding the things anyway
and evaluating the relevant stuff through the Scheme interface if they
want to and everyone should be happy, if not all equally successful.

Richard A. O'Keefe

unread,
Jul 17, 1995, 3:00:00 AM7/17/95
to
For years I have enjoyed, used, and been a proponent of Lisp-like languages,
specifically including Scheme. I would include Pop-11 and Prolog in the
Lisp family.

However, more and more I am coming to the conclusion that
- just because it's a script, or
- just because it's an extension, or
- just because it's a prototype
that DOESN'T mean that lots of static checking isn't helpful.

I think this is one of the things that can make Scheme a very good choice
*when combined with appropriate tools*. Several people have worked on
static or semi-static type systems for Scheme, such as Soft-Scheme.

When Alan Mycroft and I wrote our Milner-style type checker for DEC-10
Prolog, it found an *amazing* number of errors. In fact, I can say that
every time I have run a new static checker of some kind on bodies of
existing code I have found long-hidden mistakes.

I am not advocating discipline-and-bondage; I am not advocating changes to
Scheme. My message is just that static type checking _when you want it_
can be a _very_ powerful debugging tool, that extensions/scripts need
debugging too, and that *add-on* static checks for Scheme are already
available or a topic of study, which makes Scheme a good choice.
--
"The complex-type shall be a simple-type." ISO 10206:1991 (Extended Pascal)
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

Przemek Skoskiewicz

unread,
Jul 24, 1995, 3:00:00 AM7/24/95
to
Dave Love (d.l...@dl.ac.uk) wrote:
: [...]
: If people want Tcl/Perl -- why not Python, at least? -- as defined by

: their (current?) implementations, then assuming these really can be
: cleanly embedded and your CAD system can load random library code,
: presumably there's nothing to stop them embedding the things anyway
: and evaluating the relevant stuff through the Scheme interface if they
: want to and everyone should be happy, if not all equally successful.

In CAD/CAE/CAM systems the power of the extension language is not necessarily
its ability to embed dynamically third party libraries. If that was the case,
the main requirement would be the ease of dynamic loading/linking of foreign
language libraries.

The main issue in such systems is the availability of the CAE system's PI in
the extension language. Not many users want to load in their own numeric
computation library into a CAE system. But they *do* want to get at the
design data stored in the CAE database, or to change or add GUI widgets, or to
integrate two CAE systems together with a common GUI.

In my view, the above requirements favor Scheme as a CAD extension language.
The compactness, portability and expressive power make it easier to support
major functionality extension and configuration changes that suit CAE users.


Lastly, the fact that in the CAE industry the three major vendors all have
extension languages based on either Scheme or Lisp (and have had them for many
years) should provide some weight in the discussion. As far as I'm aware,
neither one of them made the decision lightly.


Disclaimer:

I represented Viewlogic at the CAD Framework Initiative working group which
selected Scheme as the base of the CFI Extension Language standard.

--
Viewlogic Systems, Inc. Przemek Skoskiewicz
293 Boston Post Road West
Marlborough, MA 01752-4615, USA
email: prz...@viewlogic.com

0 new messages