What other experimental languages connect to a windowing system? (was: Why is TCL successful ?)

13 views
Skip to first unread message

Niels P. Mayer

unread,
Jul 22, 1994, 2:21:40 PM7/22/94
to

[note additional crossposting to comp.lang.lisp]

In article <LORD.94Ju...@x1.cygnus.com> lo...@x1.cygnus.com (Tom Lord) writes:
ous...@sprite.Berkeley.EDU:

Since we're slinging arrows, allow me to sling mine. It's
time to accept the fact that Lisp will never be a mainstream
language. There's no question that Lisp is an intellectually
interesting language, and it is very important in certain
communities, such as AI and formal language design. But it's
simply never going to be widely used.

Right. No general-use application written in lisp will ever fly.
Only in a few exotic situations do people ever use lisp.

Tom Lord
part-time emacs hacker

Perhaps you mean no general use application written entirely in Common
Lisp will ever fly? I can think of lots of counterexamples:

* GNU Emacs partially written in Lisp. It is a hybrid
implementation using C at its core, and Lisp as a configuration
and extension language.

* AutoCAD uses AutoLisp as an extension language. It is very very
popular given that it is a CAD package, and not, say, a spreadsheet.
I can't remember the figures exactly, but I've heard there's 500,000
to 1,000,000 copies of it floating around world-wide.

* Various other CAD packages use Lisp extension languages as well,
for example Cadence Design Systems.

* Interleaf uses Lisp as an extension language.

* SoftQuad has an SGML editor which uses Scheme (a Lisp dialect) as an
extension language.

* All applications written in WINTERP (I know of one that had
an estimated 1500 users.) All applications using Elk. All.
applications using CLM/GINA. All applications using GNU Emacs
and written in Emacs-Lisp (such as the newsreader I'm using --
GNUS).

* The statistics community has found Luke Tierney's XLISP-STAT
to be a very cool package as well. THis is a package with
a hybrid C/Lisp implementation of Lisp which is extended to
do graphics and plotting (Mac,Unix/X11) and with statistics
primitives.

--------------------

From: ous...@sprite.Berkeley.EDU (John Ousterhout)
> Since we're slinging arrows, allow me to sling mine. It's time to accept the
> fact that Lisp will never be a mainstream language. There's no question that
> Lisp is an intellectually interesting language, and it is very important
> in certain communities, such as AI and formal language design. But it's
> simply never going to be widely used. Lisp has been trying for more than
> 30 years; every few years we hear another round of grandiose claims, and
> a few years later they have evaporated. We could argue about why Lisp
> hasn't entered the mainstream, but none of this changes the basic fact
> that it hasn't.
>
> I believe that it is reasonable to give new ideas a chance and to accept
> plausible arguments that they might succeed, but when a system has been
> around for 30 years I don't think "plausible arguments" are enough anymore.
> If someone is going to argue today why Lisp should be a mainstream
> language, they must somehow explain why it hasn't succeeded in the past
> and what will happen this time to make things turn out differently.

Repeating "Lisp is dead" over and over and over again will not make it
true, just like repeating "Tk has a Motif Look and Feel" will not make it
true to someone expecting a Tk application to "feel" like Motif.

All you have to do is go down to any technical bookstore and you will find
many many books on Lisp programming, Lisp application programming and
Scheme programming. And I'm not talking about 30 year old books on Lisp,
I'm talking about books that are in their third or fourth printing and have
been published in the last few years. There is a market for these books,
otherwise the publishers would never have put these books out, nor put out
new editions of older books (e.g. Winston&Horn).

In addition to Lisp books, there are also a number of recently published
books on the Scheme dialect of Lisp. One of the best introductory books on
computer science, Abelson&Sussman's "Structure and Interpretation of
Computer Programs", uses SCHEME and not Pascal or C to introduce the
student to a variety of interesting CS problems. The fortunate few that are
able to make it in to MIT end up taking 6.001 (which uses the
Abelson&Sussman book) as their introductory computer science and
programming course, which tends to put these folks on the right track right
from the start.

Finally, I know of at least three books on GNU Emacs which discuss
Emacs-Lisp programming, and there's whole rows of books on AutoLisp
programming for AutoCAD.

(Since WINTERP uses XLISP-PLUS, I'll also mention that I know of two books
on XLISP, and one on Luke Tierney's XLISP-STAT).

Meanwhile, I know of exactly one book on TCL/Tk (Ousterhout's) that is now
available in bookstores. More importantly I haven't come across any books
on applications using TCL/Tk as an extension language (like the GNU Emacs
or AutoCAD books).

> |> Yes, TCL is a simple language -- I contend that it is too simple and too
> |> simplistic for constructing well engineered applications:
> |> ...
>
> Again, I think the large number of Tcl applications and the growing size of
> the Tcl community speak for themselves. What better evidence could there
> be that Tcl and Tk are practical for building interesting and useful
> applications?

I already answered to this in my original post when I said:

| The fact that people *can* program applications in the bourne shell, or
| tcsh, or the korn shell does not imply that a language having the above
| limitations is a good or expressive language for building applications.

Some of the problems I addressed:

| * type-overloading of strings, and lack of any real type system.
| * lack of proper automatic memory and resource management (freeing
| up data when a widget is destroyed doesn't quite cut it).
| * lack of lexical scopes for functions/procedures.
| * lack of closures (forcing programmers to use too many global
| variables).
| * Lack of object orientation in the standard TCL/Tk release.

Are clearly problems with TCL in terms of building larger applications that
scale well, and aren't mired in a sea of global references. I can't imagine
that people spent the time to develop [incr tcl] and [incr tk] unless
they were attacking a known problem.

I think the whole "popularity" line of reasoning is questionable: MS-DOS
and MS-WINDOWS are more popular than Unix/X, but many of us have good
reasons to keep working on Unix and X. Beyond that, if you're worried about
popularity, both the Lisp and TCL/Tk community are no doubt insignificant
when comparted to, say the Visual Basic community, or Actor, or other
similar packages available for MS-WINDOWS.

In other words, the popularity argument is meaningless at best, and
specious at worst. Some people are willing to pay the costs of Lisp in
return for its benefits. Others may be lured to TCL/Tk because it is small,
simple and free and includes a free toolkit. None of these have anything
to do with the fact that the language may not be good for building
GUI-based applications. People write applications in assembly too.

When discussing language features, one shouldn't confuse a trend with a
movement.

I personally couldn't give a deleted expletive about whether Lisp is more
or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
program. In the mean time, I'm happy to see that we all have choices and
are not locked in to any particular form of lowest-common-denominator
groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.

Michael Tiller

unread,
Jul 22, 1994, 3:36:44 PM7/22/94
to
In article <MAYER.94J...@netcom9.netcom.com>, ma...@netcom9.netcom.com (Niels P. Mayer) writes:

[lots of stuff deleted]

|>
|> I personally couldn't give a deleted expletive about whether Lisp is more
|> or less popuplar than TCL/Tk or Perl, just as long as no employer of mine
|> ever demands that I write, maintain, or extend a TCL/Tk or Safe-TCL
|> program. In the mean time, I'm happy to see that we all have choices and
|> are not locked in to any particular form of lowest-common-denominator
|> groupthink (e.g. MS-DOS) -- use the best tool for the job, whether it be
|> C, C++, Lisp, TCL, Perl, Awk, Sed, ASN1, APL, Prolog, or whatever.

Am I the only one who finds this paragraph self-contradicting.
"...as long as no employer of mine ever demands that I write...TCL/Tk"

followed in virtually the same breath by
"...use the best tool for the job..."

Come on.

Mike

Richard Karpinski

unread,
Jul 22, 1994, 6:22:39 PM7/22/94
to
Neils Mayer's recent post detailing the applications written
wholly or partially in Lisp IMHO should end all talk of Lisp
is Dead.

--
"If I cannot bring it up on my monitor and it does not interfere
with a major aspect of my physiology, like eating, sleeping, or breathing,
then it probably does not exist"

Bill Janssen

unread,
Jul 23, 1994, 12:22:24 AM7/23/94
to
In article <30p74c$q...@ef2007.efhd.ford.com> til...@solace.me.uiuc.edu (Michael Tiller) writes:

Am I the only one who finds this paragraph self-contradicting.
"...as long as no employer of mine ever demands that I write...TCL/Tk"

followed in virtually the same breath by
"...use the best tool for the job..."

With all due respect for the wonderful implementation of Tcl, I find
it difficult to think of a job for which Tcl is the best tool.
Perhaps someone could make a list?

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://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html

Niels P. Mayer

unread,
Jul 23, 1994, 5:22:41 PM7/23/94
to
[please excuse following up to my own last posting ... Ousterhout's
original posting appears to have expired on netcom...]

From: ous...@sprite.Berkeley.EDU (John Ousterhout)
| There are many things in Niels Mayer's article that deserve a rebuttal, I'll
| just pick a couple:
|
| |> TCL's problems of language quoting incosistency make it difficult to write
| |> higher level abstractions for UI construction -- macros, iterators,
| |> data-driven-UI-generation, etc. Not that higher level abstractions can't be
| |> done -- it's just that creating them in TCL is linguistically painful
| |> because the language uses the wrong fundamental data-type -- newline
| |> delimited STRINGs separated by spaces. In constrast LISP chose the right
| |> fundamental data-type LISTs of SYMBOLs, and consistently applies this
| |> datatype across throughout the language.
| |>
|
| This paragraph suggests that you don't understand Tcl. In fact the quoting
| rules are very simple and very consistent; I claim that it's quite
| straightforward to build higher-level constructs for UIs and I think there
| are many many examples in the Tcl community that illustrate this. One
| can make religious arguments ad nauseum, but I know of no technically
| sound evidence that lists of symbols are fundamentally better than strings.

It looks like a number of your users are also having trouble understanding
Tcl. In my opinion, this is because the quoting and parenthisation rules
are neither straighforward, simple, nor consistent. About once every week
or two, I see questions come up on comp.lang.tcl dealing with one or more
of the issues raised above. Examples of these problems have been
appended to the end of this article...

When users are having real problems, it becomes clear that the arguments
are no longer religious. In Lisp, you can get arbitrarily complex and
inscrutable once you go to extreme macro-ology and multiple levels of
backquoting. However, for the more typical cases handled by the neophyte,
the problems of quoting, time-of binding, time-of substitution, and scope
of bindings are more consistent and easier to understand in Lisp. And
when you need to, you know that there's a very nice macro capability
to back up any meta-level programming you need to accomplish.

By default, Lisp does the right thing for the case of binding at run-time,
and when you need to perform binding at evaluation time, you use
backquotes... The places where backquote substitutions happen are clearly
marked by backquoting 'commands' e.g. (,foo); all other cases look up the
value of a symbol based on the closure surrounding the code being
executed. By using closures, one may limit the extent of variables to
groups of functions or methods, an application module, or the entire
application -- closures are the basis enabling any lexically scoped Lisp
solution to scale better than TCL. And in Lisp, you don't have multitudes
of different ways of opening and closing expressions...

Furthermore, there's 30 years of history and 30 years worth of books on
Lisp programming which have dealt with these problems from the pedagogical,
technical, and style/design perspectives. Most beginners find this helpful.
Reinventing the issues which are already solved problems in Lisp, just so
that you can have a language that doesn't parenthesize like Lisp -- that is
not helpful to the beginner. It does, however, open up a whole new market
for books.

Finally, I think that having language syntax depend on newlines is a bad
idea -- I think most unix shell programmers will grudgingly agree with me
on this. I'd much rather have a Lispish syntax where you delineate your
current top-level evaluations by [ ... ] and don't bother with newlines.
Unfortunately, given people's knee-jerk response to Lisp, having such a TCL
would highlight TCL's parentage as bastard-child-of-Lisp. Something almost
Lisp-like would set-off or shatter people's preconceived panic
response. Can't do that! (Meanwhile, I eagerly await the chance/time to see
how the Dylan folks solved the problem of being politically right-thinking
with regards to syntax while retaining a Lisp core).

Well, here go the examples, cleaned from a random reading through
comp.lang.tcl articles on this site:

--------------------

From: hfv...@bcarh80a.bnr.ca (7Z31 Coop)
| In article <1994Jul21.1...@khis.com>, cha...@khis.com (David Chang) writes:
|
| [... Stuff Deleted ...]
| |> I'm trying to get the number of word "set" appeared in $file and set
| |> the scale value by using "set count [exec grep -c set $file]; .scale set $count".
| |> This doesn't work if no "set" appeared in file "$file" , so I change to use
| |> the following method (use catch) :-) Guess what ?
| |>
| [... Stuff Deleted ...]
| |>
| |> catch [exec grep -c "set" $file] retval
| |> if { $retval == 1 } {
| |> .scale set 0
| |> return 0
| |> }
| |>
| |> if { $retval != 1 } {
| |> set count [exec grep -c "set" $file]
| |> .scale set $count
| |> return 0
| |> }
| |>
| |> So my question is : How do I set the variable "count" if the return value of
| |> "grep -c" is 0 ?
|
| Try:
|
| if {[catch {set count [exec grep -c "set" $file]}]} {
| .scale set 0
| } else {
| .scale set $count
| }
| return 0


From: fri...@faw.uni-ulm.de (Davide Frisoni)
| Hello everyone,
| thanks to all people who answered my question, the main error come from a wrong use of [].
|
| I wrote :
| set code [catch [my_cprogram] err] :-(
| and now with :
| set code [catch {my_cprogram} err] :-)
| it works.


From: Rob Earhart <earh...@CMU.EDU>
| wessel@stt_even.let.ruu.nl (Wessel Kraaij) writes:
| > proc 8bitbindings {widget} {
| > bind $widget \" {set nop 0}
| > bind $widget \"\" {$widget insert insert \"}
| > bind $widget \"e {$widget insert insert \353}
| > }
| >
| > Unfortunately, this does not work, because $widget in the binding
| > script is evaluated at event time, not at bind time!
|
| proc 8bitbindings {widget} {
| bind $widget \" {set nop 0}
| bind $widget \"\" [list $widget insert insert \"]
| bind $widget \"e [list $widget insert insert \353]
| }
|
| Yeah, I stumbled on this when learning TCL, too :-)

