scsh-users
[Top] [All Lists]

Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)

To: scsh@martigny.ai.mit.edu
Subject: Re: Reply to Ousterhout's reply (was Re: Ousterhout and Tcl ...)
From: mls@panix.com (Michael L. Siemon)
Date: Thu, 17 Apr 1997 22:42:06 -0400
Organization: University of Ediacara
In article <5j2p70$hj0@news.istar.ca>, hclsmith@tallships.istar.ca (Hume
Smith) wrote:

+In article <335476A5.18EA@maths.anu.edu.au>, graham.matthews@maths.anu.edu.au 
+says...

+>Michael L. Siemon wrote:

+>> Sorry, but that does not follow. Bijections are all very well...
+>> but human predispositions are relevant

+>You have missed the point! I am arguing against the claim that
+>"everything is a string is so *powerful*". This claim is rubbish since
+>"everything is a list" is just as powerful.

No, I did not miss your point. Read my remark again. I freely acknowledge
the mathematical equivalence, and equal "power" of string, list, and other
representations.  Bijections are all very well, but...

+"everything" is a list. hmm.  so what should this do:
+        ((()((()((()()))(()))))((()())))
+i think we'd want a little more than just lists. 

This misunderstands Mr. Matthews's point. One can easily enough construct
integers from lists (start with the empty list; then make a list comprising
the empty list; then a list whose single element is a list whose single
element is the empty list; etc. -- among several different methods of doing
effectively the "same" thing. Or you could read Whitehead and Russell :-)).

Once you have integers, you can map an alphabet. Lo, you get strings as a
fallout from playing with lists. No big deal.

And Lisp (at least, Famous Original Lisp :-)) is vastly more elegant with
its simple list formation and lambda operation than TCL can hope to be (I
mean, God help us when we have to deal with crap like the octal number
problem! let alone the vagaries of which commands do and which do not
perform a second round of evaluations....)  Admittedly, as you note, more
modern Lisps have a lot of ugly excrescences too:

+not even Lisp constrains us 
+to just lists; it's got symbols, namespaces, strings, characters, umpteen
kinds 
+of numbers; some lisps have structures, objects, classes, closures...

Ayup.

However, Mr. Matthews seems not to have grasped my point, which you and
other TCL users know implicitly. That for the most part, for ordinary
human purposes, everything *does* start from and return to representation
by strings -- and hence, as a principle of least surprise, a language like
TCL which (aside from warts like octal integers :-)) does what most of
us ourselves usually do with strings, has a TREMENDOUS advantage over the
mathematically "equivalent" but mostly non-congenial alternative languages.

I have toyed with Lisp (for decades :-)), and with Prolog, and with a
few others -- and I am a sucker for elegant constructs. But I have never
felt that it would do me, or any user of any of my programs, any good to
have, e.g. a lambda calculus available for their casual use. On the other
hand, I *jumped* at the opportunity to plug TCL into my GUI-testing program
and have not only not regretted it, but been *amazed* at how productive I
and my users can be without a rigorous mathematical discpline in using it.
I can get my users (some of them :-)), to wrap their heads around TCL and
its occasionally non-intuitive behavior. Trying to train them into any kind
of "intuition" of a functional programming language is, IMO, hopeless.

TCL actually operates moderately well as a list-processing language; in
that way (and others) it strikes me as being rather like "Lisp meets the
Bourne shell" -- and wins hands down. That it has this shell usage *and*
its delightfully easy embeddability into existing (or projected) programs
is plenty of reason to celebrate it.
-- 
Michael L. Siemon                             mls@panix.com        

"Green is the night, green kindled and apparelled.
It is she that walks among astronomers."
                                      -- Wallace Stevens

<Prev in Thread] Current Thread [Next in Thread>