From: dav...@london.sbi.com (David Artus)
| Long Pham (lp...@tern.NoSubdomain.NoDomain) wrote:
| : Hello tcl experts,
|
| : I'm a newbie in this area, and have a small problem while playing w/
| : tcl. So, be gentle.
|
| : Here is my problem:
| : I'm trying to create an n number of buttons, each button will call
| : a same proc upon activated. And an argument passes to the proc is
| : an variable, i.e. different value for different button. I want to
| : display the value of the argument that I passed to the proc everytime
| : I click on a button. However, the program doesn't work, it always
| : display the last value of the variable no matter what button I
| : clicked on.
|
| : set names {John Anne Mary Jim}
| : foreach b $names {
| :
| : button .$b -text $b -command {displayName $b}
| : pack .$b -side left -padx 3
|
| : }
|
| : proc displayName bname {
| : puts $bname
| : }
|
| your problem is -command {displayName $b}
|
| The {} defer evaluation of $b till the event occurs. At that time
| b is, of course, set to Jim. You probably mean -command "display $b"
| for the purposes of this playing, or in real life maybe some
| cunning way of extracting the button name, contents or whatever.

From: hfv...@bcarh80a.bnr.ca (Dan MacDonald)
|In article <1994Jul22.005941.19824@wmichgw>, 31ch...@wmich.edu writes:
||> Hello Everybody,
||>
||> I am a new user of tk/tcl. I have a question.
||>
|
|Your entire problem:
| Very simply it's the value being passed to your procedure s1 is
| always '0'. This stems from the fact that when you created the
|
| button .watch22.yes -text YES \
| -command "s1 $foo_value"
|
| you specified the command (bind command) in quotes which performs
| substitutions when created. If you enclose the command in curly
| braces the substitution will be performed later. Although the (all)
| bind command operates at global scope, this is acceptable since the
| variable foo_value is a global variable - it must be because it
| to is "bound" by the scale widget to store the value.
|
|Try: button .watch22.yes -text YES -command {s1 $foo_value}
|
|Dan MacDonald

From: f...@cam-orl.co.uk (Frank Stajano)
| In article <303o17$4...@hydrox.cs.umd.edu>, nle...@cs.umd.edu (Nathan Lewis) writes:
| |> Hi everyone,
| |>
| |> I'm still new to tcl and I'm having some trouble. I'm trying to write lines to
| |> a file. There is one line where I want to write a bunch of things to the file
| |> literally but the problem is that I want to write $variable-name to a file
| |> literally and the interpreter keeps trying to evaluate the variable and I can't
| |> seem to get it not to.
| |>
| |>
| |> Thanks alot for any help.
| |>
| |> This is the code:
| |>
| |> button $w.ok -text "EXIT" -command " ;\
| |> puts \$datafile \"set precedence_relO \$precedence_rel\" ;\
| |> puts \$datafile \"\n\n\n\" ;\
| |> puts \$datafile \"set precedence_rel {\[lindex \\$precedence_relO 0\]}\" ;\
| |> This is the line ^ This is the variable ^
| |> puts \$datafile \"\n\" ;\
| |> puts \$datafile \"set Threads [list $Threads]\" ;\
| |> puts \$datafile \"\n\" ;\
| |> puts \$datafile \"set exclusion_rel [list $exclusion_rel]\" ;\
| |> exit ;\
| |>
|
| I must admit I haven't got a very clear idea of what you are trying to do, but
| if all you want is putting out stuff literally you could use curly brackets
| instead of quotes. If instead you want to have some of the things substituted
| (like the []'s) and some not (like the $'s) then I'd say your best bet is to
| make the command a separate procedure and build up the complex string in the
| procedure with "append". Otherwise it becomes a bit too complicated to do in one
| single command line, and the code becomes difficult to read and maintain.

From: f...@cam-orl.co.uk (Frank Stajano)
| In article <ASSON.94J...@chacmool.stsci.edu>, as...@chacmool.stsci.edu (Drew Justin Asson) writes:
| [...]
| |> >proc foo {x} {
| |> > global Global_Var
| |>
| |> > if {$x == ""} {
| |> > return $Global_Var
| |> > } else {
| |> > return $x
| |> > }
| |> >}
| |>
| |>
| |> The only problem with this is that this will raise an error
| |> if no argument is provided. To do what you want, you would
| |> have to declare the argument list as:
| |>
| |> { {x ""} }
| |>
| |> Then, the code would work.
|
| You're absolutely right, thanks for pointing it out. (Using args instead of x is
| another option.)
|
| |> But, this isn't really what I wanted. I was more interested in
| |> doing something that we often do with LISP code. E.g.
| |>
| |> proc foo { {x minus-infinity} {y plus-infinity} } {
| |> ...
| |> }
| |>
|
| I can't think of a Tcl way of doing this sort of thing in the argument list. If
| someone finds one, I'd be curious to know about it.

From: s...@cs.hut.fi (Sami-Jaakko Tikka)
| In <30jdao$8...@access3.digex.net> cob...@access3.digex.net (Cary B. O'Brien) writes:
| >Why does expr { fred < sam } fail,
| >When expr { "fred" < "sam" } succeeds.
|
| When expr sees strings without quotes, it tries to convert them to
| numbers.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
== Niels Mayer -- netcom!mayer -- ma...@netcom.com ==
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Don Libes

unread,
Jul 24, 1994, 1:06:04 AM7/24/94
to
In article <MAYER.94J...@netcom2.netcom.com> ma...@netcom2.netcom.com (Niels P. Mayer) writes:
+ From: ous...@sprite.Berkeley.EDU (John Ousterhout)
+ | This paragraph suggests that you don't understand Tcl. In fact the quoting
+ | rules are very simple and very consistent; I claim that it's quite
+ | straightforward to build higher-level constructs for UIs and I think there
+ | are many many examples in the Tcl community that illustrate this. One
+ | can make religious arguments ad nauseum, but I know of no technically
+ | sound evidence that lists of symbols are fundamentally better than strings.

+ It looks like a number of your users are also having trouble understanding
+ Tcl. In my opinion, this is because the quoting and parenthisation rules
+ are neither straighforward, simple, nor consistent. About once every week
+ or two, I see questions come up on comp.lang.tcl dealing with one or more
+ of the issues raised above. Examples of these problems have been
+ appended to the end of this article...

+ When users are having real problems, it becomes clear that the arguments
+ are no longer religious. In Lisp, you can get arbitrarily complex and
+ inscrutable once you go to extreme macro-ology and multiple levels of
+ backquoting. However, for the more typical cases handled by the neophyte,
+ the problems of quoting, time-of binding, time-of substitution, and scope
+ of bindings are more consistent and easier to understand in Lisp. And
+ when you need to, you know that there's a very nice macro capability
+ to back up any meta-level programming you need to accomplish.

As a computer scientist, I found Lisp beautiful and easy to learn.
But that doesn't mean I like programming in it. The heart of Lisp,
the list, models only a fraction of the algorithms and data structures
that I deal with. Everything else is 2nd class and dilutes the beauty
of the language. As soon as I wrote my first do-loop in Lisp, started
declaring my data structures, and explaining all sorts of things to
the compiler, the courtship was over. As I remember, macros were the
final straw. As you admit, they make the language inscrutable, and
since everyone uses them...

I am not defending Tcl. I am simply saying that I find your arguments
about Lisp contrived. There are obvious difficulties in Lisp to
beginners that you have conveniently forgotten. If as many people
were learning Lisp as were learning Tcl, I'm sure the number of
beginner-type questions to comp.lang.lisp would be just as high. I
actually went and looked to see what's happening in the newsgroups and
c.l.l has the same beginner questions that you can find in any
language newsgroup. Here's a classic sample:

>From: [name changed to protect the innocent]
>Subject: Book Recommendation????
>Message-ID: <2vo19p$o...@jadzia.CSOS.ORST.EDU>
>Date: 10 Jul 94 05:34:49 GMT
>
>I am new to the LISP language (studying for alomst a year) and have read
>a few books on LISP. I am interested in hard core (excuse the expression)
>programming using the LISP language. Most of the books that I have read
>have gotten confusing about halfway through. I know this may have been
>asked in the past but I would like to know what book(s) would be
>recommended for a beginner on LISP?? Any responses would be greatly
>appreciated...Thanks

This poor guy has been studying Lisp for a year, has read several
books on it and still considers himself "new to the language"?!

My point is, citing messages from confused novices doesn't prove the
language is difficult any more than messages from rabid experts proves
that the language is great.

Don Libes <li...@nist.gov>

Paul Alexander

unread,
Jul 24, 1994, 7:17:46 AM7/24/94
to
In article <MAYER.94J...@netcom2.netcom.com>, ma...@netcom2.netcom.com (Niels P. Mayer) writes:

|> Finally, I think that having language syntax depend on newlines is a bad
|> idea -- I think most unix shell programmers will grudgingly agree with me
|> on this. I'd much rather have a Lispish syntax where you delineate your
|> current top-level evaluations by [ ... ] and don't bother with newlines.

But Tcl was intended, and used by many of us, as a shell-like command
interface to applications and ALSO as an extension language. I think the
vast majority of users would be confused by a "SHELL" in which newline did
not terminate input to a command. It is in this respect that Tcl's very
simple syntax is just the job for an embedded language.

Paul Alexander
Department of Physics, University of Cambridge, Cambridge, UK

Stephen J Bevan

unread,
Jul 24, 1994, 8:55:08 AM7/24/94
to
In article <LIBES.94J...@muffin.nist.gov> li...@nist.gov (Don Libes) writes:
... As a computer scientist, I found Lisp beautiful and easy to learn.

But that doesn't mean I like programming in it. The heart of Lisp,
the list, ...

Lisp 1.5 perhaps, but things have moved on since then. Functions are
the heart of Scheme (I don't think Common Lisp has a heart :-)


... models only a fraction of the algorithms and data structures


that I deal with. Everything else is 2nd class and dilutes the beauty

of the language. ...

Are you implying that structures, vectors, ... etc. are all "2nd
class" in Common Lisp? Either way, what is your definition of "2nd class"?

Juergen Wagner

unread,
Jul 24, 1994, 1:09:26 PM7/24/94
to
There are two types of GUI toolkits on the market (including the
public domain): those using an interpreted approach, and those based
on a compiled language. The interpreted tools use a more or less
simple language to specify or actually program widgets, gadgets, and
whatever they may call them. The compiled tools emit C or C++ code
where a user may fit in his/her application code.

Both have advantages and disadvantages: interpreted languages usually
allow dynamic loading in a simple fashion, i.e., they are good for
prototyping of complex user interfaces you couldn't easily do in a
compiled environment due to the time needed for edit-compile-run
cycles. Also, compiler-based languages require an entire restart of
the application (because the patched program is a new program), while
interpreted systems can handle updates on the fly. Compiler-based
languages are more efficient for numerical calculations and other
low-level operations.

Compiling both approaches is what has been done in LISP. One of the
problems of LISP (still my favourite programming language), however,
is that it is a fully-fledged programming language with constructs a
little bit unfamiliar to usual programmers. The price you have to pay
for an elegant language like LISP: it is...umm... different.

Tcl also tries to combine the two approaches by providing an
interpreted language which is extensible by C- or C++-written
commands. However, sacrificing a real type system (LISP has a full
type system) causes problems for certain applications: take an
object-oriented database, for example. Object types and ids cannot be
simply distinguished from strings which happen to look the same. Users
have to artificially add type markers because there are only strings
in Tcl. Syntactic features must be used to differentiate between
types.

Other than that, Tcl very much resembles a LISP with BASIC elements,
and turns out to be useful for most user interface designs, although
the syntacticness of types can cause weird situations with character
or expression quoting.

As for Tk, there are also advantages and disadvantages: First of all,
it is nice to have a toolkit of relatively elaborate widgets which is
as simple to manage as Tk. Tools like XDesigner are nice, but once you
go beyond what they provide as pre-manufactured widgets, you have to
go down into the basement and dig up those Motif manuals. Also, you
may find your actual data items nested into a four-level struct. The
problems with Tk come in where compute-intensive portions of a GUI
need to be implemented. Passing data between Tcl/Tk and a C/C++
application in the form of strings simply won't be efficient enough
for such applications.

This is the point where I wished I had a more layered system at my
disposal:

Level 0 Xlib and friends
Level 1 Tk with a C/C++ interface pretty much
like SunView had
Level 2 Tcl-binding for Tk

This way, Tk would be 100% separated from Tcl, also allowing other
languages to bind more easily to the nice widgets provided. In
particular, C/C++ interfaces would be able to directly access
functions to do their high-volume data output which would be too
time-consuming when done through Tcl strings.

In a way, the purely syntactic character of data types in Tcl wouldn't
be that much of an issue any more because the critical parts, where
type semantics is lost in string conversion, could be done directly in
C or C++, or any other language replacing the level-2 binding (LISP?).
How much of Tk would be available at level 2, and how types are
handled exactly, would be left to level 2. Tcl would be a simple but
type-wise restricted language, LISP could carry through all
information.

The ultimate question always is: "Is it useful for my application? If
not, what is?" We had a project at FhG-IAO, where the GUI design was
done with a copmiler-based GUI designer. At some point, there was a
requirement to do splines. Due to problems implementing this quickly
under the GUI tool, we had to bring in UNIRAS, a huge, overkill
scientific visualization package. It sort of worked, but was an
incredible kludge to use that monstrous package only for the splines.
Little later, the entire GUI was re-done with Tcl/Tk. Not only was the
development time (including the time to learn Tcl/Tk) of the entire
GUI much shorter, but the configurability and overall flexibility was
greatly enhanced.

If I compare the results (and efforts!) for some GUI designs, I'm
happy to have a tool at my disposal which allows me to quickly
prototype GUIs without bothering much about type information and
declarations. This tool may be Tcl/Tk, it may be a LISP-based
environment. If I only have to position a few buttons, choose colors,
and plug a simple database interface program into the resulting GUI, a
tool like XDesigner would be most welcome. At WESCON'94, I'll describe
some of the experiences made in this project and others in more
detail.

IMHO, some of the previous discussion, where religious arguments came
up, lacked this view.


--Juergen Wagner

Juergen...@iao.fhg.de
gan...@csli.stanford.edu

Fraunhofer-Institut fuer Arbeitswirtschaft und Organisation (FhG-IAO)
Nobelstr. 12c Voice: +49-711-970-2013
D-70569 Stuttgart, Germany Fax: +49-711-970-2299
For more information/detail, please do "finger gan...@csli.stanford.edu".

Martin Rodgers

unread,
Jul 24, 1994, 9:34:48 AM7/24/94
to
In article <MAYER.94J...@netcom9.netcom.com>

ma...@netcom9.netcom.com "Niels P. Mayer" writes:

> I think the whole "popularity" line of reasoning is questionable: MS-DOS
> and MS-WINDOWS are more popular than Unix/X, but many of us have good
> reasons to keep working on Unix and X. Beyond that, if you're worried about
> popularity, both the Lisp and TCL/Tk community are no doubt insignificant
> when comparted to, say the Visual Basic community, or Actor, or other
> similar packages available for MS-WINDOWS.

This is true. If you don't use VB or VC++, there are a lot of people
who won't take you too seriously. Even Actor and Smalltalk/V get heavy
criticism, coz reviewers (I'm told that one of the was Ray Duncan) use
the "Hello, World" type app (App? What a joke.) as a benchmark. Using
code like that can make even VC++ look bad, but that doesn't stop
reviewers wetting themselves over it, while all they can say about
Lisp, Smalltalk and Actor is that you _can_ use them if you want to.
They don't say you _have_ to, which is what they're saying about VB
and VC++.

That may explain why I never see any job offers for Lisp or Smalltalk,
but I see many for C++ and VB. Perhaps I'm looking in the wrong places?
After all, I'm only looking in the mainstream computing press.

Languages issues arew irrelevent when you look at them like this. It's
too easy to say, "Pay me to use your favourite language, and I'll be
happy to install it and program with it."

--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"

If "One likes to believe in the freedom of email", email
clipper....@cpsr.org and tell them you oppose Clipper.
This is a shareware .signature -- please pass it on!

Michael Tiller

unread,
Jul 25, 1994, 8:38:33 AM7/25/94
to
In article <JANSSEN.94...@holmes.PARC.Xerox.Com>, jan...@parc.xerox.com (Bill Janssen) writes:
|> In article <30p74c$q...@ef2007.efhd.ford.com> til...@solace.me.uiuc.edu (Michael Tiller) writes:
|>
|> Am I the only one who finds this paragraph self-contradicting.
|> "...as long as no employer of mine ever demands that I write...TCL/Tk"
|>
|> followed in virtually the same breath by
|> "...use the best tool for the job..."
|>
|> With all due respect for the wonderful implementation of Tcl, I find
|> it difficult to think of a job for which Tcl is the best tool.
|> Perhaps someone could make a list?

Well, I use a variety of tools some use TCL/Tk some don't. The two
most recent uses I have found for TCL/Tk were...

1) My real work (research) deals with mathematics. As part of this
research I found it necessary to write a Finite Element analysis
package. The package is written in C++ and I was quite content
to write a C++ "program" for each FEA "problem" that I wanted to
run. However after a while this got pretty tedious. Basically,
what it comes down to is the need for an input file which is
read interactively. Now I played around with some parser tools
to try to write a grammar for my input files. However, I kept
changing what kinds of elements I had and such and it got pretty
tedious. Then I decided to write the front-end in TCL. It
works great. Among the added features of using TCL...

* Expressiveness. I can use for loops and such rather than
explicit lists
* I get some added interactive capabilities. For example, in
addition to specifying the problem, I get a certain amount of
control over number of time steps and such. I can stop half
way through a simulation to examine some results

2) I'm currently working as a contractor for Ford Motor Company until
August. They had several text-based applications and they wanted
me to write some GUI stuff for them. I banged these GUIs together
pretty damn fast with the help of TCL/Tk. This has sparked a fair
amount of interest in TCL/Tk here in my department.

Now, I could have used anything I wanted for both of these projects
and I chose TCL/Tk because I felt they were the best tools for the
job. So far, I'm very happy with the results.


|>
|> 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://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html

Michael Tiller
University of Illinois

Christophe Muller

unread,
Jul 25, 1994, 1:24:43 PM7/25/94
to
In article <DICKK.94J...@netcom13.netcom.com> di...@netcom13.netcom.com (Richard Karpinski) writes:

> Neils Mayer's recent post detailing the applications written
> wholly or partially in Lisp IMHO should end all talk of Lisp
> is Dead.

Lisp is not dead.

I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
applications, it's just a matter of increasing CPU power and of ratio
hardware cost vs engineer cost (is this a fact that we could all agree on? :-).

It seems that Unix, X11, Windows, Emacs, Gcc will stay written in C (with a
small interpreter when needed) for a while, but that a lot of other
applications will be better generated in Cobol by a L4G or in C by Eiffel,
the rest, the "glue" for integrations being Tcl or Lisp code.

For this reason, a religious war between Lisp and Tcl is pointless, they
will certainly *both* have more and more adepts, and C/Fortran/Cobol less.. at
least I hope.. :-)

Cheers,
Christophe.

= % ping elvis =
= elvis is alive =

Don Bennett

unread,
Jul 25, 1994, 2:48:54 PM7/25/94
to
> I think the vast majority of users would be confused by a "SHELL" in
> which newline did not terminate input to a command.

Do you really think so? On my machine, only csh terminates input
with a newline.

sh, ksh, and bash will prompt for additional input if you haven't
closed your quoted expressions.

The secondary prompt makes it clear (to me at least) that additional
input is expected.

--

Don Bennett (415)390-2145
d...@sgi.com
Silicon Graphics

Mathieu Longtin

unread,
Jul 25, 1994, 1:19:10 PM7/25/94
to

In some earlier part of this discussion, somebody mentionned
a Scheme/Tk package called "STk" if I remember well. However
I can't seem to find anything about that package, does
anybody knows a ftp/www address where I could find info about
STk?

Thanks in advance


Mat

Peter da Silva

unread,
Jul 25, 1994, 5:30:53 PM7/25/94
to
In article <DPB.94Ju...@pedernales.sgi.com>,

Don Bennett <d...@sgi.com> wrote:
> > I think the vast majority of users would be confused by a "SHELL" in
> > which newline did not terminate input to a command.

> Do you really think so? On my machine, only csh terminates input
> with a newline.

> sh, ksh, and bash will prompt for additional input if you haven't
> closed your quoted expressions.

% tcl
tcl>echo "hi there
=>foo"
hi there
foo

What's your point?
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast Du heute schon Deinen Wolf umarmt?"

David Eby

unread,
Jul 25, 1994, 7:52:40 PM7/25/94
to

You can find STk 2.1 in the Scheme Repository:

ftp.cs.indiana.edu:/pub/scheme-repository/imp/STk-2.1.tar.gz

I believe this is the latest version of STk. If you just want info
without actually downloading the package, you might try sending mail
to Erick Gallesio (e...@unice.fr).

David Eby
de...@cs.indiana.edu

Martin Rodgers

unread,
Jul 25, 1994, 12:01:25 PM7/25/94
to
In article <LIBES.94J...@muffin.nist.gov>
li...@nist.gov "Don Libes" writes:

> As a computer scientist, I found Lisp beautiful and easy to learn.
> But that doesn't mean I like programming in it. The heart of Lisp,
> the list, models only a fraction of the algorithms and data structures
> that I deal with. Everything else is 2nd class and dilutes the beauty
> of the language. As soon as I wrote my first do-loop in Lisp, started
> declaring my data structures, and explaining all sorts of things to
> the compiler, the courtship was over. As I remember, macros were the
> final straw. As you admit, they make the language inscrutable, and
> since everyone uses them...

Which Lisp dialect was this? Is it one with structures? Arrays?
Not everything is a list. Some things are even symbols.

> This poor guy has been studying Lisp for a year, has read several
> books on it and still considers himself "new to the language"?!

I still consider myself new to C, even tho I first used it in the
early 80s. Now I'm learning C++, which looks even worse. Most of
what I consider "learning a language" to be is more than the syntax
and the symantics. It's more like style and experience.

> My point is, citing messages from confused novices doesn't prove the
> language is difficult any more than messages from rabid experts proves
> that the language is great.

Agreed. Languages are just different. I love an exchange of opinions,
but please, _please_ let's not try to "prove" anything?

David Chase

unread,
Jul 26, 1994, 10:39:41 AM7/26/94
to
mul...@simulog.fr (Christophe Muller) writes:
|> Lisp is not dead.

|> I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
|> applications, it's just a matter of increasing CPU power and of ratio
|> hardware cost vs engineer cost (is this a fact that we could all agree on? :-).

But Lisp could have better syntax. On the other hand, all these other
little languages could have better semantics. For some time it has been
a pet peeve of mine that people inventing little languages, with their
syntax appropriate-to-task/audience, seem to feel it is necessary to badly
re-invent execution semantics. It-would-be-nice if people would take a
little bit of trouble to layer their new syntax on top of (for instance)
Scheme, or an interpreter built in that (continuation-passing) style (it's
NOT HARD, DAMMIT!)

And, there are those little languages with inferior syntax, which could just
as well be replaced by Scheme with a few appropriate primitives. Here, I'm
thinking of the "languages" used to program sendmail and adb.

Then again, it seems to be the norm in Computer "Science" to step on toes
instead of stand on shoulders. Carry on.

David Chase, speaking for myself
Thinking Machines Corp.

John W. Baugh Jr.

unread,
Jul 26, 1994, 2:19:35 PM7/26/94
to
In article <31377d...@early-bird.think.com>, ch...@Think.COM (David

Chase) writes:
> But Lisp could have better syntax. On the other hand, all these other
> little languages could have better semantics. For some time it has been
> a pet peeve of mine that people inventing little languages, with their
> syntax appropriate-to-task/audience, seem to feel it is necessary to badly
> re-invent execution semantics.

Amen. Preach it, brother!

In addition to "unix" languages, the Matlabs and Maples of the world
could use a reasonable --or at least sane-- execution semantics.

--
John Baugh
j...@eos.ncsu.edu

Peter da Silva

unread,
Jul 26, 1994, 6:31:30 PM7/26/94
to
In article <31377d...@early-bird.think.com>,

David Chase <ch...@Think.COM> wrote:
> But Lisp could have better syntax.

I like TCL fine, but I strongly disagree with this. A lot of Lisp's strengths
are *due* to its unconventional syntax (as is the case with Forth, SmallTalk,
Logo, PostScript, and, yes, TCL).

I just wish Lisp didn't have all these *other* syntaxes for arrays and macros
and everything else layered on top of it. I want Lisp 1.5, damnit.

(Peter shows his age again)

Scheme looks better, these days.

Martin Rodgers

unread,
Jul 26, 1994, 4:50:47 PM7/26/94
to
In article <MULLER.94J...@obelix.simulog.fr>
mul...@simulog.fr "Christophe Muller" writes:

> For this reason, a religious war between Lisp and Tcl is pointless, they
> will certainly *both* have more and more adepts, and C/Fortran/Cobol less.. at
> least I hope.. :-)

Agreed. Nobody will ever "prove" one language is "better" than another.
All they'll do is convince people (like me) that there are a few more
fanatics that support language X than language Y. That's hardly an
attractive feature.

Nicolas M Williams

unread,
Jul 27, 1994, 10:49:18 PM7/27/94
to
Well, back to the subject listed in the header.

A neat experimental language that is in some ways similar to lisp is
Icon. It is built on the concepts of success/failure (instead of
true/false boolean values), generators and control backtracking. It is
also a very functional language, about the only lisp-like features it
is missing are lambda expressions, quote and and a simple syntax
(although all expressions except for assingments can be expressed in a
form that is very similar to lisp's s-expressions). It's greatest
strength lies in text handling, though it is by no means a specialized
language. It also has most of the types that lisp has and there is a
[relatively] simple way to write variants of it (there's an
object-oriented variant for example).

Icon also has a graphics library that makes graphics programs written
in it fairly portable accross platforms and OS's.

Icon can be obtained from ftp://cs.arizona.edu/icon/ and the newsgroup
for it is comp.lang.icon.

Nick

Mike Gallo

unread,
Jul 28, 1994, 5:55:31 AM7/28/94
to
In article <MULLER.94J...@obelix.simulog.fr>
mul...@simulog.fr "Christophe Muller" writes:
>
> For this reason, a religious war between Lisp and Tcl is
> pointless, they will certainly *both* have more and more
> adepts, and C/Fortran/Cobol less.. at least I hope.. :-)

Actually, a religious war needs no point.
--
The more I get to know people, the more I like my dog.

Wolfgang Lux

unread,
Jul 29, 1994, 6:11:50 AM7/29/94
to
In article <1994Jul28.0...@cs.rit.edu>, nmw...@cs.rit.edu (Nicolas M Williams) writes:
|> Icon ... is

|> also a very functional language, about the only lisp-like features it
|> is missing are lambda expressions, quote and and a simple syntax
|> (although all expressions except for assingments can be expressed in a
|> form that is very similar to lisp's s-expressions).
Sorry, but I thought lambda was one of the very functional parts of
lisp. Should it be true that Icon has no way of representing anonymous
functions?

Wolfgang
--

Wolfgang Lux
WZH Heidelberg, IBM Germany IBM IP-Net: l...@rio.heidelbg.ibm.com
+49-6221-59-4546 VNET: LUX at HEIDELBG
+49-6221-59-3300 (fax) EARN: LUX at DHDIBMIP

Bennett Todd

unread,
Jul 28, 1994, 8:28:23 PM7/28/94
to
>|> With all due respect for the wonderful implementation of Tcl, I find
>|> it difficult to think of a job for which Tcl is the best tool.
>|> Perhaps someone could make a list?

As Michael Tiller said, one things TCL/Tk is excellent at is quickly
implementing small GUIs --- particularly GUI front-ends to non-GUI
applications. And that's an excellent model for general programming; don't
put any substantial, complex functionality into a GUI program if you can
help it; instead, write substantive command-line-driven programs, and GUI
front-ends. Improves code-reusability, modularity, regression testing, and
so on.

What's more, it helps set a precedent. As recently as a few years ago,
people were willing to stand up in public and claim that C (or C++) was the
only acceptable application development language. Within the last couple of
years Perl has forced its way in as another acceptable language, but somehow
most of those same people now want to try to say that C (or C++) and Perl
are the only two acceptable languages. So write your next application in
TCL/Tk. Then the one after that in Python. Then find a little Scheme, add
some dynamic loading, and create your own language for the next one. Use a
different language for every project until they get the point that chosing
the right language for the job is part of the design process, and can be
revisited _ab_initio_ for each new design.

-Bennett
b...@sbi.com

Henry G. Baker

unread,
Jul 31, 1994, 3:59:57 PM7/31/94
to
In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:
>mul...@simulog.fr (Christophe Muller) writes:
>|> Lisp is not dead.
>
>|> I think Lisp _and_ Tcl, and Perl etc.. will have more and more fields of
>|> applications, it's just a matter of increasing CPU power and of ratio
>|> hardware cost vs engineer cost (is this a fact that we could all agree on? :-).
>
>But Lisp could have better syntax.

The whole point of Lisp syntax is that it is trivial, and doesn't require
a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
syntax completely blew that particular advantage.

Improving the 'syntax' of a language is a little like climbing a tree
to make the first step towards the moon. It doesn't accomplish very
much, but it's easy and accessible and allows one to feel superior to
those still standing on the ground. In most cases, people would be
better off dispensing with character-based languages completely (e.g.,
for graphical languages), rather than wasting everyone's time creating
additional parsing and training nightmares.

Is the syntax of Lotus 1-2-3 macros really that brilliant, that it deserves
all of the brainpower wasted on it?

After tripping over all the minor syntactic incompatibilities of Fortran,
PL/I, Pascal, C, Ada, ..., I'm sick to death of the whole syntactic mess.

Proponents of syntactic sugar keep claiming their languages are more
'readable', but this presumes that users want to waste time reading
their silly 500-page manuals in the first place. I'm sure that
Persian and Finnish are 'readable' to their natives, too, but that
doesn't mean that they are 'readable' to anyone else.

>On the other hand, all these other
>little languages could have better semantics. For some time it has been
>a pet peeve of mine that people inventing little languages, with their
>syntax appropriate-to-task/audience, seem to feel it is necessary to badly
>re-invent execution semantics. It-would-be-nice if people would take a
>little bit of trouble to layer their new syntax on top of (for instance)
>Scheme, or an interpreter built in that (continuation-passing) style (it's
>NOT HARD, DAMMIT!)

Agreed, but I think that Lisp people have ignored for too long what the
users really want/need. Some of the things they want:

* the advantages of an integrated system with both compiled & interpreted code

* the ability to construct strict (file) and lazy (Unix stream)
compositions of existing functions

* the ability to explicitly control resource usage (GC hides too much)
without creating dangling references

* the ability to encapsulate nearly anything within a protocol-conversion
wrapper

* a powerful defaulting mechanism that isn't based on _state_ and
_state variables_. (This is probably one of the most important
problems facing the functional language community.)

>And, there are those little languages with inferior syntax, which could just
>as well be replaced by Scheme with a few appropriate primitives. Here, I'm
>thinking of the "languages" used to program sendmail and adb.
>
>Then again, it seems to be the norm in Computer "Science" to step on toes
>instead of stand on shoulders. Carry on.

Progress in most fields requires a throwing away of paradigms that
bind and constrict. Perhaps it is time to stop teaching students how
to parse, so they can focus on more worthwhile pursuits?


Joseph H Allen

unread,
Jul 31, 1994, 10:26:12 PM7/31/94
to
In article <hbakerCt...@netcom.com>,

Henry G. Baker <hba...@netcom.com> wrote:
>In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:

>>But Lisp could have better syntax.

>The whole point of Lisp syntax is that it is trivial, and doesn't require
>a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
>syntax completely blew that particular advantage.

I agree. Common lisp is hopeless. Its standard manual is longer than that
of _every_ _other_ programming language and its syntax diverged from the
lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
ideal lisp is not powerful or convenient enough for a real language.

>Improving the 'syntax' of a language is a little like climbing a tree
>to make the first step towards the moon. It doesn't accomplish very
>much, but it's easy and accessible and allows one to feel superior to
>those still standing on the ground.

Language syntax is related to style, in the graphic arts sense. It is
important for readability and can guide programming methodology. It helps
programmers remember language syntax and provides historic continuity.

Ideal-Lisp syntax may be trivial but it is not very nice looking. Why do
you think that algorithms in every non-lisp computer journal are printed in
pseudo-Algol-60?

>Is the syntax of Lotus 1-2-3 macros really that brilliant, that it deserves
>all of the brainpower wasted on it?

I don't know what you mean by this. Like lisp, Lotus 1-2-3 macro syntax is
trivial, but also like lisp, it's terrible looking.

>After tripping over all the minor syntactic incompatibilities of Fortran,
>PL/I, Pascal, C, Ada, ..., I'm sick to death of the whole syntactic mess.

Lisp isn't so wonderful in this respect either. Although the syntax, in the
strictest sense of the word, is trivial, the language is big, redundant and
non-uniform.

For example, 'setf' takes list of pairs which don't need to be enclosed:
(setf a 10 b 20 ... ), but then structures, which could also have this
syntax, require parenthesis around its pairs: (defstruct foo (a 3) (b 4)...).

Then there's: set, setq and setf; eq, eql and equal; and let, let*, letrec
and declare. Not to mention: cond and if; do, do*, and dotimes; and
array-dimension, initialize-instance, multiple-value-bind and
with-input-from-string.

>Proponents of syntactic sugar keep claiming their languages are more
>'readable', but this presumes that users want to waste time reading
>their silly 500-page manuals in the first place.

Which programming language has a 500-page manual? Only common lisp. Even
the manuals for PL/I, Ada and Algol-68 are shorter.

>I'm sure that
>Persian and Finnish are 'readable' to their natives, too, but that
>doesn't mean that they are 'readable' to anyone else.

I suppose you'd like them to convert to esperanto.

>>On the other hand, all these other
>>little languages could have better semantics. For some time it has been
>>a pet peeve of mine that people inventing little languages, with their
>>syntax appropriate-to-task/audience, seem to feel it is necessary to badly
>>re-invent execution semantics. It-would-be-nice if people would take a
>>little bit of trouble to layer their new syntax on top of (for instance)
>>Scheme, or an interpreter built in that (continuation-passing) style (it's
>>NOT HARD, DAMMIT!)

>Agreed, but I think that Lisp people have ignored for too long what the
>users really want/need. Some of the things they want:

I agree too, most languages could use better semantics. But they don't need
lisp's syntax.

>>And, there are those little languages with inferior syntax, which could just
>>as well be replaced by Scheme with a few appropriate primitives. Here, I'm
>>thinking of the "languages" used to program sendmail and adb.

I don't see what's so great about scheme. Constructs such as
(call-with-current-continuation name (body)) certainly don't encourage the
use of it's powerful semantic capability.

The major semantic paradigms present in scheme/lisp are:

1 Closures
2 Loops through tail-recursion and lambda functions
3 Type inference
4 Self-representation through common list syntax

1 is the most important one, and is syntacticly possible with other
languages. Most functional languages have closures. Other static languages
don't have them because they do not sit well with stack-based local
variables. For a non-lisp and non-functional language with closures, try my
language Ivy.

2 and 3 are not necessary, hurt readability and can be considered semantic
sugar.

4 is the only one which is really unique to lisp. It's made redundant by 1
though, so I don't miss it.
--
/* jha...@world.std.com (192.74.137.5) */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

rodrigo vanegas

unread,
Aug 1, 1994, 1:49:35 AM8/1/94
to

Finally, this long thread has reached the heart of what i believe to
be the principal reason why we can't do without lisp.

In article <Ctu43...@world.std.com>, jha...@world.std.com (Joseph H Allen) writes:
> The major semantic paradigms present in scheme/lisp are:

> 1 Closures
> 2 Loops through tail-recursion and lambda functions
> 3 Type inference
> 4 Self-representation through common list syntax

> 1 is the most important one, and is syntacticly possible with other
> languages. Most functional languages have closures. Other static languages
> don't have them because they do not sit well with stack-based local
> variables. For a non-lisp and non-functional language with closures, try my
> language Ivy.

1) ML also meets this criteria. It is an impure functional language
(meaning it has assignment which is all you need to program as you
would in C), and has a pleasant non-lisp syntax.

> 2 and 3 are not necessary, hurt readability and can be considered semantic
> sugar.

2) On the contrary, using tail-recursion allows one to use the return
values of each iteration to accumulate final values. (Mail me if you
want an example.) This is not possible with WHILE or FOR loops in
C/Pascal. Although, i admit that the paren-syntax is annoying, i
still prefer to program loops with tail recursion.

3) Type inference in Lisp? This is new to me. (Someone please
enlighten me here.)

> 4 is the only one which is really unique to lisp. It's made redundant by 1
> though, so I don't miss it.

4) But this is the ultimate reason why LISP is still indispensably
unique. Lisp's macros and ultra-flexible syntax have made it the
hot-bed of language research for many many years and continues to play
that role today. (Consider MOP, CLOS, CL Condition System, and
syntax-case for Scheme.) It's not made redundant by closures at all.
You still need the macros which can manipulate code as data
self-referentially.


Even so, i will concede without prompting,that if one is not
interested in either higher-order functions or language
experimentation, the lisp parentheses become only a nuisance and
Common Lisp's size just an obstacle to delivery.


rodrigo vanegas
r...@cs.brown.edu

Henry G. Baker

unread,
Aug 1, 1994, 1:04:02 AM8/1/94
to
In article <Ctu43...@world.std.com> jha...@world.std.com (Joseph H Allen) writes:
>In article <hbakerCt...@netcom.com>,
>Henry G. Baker <hba...@netcom.com> wrote:
>>In article <31377d...@early-bird.think.com> ch...@Think.COM (David Chase) writes:
>>>But Lisp could have better syntax.
>
>>The whole point of Lisp syntax is that it is trivial, and doesn't require
>>a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
>>syntax completely blew that particular advantage.
>
>I agree. Common lisp is hopeless. Its standard manual is longer than that
>of _every_ _other_ programming language and its syntax diverged from the
>lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
>ideal lisp is not powerful or convenient enough for a real language.

I think a quick perusal would show that most languages are happy with syntax
_trees_. Lisp S-expressions are general trees. QED

>>Improving the 'syntax' of a language is a little like climbing a tree
>>to make the first step towards the moon. It doesn't accomplish very
>>much, but it's easy and accessible and allows one to feel superior to
>>those still standing on the ground.
>
>Language syntax is related to style, in the graphic arts sense. It is
>important for readability and can guide programming methodology. It helps
>programmers remember language syntax and provides historic continuity.

God save us from language designers who want to impose their own personal
styles on all their users. The problem is that programming styles change
rather more rapidly than languages do, leaving the programs and programmers
of the 'I know what's best for you' languages high and dry.

>Ideal-Lisp syntax may be trivial but it is not very nice looking. Why do
>you think that algorithms in every non-lisp computer journal are printed in
>pseudo-Algol-60?

And how nice looking is the numerical program in pseudo-Algol that has
to first symbolically differentiate its functional argument, before
compiling and executing it?? Lisp syntax is ideal for programs which
must analyze and/or compose other programs. Since this is one of the
most powerful software levers available, languages which make this
difficult are guaranteeing poor productivity.

As to the pseudo-Algol-60 algorithms in computer books and
journals--it's truly a shame that Knuth never really got into Lisp.
His books would be _more_ readable, and TeX might actually have been a
decent language. Sigh...

>Lisp isn't so wonderful in this respect either. Although the syntax, in the
>strictest sense of the word, is trivial, the language is big, redundant and
>non-uniform.
>
>For example, 'setf' takes list of pairs which don't need to be enclosed:
>(setf a 10 b 20 ... ), but then structures, which could also have this
>syntax, require parenthesis around its pairs: (defstruct foo (a 3) (b 4)...).
>
>Then there's: set, setq and setf; eq, eql and equal; and let, let*, letrec
>and declare. Not to mention: cond and if; do, do*, and dotimes; and
>array-dimension, initialize-instance, multiple-value-bind and
>with-input-from-string.

Touche' ! (I'll have to send you a copy of my article "If it ain't Baroque,
fix it!")

>>Proponents of syntactic sugar keep claiming their languages are more
>>'readable', but this presumes that users want to waste time reading
>>their silly 500-page manuals in the first place.
>
>Which programming language has a 500-page manual? Only common lisp. Even
>the manuals for PL/I, Ada and Algol-68 are shorter.

The PL/I manual that I used was many more than 500 pages. Algol-68 is
shorter, but only because it appears to have been LZ-compressed and
therefore incomprehensible. The Ada83 manual is shorter, but you then need
the Commentaries and the Congressional Record to figure out what the manual
says.

Look at the computer books in your nearby Bookstar. Of course, the chatty
style, the double spacing, and those silly small-format pages do a lot to
create 500++ page books.

>The major semantic paradigms present in scheme/lisp are:
>
>1 Closures
>2 Loops through tail-recursion and lambda functions
>3 Type inference
>4 Self-representation through common list syntax
>
>1 is the most important one, and is syntacticly possible with other
>languages. Most functional languages have closures. Other static languages
>don't have them because they do not sit well with stack-based local
>variables. For a non-lisp and non-functional language with closures, try my
>language Ivy.
>
>2 and 3 are not necessary, hurt readability and can be considered semantic
>sugar.

If you think that anonymous lambda functions _hurt_ readability, I'd like to
sell you some continuation-passing code which is written in Pascal/Ada style.
Now _that_ really hurts the eyes.

??????????? 'Type inference' _hurt_ readability?? Perhaps you meant type
declarations?

Joseph H Allen

unread,
Aug 1, 1994, 2:44:12 AM8/1/94
to

I don't know Ada, but I agree, emulating continuations with Pascal is awful
(you have to pass a record via a global variable). Now if Pascal had
continuations, (and function pointers) it would be fairly nice, even without
lambda functions:

function foo():function;
var ...
begin

... (* code which sets vars *)

function bar(x:real):real;
begin
...
end.

some_proceedure(bar); (* call with continuation *)

foo:=bar; (* return with continuation *)

end.

>??????????? 'Type inference' _hurt_ readability?? Perhaps you meant type
>declarations?

IMHO, except for trivial programs, declarations improve readability because
you can easily figure out what is stored in variables and arguments and
don't have to trace constants or depend on operators not being overloaded.
You can jump into the middle of a program and start modifying it without
comprehending all of it. It makes your programs less general perhaps, but
definitly more readable. Likewise, structures (records) are better than
lists and tuples.

Joseph H Allen

unread,
Aug 1, 1994, 4:59:35 AM8/1/94
to
In article <RV.94Au...@tahoe.cs.brown.edu>,
rodrigo vanegas <r...@cs.brown.edu> wrote:

>Finally, this long thread has reached the heart of what i believe to
>be the principal reason why we can't do without lisp.

>In article <Ctu43...@world.std.com>, jha...@world.std.com (Joseph H Allen) writes:
>> The major semantic paradigms present in scheme/lisp are:
>
>> 1 Closures
>> 2 Loops through tail-recursion and lambda functions
>> 3 Type inference
>> 4 Self-representation through common list syntax

>> 1 is the most important one, and is syntacticly possible with other
>> languages. Most functional languages have closures. Other static languages
>> don't have them because they do not sit well with stack-based local
>> variables. For a non-lisp and non-functional language with closures, try my
>> language Ivy.

>1) ML also meets this criteria. It is an impure functional language
>(meaning it has assignment which is all you need to program as you
>would in C), and has a pleasant non-lisp syntax.

Yeah, ML's pretty nice.

>> 2 and 3 are not necessary, hurt readability and can be considered semantic
>> sugar.

>2) On the contrary, using tail-recursion allows one to use the return
>values of each iteration to accumulate final values. (Mail me if you
>want an example.) This is not possible with WHILE or FOR loops in
>C/Pascal.

Yes it is:

while(!context.done) context=function(context);

or if you have continuations (or are using global variables):

declare context;

function()
{
operate on context;
}

while(!done) function();

Any function which is strictly tail recursive can be directly expanded this
way. More general recursive functions can't:

LIST slow_reverse(LIST a)
{
LIST b=a->next;
if(b) return a->next=0, append(slow_reverse(b),a);
else return a;
}

IMHO, loop structures should be used in place of tail recursion for
readability. Recursion should, of course, still be possible.

>3) Type inference in Lisp? This is new to me. (Someone please
>enlighten me here.)

It's not guarenteed to infer the type of everything, but lisp optimizing
compilers sure try. The more that can be inferred, the more that can be
optimized.

>> 4 is the only one which is really unique to lisp. It's made redundant by 1
>> though, so I don't miss it.

>4) But this is the ultimate reason why LISP is still indispensably
>unique. Lisp's macros and ultra-flexible syntax have made it the
>hot-bed of language research for many many years and continues to play
>that role today. (Consider MOP, CLOS, CL Condition System, and
>syntax-case for Scheme.) It's not made redundant by closures at all.
>You still need the macros which can manipulate code as data
>self-referentially.

I should have said 'nearly redundant' :-)

Simple macros can be more powerful in lisp than in any other language and
rather easily lead to parameterized classes and other syntax augmentations.

You can also do neat things like easily take the derivatives of mathematical
functions expressed in lisp. But then I don't want to express my functions
in lisp :-) A simple precidence parser is only about a hundred lines long in
any other language, so it's not that big of a deal to use lists for
representation, and infix/prefix for data entry and display.

>Even so, i will concede without prompting,that if one is not
>interested in either higher-order functions or language
>experimentation, the lisp parentheses become only a nuisance and
>Common Lisp's size just an obstacle to delivery.

Lisp is a neat idea, but to gross to use in practice.

Nick Williams

unread,
Aug 1, 1994, 9:17:30 AM8/1/94
to
In article <31akl6$l...@kaa.heidelbg.ibm.com>,

Wolfgang Lux <l...@rio.heidelbg.ibm.com> wrote:
>In article <1994Jul28.0...@cs.rit.edu>, nmw...@cs.rit.edu (Nicolas M Williams) writes:
>|> Icon ... is
>|> also a very functional language, about the only lisp-like features it
>|> is missing are lambda expressions, quote and and a simple syntax
>|> (although all expressions except for assingments can be expressed in a
>|> form that is very similar to lisp's s-expressions).
>Sorry, but I thought lambda was one of the very functional parts of
>lisp. Should it be true that Icon has no way of representing anonymous
>functions?

All expressions in Icon produce results (i.e. there is no such thing as
a void typed functions as in C or CL). It also has apply/funcall like
expressions. Pointer semantics abound and there is no way to pass
pointers-to-pointers to functions (i.e. no quote function). All of which
makes Icon a heck of a lot more of a strict functional language than is
CL, though it does have variable assignment expressions, as well as
destructive functions and though it does not have lambda expressions. It
does have a feature that comes close to lambda expressions and which its
authors call "co-expressions;" these co-expressions are co-routines that
can be created more or less dynamically from regular Icon expressions.
Perhaps you should take a look at the introduction to Icon that can be
found in cs.arizona.edu:/icon/doc/tr-90.6.doc (also tr-90.6.ps.Z). Its
quite short...

>Wolfgang
>--

>Wolfgang Lux
>WZH Heidelberg, IBM Germany IBM IP-Net: l...@rio.heidelbg.ibm.com
>+49-6221-59-4546 VNET: LUX at HEIDELBG
>+49-6221-59-3300 (fax) EARN: LUX at DHDIBMIP


Nick

Henry G. Baker

unread,
Aug 1, 1994, 10:54:06 AM8/1/94
to
In article <CtuG1...@world.std.com> jha...@world.std.com (Joseph H Allen) writes:
>>??????????? 'Type inference' _hurt_ readability?? Perhaps you meant type
>>declarations?
>
>IMHO, except for trivial programs, declarations improve readability because
>you can easily figure out what is stored in variables and arguments and
>don't have to trace constants or depend on operators not being overloaded.
>You can jump into the middle of a program and start modifying it without
>comprehending all of it. It makes your programs less general perhaps, but
>definitly more readable. Likewise, structures (records) are better than
>lists and tuples.

Aha! We've finally smoked you out! What you are complaining about is
the lack of a good code browser which would tell you what a compiler
knows about the various constructs that it sees. Rather than have to
specify all this redundancy every time I write a program, wouldn't it
be better to have the program tell me what it thought? This would be
a much better tradeoff in terms of my time vs. the computer's time.
For what it's worth, such a code browser is much easier to write, due
to (you guessed it) Lisp's trivial syntax.


Thomas M. Breuel

unread,
Aug 1, 1994, 2:40:29 PM8/1/94
to
In article <Ctu43...@world.std.com> jha...@world.std.com (Joseph H Allen) writes:
|I agree. Common lisp is hopeless. Its standard manual is longer than that
|of _every_ _other_ programming language and its syntax diverged from the
|lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
|ideal lisp is not powerful or convenient enough for a real language.

CommonLisp is not particularly complicated by modern standards. Most
of CLtL/2 describes what in other languages is part of a separate
library standard. And CLtL/2 describes a language that is
substantially simpler than, say, C++ and several other successful
modern languages.

Still, CommonLisp probably should be simpler...

Thomas.

Thomas M. Breuel

unread,
Aug 1, 1994, 2:44:00 PM8/1/94
to
In article <Ctu43...@world.std.com> jha...@world.std.com (Joseph H Allen) writes:
|The major semantic paradigms present in scheme/lisp are:
|
|1 Closures
|2 Loops through tail-recursion and lambda functions
|3 Type inference
|4 Self-representation through common list syntax

Type inference is definitely not a "semantic paradigm" of Scheme or
Lisp. Type inference is mainly used in statically typed functional
programming languages like SML and Haskell. Scheme and Lisp use
dynamic typing.

Thomas.

Marco Antoniotti

unread,
Aug 1, 1994, 9:30:06 AM8/1/94
to
In article <CtuMB...@world.std.com> jha...@world.std.com (Joseph H Allen) writes:

In article <RV.94Au...@tahoe.cs.brown.edu>,
rodrigo vanegas <r...@cs.brown.edu> wrote:

>Finally, this long thread has reached the heart of what i believe to
>be the principal reason why we can't do without lisp.

>In article <Ctu43...@world.std.com>, jha...@world.std.com
(Joseph H Allen) writes:
>> The major semantic paradigms present in scheme/lisp are:
>
>> 1 Closures
>> 2 Loops through tail-recursion and lambda functions
>> 3 Type inference
>> 4 Self-representation through common list syntax

>> 1 is the most important one, and is syntacticly possible with other
>> languages. Most functional languages have closures. Other
>> static languages
>> don't have them because they do not sit well with stack-based local
>> variables. For a non-lisp and non-functional language with
>> closures, try my
>> language Ivy.

>1) ML also meets this criteria. It is an impure functional language
>(meaning it has assignment which is all you need to program as you
>would in C), and has a pleasant non-lisp syntax.

Yeah, ML's pretty nice.

Except when you FORGET parenthesis! :-) The operator precedence rules
are so contrived that you end up stuffing the code with parenthesis
just to play it safe. :-)

>> 2 and 3 are not necessary, hurt readability and can be
>> considered semantic
>> sugar.

...

IMHO, loop structures should be used in place of tail recursion for
readability. Recursion should, of course, still be possible.

It is the nature of data that makes recursion more suitable than loops
and vice versa.

...

I should have said 'nearly redundant' :-)

Simple macros can be more powerful in lisp than in any other language and
rather easily lead to parameterized classes and other syntax augmentations.

You can also do neat things like easily take the derivatives of mathematical
functions expressed in lisp. But then I don't want to express my functions
in lisp :-) A simple precidence parser is only about a hundred lines long in
any other language, so it's not that big of a deal to use lists for
representation, and infix/prefix for data entry and display.

Have you tried the 'infix.lisp' package from the AI-repository?

>Even so, i will concede without prompting,that if one is not
>interested in either higher-order functions or language
>experimentation, the lisp parentheses become only a nuisance and
>Common Lisp's size just an obstacle to delivery.

Lisp is a neat idea, but to gross to use in practice.

As is ML, Haskell, Miranda, Prolog and I would add FORTRAN, COBOL,
PL/I and, last but not least, C/C++.

So much for the daily religion wars :)

Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab | room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU | e-mail: mar...@cs.nyu.edu

...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
Bertholdt Brecht

David J. Hughes

unread,
Aug 1, 1994, 9:26:58 PM8/1/94
to

I didn't see the original of this, but a language that hasn't been
mentioned in ESL. ESL is a C styled scripting language that provides
the C programmer with a familiar and convenient environment. The 'E'
stands for extensible. I've just had a student add Motif bindings to
ESL so the next release will fit the original question.

ESL itself supports automatic memory allocation for text objects,
arrays, and associative arrays. Assoc's can also be either in-core or
bound to ndbm files without any modification to their usage. Scripts
can also be "compiled" into an architecture neutral format and shiped
onto any box running the ESL interpreter (bit like forth in that regard
- or so I'm told).

There are currently bindings provided for SNMP and also Mini SQL. It
was originally written for use in network management.

I may be biased (probably am since I wrote it :-) but it's a nice
language if your a C programmer. If you want to have a look at it it's
available from ftp://Bond.edu.au/pub/Bond_Uni/Minerva/esl. Like I said,
the Motif support will appear in the enxt release.


__ David J. Hughes - Ba...@Bond.edu.au
/ \ / / / http://Bond.edu.au/People/bambi.html
/___/ __ _ ____/ / / _
/ \ / \ / \ / / / / / \ / Senior Network Programmer, Bond University
\___/ \__// / \__/ \__/ / / / Qld. 4229 AUSTRALIA (+61 75 951450)

Richard Mlynarik

unread,
Aug 1, 1994, 7:48:45 PM8/1/94
to
The whole point of Lisp syntax is that it is trivial, and doesn't require
a full-blown parser to interpret. Unfortunately, Common Lisp's parameter
syntax completely blew that particular advantage.

Improving the 'syntax' of a language is a little like climbing a tree
to make the first step towards the moon. It doesn't accomplish very
much, but it's easy and accessible and allows one to feel superior to
those still standing on the ground. In most cases, people would be
better off dispensing with character-based languages completely (e.g.,
for graphical languages), rather than wasting everyone's time creating
additional parsing and training nightmares.

As I see it, computer "science" as taught is to a large extent a
matter of using YACC and being able to write shell-scripts.

It is sad but unsurprising that people who have mastered (or
bachelored) this rubbish feel that they must constantly demonstrate
and highlight their competence by insisting that it be used as much as
possible.

Hendrik Boom

unread,
Aug 2, 1994, 4:35:39 PM8/2/94
to
I hear the usual complaints on this thread about Lisp's parentheses.
There's been lots of syntaxes for different constructions that would
otherwise be unreadable because of the parentheses. But there's a simple
way to deal with most of the parentheses.

Whenever a parenthesized phrase occurs at the end of another.
use a slash instead of parenthesizing it, thus:
(abf gut ( hnniuf slks))
becomes
(abf gut / hnniuf slks)
this gets rid of most of the parenthesis clusters in Lisp.
It makes it easy to use "if" instead of "cond",
or a "let" without a list, because many such constructs naturally
nest in their last argument.

P.s. another candidate for a "/" is a semicolon, but that looks better at
the end of a lin than at the beginnning:

( if onions bagels
/ if cows milk
/ let horse pony
/ list onions cows horse
)

( if onions bagels ;
if cows milk ;
let horse pony ;
list onions cows horse
)
In my experience, with this feature, most Lisp read-macros
become unnecessary, and much syntactic sugar likewise.

hendrik.

Tim Bradshaw

unread,
Aug 3, 1994, 12:52:07 PM8/3/94
to
* Joseph H Allen wrote:

> IMHO, except for trivial programs, declarations improve readability because
> you can easily figure out what is stored in variables and arguments and
> don't have to trace constants or depend on operators not being overloaded.
> You can jump into the middle of a program and start modifying it without
> comprehending all of it. It makes your programs less general perhaps, but
> definitly more readable.

But I want this to work (yes this is a trivial program, but it could
be part of a non-trivial one, and having to put declarations in at
that level is a serious pain.

(defun foo (n)
(declare (fixnum n))
(dotimes (i n ...)
<use i, compiler knows i is a fixnum>
...))

> Likewise, structures (records) are better than
> lists and tuples.

Which is why people use them in Lisp of course.

--tim

Trevor Blackwell

unread,
Aug 4, 1994, 7:10:42 PM8/4/94
to

There's something about languages with overly complex syntax and
crufty semantic foundations that makes them popular. I wish I
understood it.

The semantics of TCL are truly mind-boggling. I was using it to build
a gui front-end to something (under the dicates of portability).
Suffice to say, I ended up using a couple of global variables to pass
things around.

In fact, I highly recommend trying to write a nontrivial program in
TCL, as a rather enlightening experience. You should particularily try
to use 'uplevel' and 'upvar'. You should also pass associative arrays
around a lot. Try pass closures as the 'action' field of a pushbutton.

On the plus side, TCL interfaces to C very easily. There's no garbage
collection to worry about. Data structures are simple. All in all,
it's a breeze to write tcl commands in C.


Maybe part of the reason for the success of TCL and C++ is this. Lisp
& Smalltalk & ML & your favourite language all provide a number of
simple primitives, which you connect together to form an
application. The primitives themselves are a bit abstract, so it takes
some creativity to apply them in order to reach your goal. With some
experience, though, cranking out common program structures becomes
automatic.

TCL & C++, on the other hand, have language features for many of the
things you might wish to do. So you get a nice warm feeling by looking
in the index for the manual and seeing the thing you want to do there.


You should look at Jeff Ullman's "Elements of ML Programming" as an
example of how to present a language as a large collection of
solutions, rather than as a simple and elegant set of primitives.

I'm not knocking the book - it just has a very different style from
the way I like to think about languages. (You don't learn until
chapter 21 of 26, in the "Additional Details and Features" section,
that you can curry functions.) In fact, I would highly recommend the
book to anyone who wants to learn to program in ML, and hasn't seen
much beyond Pascal or C.


It seems to be the case that language designers have a different way
of thinking about things than inexperienced language users.
"Elements...", like Ousterhout's TCL manual, presents them in a nice,
concrete way that's palatable to beginners. The manuals for any of the
research languages I've used are very different.

To summarize, TCL is succeeding because:
- hello-world-in-an-X-window is 2 lines, and easy to understand
- the manual is very concrete
- the environment is very portable
- there are no abstract concepts you need to learn to write basic programs.

--
--
Trevor Blackwell t...@das.harvard.edu (617) 495-8912
(info and words of wit in my .plan)
Disclaimer: My opinions.

Piercarlo Grandi

unread,
Aug 4, 1994, 2:41:39 PM8/4/94
to
>>> On Mon, 1 Aug 1994 14:54:06 GMT, hba...@netcom.com (Henry G. Baker)
>>> said:

Henry> In article <CtuG1...@world.std.com> jha...@world.std.com
Henry> (Joseph H Allen) writes:

hbaker> ??????????? 'Type inference' _hurt_ readability?? Perhaps you
hbaker> meant type declarations?

jhallen> IMHO, except for trivial programs, declarations improve
jhallen> readability because you can easily figure out what is stored in
jhallen> variables and arguments and don't have to trace constants or
jhallen> depend on operators not being overloaded. You can jump into
jhallen> the middle of a program and start modifying it without
jhallen> comprehending all of it.

A very dangerous attitude indeed, in the general case. And where it
works it has nothing to do with the manifest/latent or static/runtime
typing issue, it can be done because the program is well modularized.

jhallen> It makes your programs less general perhaps, but definitly more
jhallen> readable. Likewise, structures (records) are better than lists
jhallen> and tuples.

Agreed, lists and tuples are too general.

Henry> Aha! We've finally smoked you out! What you are complaining
Henry> about is the lack of a good code browser which would tell you
Henry> what a compiler knows about the various constructs that it sees.

Aha! We've finally smoked you out! You don't believe that programs are
about _communication_, i.e. texts that describe what the author
thinks. If you did, any extra annotations by the author are welcome,
because they enlighten the reader as to the assumptions of the author.

When I read a program I want to understand not what it does (using a
browser or a tracer), but what the author wanted to communicate with
it. _Then_ I shall check that the intent was correctly implemented.

When I see "const x" or "pure y", what I think is not "ah, a read-only
variable", I think "the author assumes that there will be no need to
change this variable's value". When I see "reducible proc p" I know that
in the author's intent the procedure's result only depends on its
arguments.

This is much more informative than just having a browser telling me
whether in fact a variable is or is not modified in a region of code
(and find a browser that will tell you whether a procedure is
reducible!). Of course I want the latter information too... But not
just that. I want to compare intent with actuality.

Henry> Rather than have to specify all this redundancy every time I
Henry> write a program, wouldn't it be better to have the program tell
Henry> me what it thought?

This redundancy is actually descriptive statements of the author's
intent. Communication, useful communication, about design choices. A
browser will not tell me anything about design choices, will only tell
me about what's there, not in the mind of the author.

Henry> This would be a much better tradeoff in terms of my time vs. the
Henry> computer's time. For what it's worth, such a code browser is
Henry> much easier to write, due to (you guessed it) Lisp's trivial
Henry> syntax.

But I still want the author's annotations, perhaps compared to the
annotations synthetized by a browser.

All this assuming that the author agrees that the purpose of a program
text is to communicate a description to the reader, and puts in
descriptive annotations. A rare thing!

Jurgen Botz

unread,
Aug 5, 1994, 4:51:55 PM8/5/94
to
In article <Ctu43...@world.std.com>,

Joseph H Allen <jha...@world.std.com> wrote:
>The major semantic paradigms present in scheme/lisp are:
>
>1 Closures
>2 Loops through tail-recursion and lambda functions
>3 Type inference
>4 Self-representation through common list syntax
>
>1 is the most important one, [...]

No argument there...

>2 and 3 are not necessary, hurt readability and can be considered semantic
>sugar.

I don't think any of these /hurt/ readability, ever, and I can't
imagine what "semantic sugar" might be (I've heard of "syntactic
sugar", i.e. "sweetening" cumbersome syntax by dressing it up, but
before we can talk about sweetening cumbersome semantics, we'd have to
get into an argument over what cumbersome semantics /are/...) Also,
isn't it a bit self-contradictory to claim that something is sugar,
but that it ain't sweet?

>4 is the only one which is really unique to lisp. It's made redundant by 1
>though, so I don't miss it.

I don't see what Lisp's ability to treat programs and data identically
(which is what I assume you mean by self-representation) has to do
with closures? Most Lisp's don't have closures, but they all
represent programs as lists...

On the other hand, Tcl (I started reading this thread in comp.lang.tcl) is
also self-representing in the above sense, but using strings rather than
lists as the fundamental type from which programs are made.

(I removed comp.windows.x from the newsgroups line.)
--
Jurgen Botz, jb...@mtholyoke.edu | Communications security is too important to
Northampton, MA, USA | be left to secret processes and classified
| algorithms. -- USACM

Ted Dunning

unread,
Aug 6, 1994, 3:38:25 AM8/6/94
to

In article <PIERCARL.9...@sabi.sabi.demon.co.uk> pier...@sabi.demon.co.uk (Piercarlo Grandi) writes:

Henry> Rather than have to specify all this redundancy every time I
Henry> write a program, wouldn't it be better to have the program

Henry> tell me what it thought?

This redundancy is actually descriptive statements of the author's
intent. Communication, useful communication, about design choices.
A browser will not tell me anything about design choices, will only
tell me about what's there, not in the mind of the author.


what if my intent is to write a generalized and polymorphic procedure?

don't all those required type declarations get in the way of my
intent?

Bennett Todd

unread,
Aug 5, 1994, 7:40:17 PM8/5/94
to
In article <MLY.94Au...@carrot.adoc.xerox.com>,

Richard Mlynarik <m...@adoc.xerox.com> wrote:
>As I see it, computer "science" as taught is to a large extent a
>matter of using YACC and being able to write shell-scripts.
>
>It is sad but unsurprising that people who have mastered (or
>bachelored) this rubbish feel that they must constantly demonstrate
>and highlight their competence by insisting that it be used as much as
>possible.

As you said, ``to a large extent'', but it isn't universal. There are some
Computer Science departments that strive to treat it as a real academic
science, putting the emphasis on theoretical results.

There are others that chose to pursue it as an engineering discipline, where
the focus is on mastering the range of techniques currently used to get real
work done, with enough theory to leave the students equipped to learn new
techniques as they are evolved.

There seems to be a lag of 10 to 20 years, as best I can see, between the
theoreticians dreaming up new concepts and the engineers putting them to
good use to get work done. Shortening up that lag is desireable, but I don't
see how it can happen; the people who are dreaming up the new concepts
aren't concerned with practical application. In fact, the one school I have
personal experience with had a theoretical bent so strong that they weren't
interested in practical work for academic credit.

So I think the really interesting question is:

What new, better techniques _should_ people be using to get work done?

-Bennett
b...@sbi.com

Mark Kilgard

unread,
Aug 5, 1994, 9:38:26 PM8/5/94
to
In article <TFB.94Au...@burns.cogsci.ed.ac.uk>, t...@cogsci.ed.ac.uk (Tim Bradshaw) writes:

|> * Trevor Blackwell wrote:
|> > There's something about languages with overly complex syntax and
|> > crufty semantic foundations that makes them popular. I wish I
|> > understood it.
|>
|> I think that it's because natural languages are like this too (well,
|> they have complex syntax and semantics, perhaps not overly complex).
|> This however doesn't explain why only *some* people like these
|> programming languages.

There's generally a common reason people like things that are
"crufty" and "complex": job security.

Perhaps that's the reason so many of these complex and crufty
systems are economically viable - and why so many academic systems
are not. Academicians should remember to add a healthy helping of
cruft and complexity to their designs.

Something to think about.

- Mark

Tim Bradshaw

unread,
Aug 5, 1994, 12:50:11 PM8/5/94
to
* Trevor Blackwell wrote:
> There's something about languages with overly complex syntax and
> crufty semantic foundations that makes them popular. I wish I
> understood it.

I think that it's because natural languages are like this too (well,


they have complex syntax and semantics, perhaps not overly complex).
This however doesn't explain why only *some* people like these
programming languages.

--tim

Joseph H Allen

unread,
Aug 7, 1994, 2:55:43 AM8/7/94
to
In article <TED.94Au...@lole.crl.nmsu.edu>,

It depends on the language. You could have a language which lets you
specify that a variable or function argument is any type, one of a set of
types (a union or ML style polymorphic type) or a type of a certain class.

The class method is particularly useful because then you could have any type
which has the proper attributes inherit the class specified for the argument
or variable. The class name is then used for classifying which types are
allowed. You could conceive of a system where integers are in the
whole-number class, the integer-class, and the exact-class, while floats are
in both the whole-number and integer-classes and additionally the
real-class, but not in the exact class.

A debate going on in other newsgroups is "sub-typing vs. sub-classing".
Some think that a value of certain type should be usable in a variable if
the class specified for the variable has method names which are the same as
those of the class of the type. This eliminates the need for inheritance
but I think it also prevents you from using class names as general attribute
specifiers. I would be happier with the sub-classing idea if you had method
names which did nothing but indicate the presence of certain properties that
the type has.

Thomas M. Breuel

unread,
Aug 7, 1994, 4:29:19 PM8/7/94
to
In article <TLB.94Au...@chardonnay.harvard.edu> t...@chardonnay.harvard.edu (Trevor Blackwell) writes:
|Maybe part of the reason for the success of TCL and C++ is this. Lisp
|& Smalltalk & ML & your favourite language all provide a number of
|simple primitives, which you connect together to form an
|application. The primitives themselves are a bit abstract, so it takes
|some creativity to apply them in order to reach your goal. With some
|experience, though, cranking out common program structures becomes
|automatic.

I don't lack the creativity. But I do lack the time. Trying to work
around a lack of numerical libraries, string libraries, and graphics
and GUI libraries requires a _lot_ of time and effort. Likewise,
trying to get some complicated algorithm to run fast and use little
space can be much harder in Lisp or Smalltalk than in C, even if a
simple implementation of the algorithm would be easier in those
languages.

Thomas.

Bryan O'Sullivan

unread,
Aug 8, 1994, 6:12:53 AM8/8/94
to
t...@arolla.idiap.ch (Thomas M. Breuel) writes:

>I don't lack the creativity. But I do lack the time. Trying to work
>around a lack of numerical libraries, string libraries, and graphics
>and GUI libraries requires a _lot_ of time and effort.

This is true. Haskell's standard prelude goes some very small way
towards addressing this, but you invariably end up having to use custom
libraries and compiler features to get half-decent performance (string
manipulation is horribly inefficient in standard Haskell, but a *lot*
faster and more space-efficient if you use the Glasgow Haskell packed
string extensions).

In the Scheme world, SLIB does a nice job of giving you lots of useful
library features, and does it quite portably too. Common Lisp
programmers get an even larger kitchen sink with their systems, so I
think the library problem is more or less solely confined to the more
``experimental'' functional languages (though I assume Yale Haskell
lets you get at a lot of CL baggage without too much pain).

>Likewise, trying to get some complicated algorithm to run fast and use
>little space can be much harder in Lisp or Smalltalk than in C, even if
>a simple implementation of the algorithm would be easier in those
>languages.

I don't know about Smalltalk, but it's not overly hard to get complex
algorithms to go quickly in Lisp or even, dare I say it, Haskell
(though space efficiency will bite you in Haskell). I'd say the amount
of effort required to code an algorithm efficiently in either of these
languages is about the same as that required to get an efficient
algorithm going in C.

<b

--
Bryan O'Sullivan u nas est tolko odyeen yagnyonok seychas.
Computing Science Department email: b...@cyclic.com, b...@dcs.gla.ac.uk
University of Glasgow web.gunge: http://www.scrg.cs.tcd.ie/~bos

Chris Gray

unread,
Aug 8, 1994, 12:12:09 PM8/8/94
to

--tim

I think it is quite simple. People who have trouble with abstract
concepts (like me), prefer languages with the minimum number of
new concepts over those they know from natural language. I am quite
happy to read something that is a few characters longer if it looks
more like something that I already know (English). Consider what is
required to understand:

(cond (< (+ a b) 5)
(setq a 1)
(setq b 1)
)

versus:

if a + b < 5 then
a <- 1;
else
a <- 2;
endif;

This principle works for Cobol, but that language (IMHO) violates
the same principle in another way, by having far too many words
with differing meanings.
--
Chris Gray c...@myrias.ab.ca [C macros - a powerful way to make bugs!]
Myrias Computer Technologies Inc. (403) 463-1337

Henry G. Baker

unread,
Aug 8, 1994, 11:41:10 AM8/8/94
to
In article <TFB.94Au...@burns.cogsci.ed.ac.uk> t...@cogsci.ed.ac.uk (Tim Bradshaw) writes:
>* Trevor Blackwell wrote:
>> There's something about languages with overly complex syntax and
>> crufty semantic foundations that makes them popular. I wish I
>> understood it.
>
>I think that it's because natural languages are like this too (well,
>they have complex syntax and semantics, perhaps not overly complex).
^^^^^^^^^^^^^^

>This however doesn't explain why only *some* people like these
>programming languages.


IMHO, Terry Winograd showed that the _syntax_ of English is trivial, and
that what NL types were trying to do with parsing and syntax is much better
left to semantic analysis.

The problem with Enlish is analogous to the problem with certain
graphical languages: after you select certain entities to play a part
in the next operation, it is up to the operation to try to figure out
what role each entity will play, based on the semantics of the
operation and the characteristics of the entities.


Henry G. Baker

unread,
Aug 8, 1994, 11:43:20 AM8/8/94
to

I thought that adding cruft and complexity was the role of the ANSI/IEEE
standardization committee. :-)

Amancio Hasty Jr

unread,
Aug 8, 1994, 5:41:53 PM8/8/94
to
Any comments or experiences with TAOS?

There a nice article in the Byte Magazine about it. I think in the
June issue...

What I like about TAOS is that the compilitation output is targeted
to a virtual machine. When objects are loaded, the system compiles
them into the native machine code. Supposedly the assembly process
is very efficient.

Tnks,
Amancio
--
FREE unix, gcc, tcp/ip, X, open-look, netaudio, tcl/tk, MIME, midi,sound
at freebsd.cdrom.com:/pub/FreeBSD
Amancio Hasty, Consultant |
Home: (415) 495-3046 |
e-mail ha...@netcom.com | ftp-site depository of all my work:
| sunvis.rtpnc.epa.gov:/pub/386bsd/X

Steven D. Majewski

unread,
Aug 8, 1994, 6:59:44 PM8/8/94
to
In article <Ctu43...@world.std.com>,
Joseph H Allen <jha...@world.std.com> wrote:
>
>I agree. Common lisp is hopeless. Its standard manual is longer than that
>of _every_ _other_ programming language and its syntax diverged from the
>lisp ideal since the introduction dotted-pairs and ' for quoting. Perhaps
>ideal lisp is not powerful or convenient enough for a real language.
>

The length of a language manual is not a commensurate metric.

"Common Lisp, the Language" has more complete and detailed
coverage of it's language than almost any other manual I've seen. Guy
Steele ( the editor of CLtL ) was also the coauthor of a reference
manual for C which was 2 or 3 times as long as K&R. Steele's C manual
was as detailed as the Lisp manual, with discussion and justifications
of various ANSI features, and comparison with non-ANSI compilers, etc.
A lot of explaination of WHY and WHY-NOT.

The functional equivalent of the same level of documentation
for C would be Harrison & Steele's C Reference Manual *PLUS* another
book on portability and the standard C libraries. This would probably
equal the page count of CLtL1 ( The first version, which is the one
I have on my shelf. CLtL2, which adds documentation for CLOS probably
regains the record again. )

I'm not arguing that Common Lisp isn't, in many ways, a complex
language. Just that the size of the manual is NOT usually a reasonable
mesaure of complexity. ( I could also argue that there are different
TYPES of complexity, and that some types are better/worse than others,
but I'll save that argument for later! )

- Steve Majewski (804-982-0831) <sd...@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics

Ted Dunning

unread,
Aug 8, 1994, 4:41:21 PM8/8/94
to

In article <Cu8nv...@murdoch.acc.Virginia.EDU> sd...@elvis.med.Virginia.EDU (Steven D. Majewski) writes:

The functional equivalent of the same level of documentation
for C would be Harrison & Steele's C Reference Manual *PLUS* another
book on portability and the standard C libraries.

plus a complete reference on c++ and associated object libraries along
with specification of the hooks available to build a class browser
(i.e. a metaobject protocol).

This would probably
equal the page count of CLtL1 ( The first version, which is the one
I have on my shelf. CLtL2, which adds documentation for CLOS probably
regains the record again. )

not after you mention c++, it doesn't. and c alone is a much more
like what cltl1 describes.

Larry W. Virden

unread,
Aug 9, 1994, 7:21:15 AM8/9/94