Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!MathWorks.Com!uhog.mit.edu!sgiblab!sgigate.sgi.com!olivea!news.hal.COM!decwrl!pacbell.com!amdahl!netcomsv!netcom.com!hbaker
From: hbaker@netcom.com (Henry G. Baker)
Subject: Re: Why do people like C? (Was: Comparison: Beta -
Message-ID: <hbakerCxqvs3.1C8@netcom.com>
Organization: nil
References: <37p0uq$2gn@omnifest.uwm.edu>
Distribution: na
Date: Sun, 16 Oct 1994 02:48:03 GMT
Lines: 61

In article <37p0uq$2gn@omnifest.uwm.edu> mark@omnifest.uwm.edu (Mark Hopkins) writes:
>One might also look at the syntax as an obvious reason a preference for C.
>LISP, itself, was never meant to be a purely bracketed language.  That
>syntax was designed as a holdover until the language could be complete --
>a first generation in a bootstrapping process.  It's just that the McCarthy
>never got around to finishing his project.  Undoubtedly, part of the reason
>was that Context Free Grammars were hardly even known back then.

McCarthy's actual quote from the 1978 History of Programming Languages
Conference is:

"The project of defining M-expressions [the infix notation from the
1960 CACM paper] precisely and compiling them or at least translating
them into S-expressions was neither finalized nor explicitly
abandoned.  It just receded into the indefinite future, and a new
generation of programmers appeared who _preferred_ internal notation
to any FORTRAN-like or ALGOL-like notation that could be devised."
[emphasis supplied]

again McCarthy:

"One can even conjecture that LISP owes its survival specifically to
the fact that its programs are lists, which everyone, including me,
has regarded as a disadvantage.  Proposed replacements for LISP, e.g.,
POP-2 (Burstall 1968, 1971) abandoned this feature in favor of an
Algol-like syntax _leaving no target language for higher level
systems_."  [emphasis supplied]

So, McCarthy admitted that his initial prejudice in favor of infix
style languages was _wrong_.  Infix notation goes to a lot of trouble
to make arithmetic look natural, but makes everything else less
natural.  Since the percentage of arithmetic expressions with more
than one operation in Lisp programs is vanishingly small (actually, it
is in _every_ programming language, including Fortran), it makes more
sense to make the common operations easy, and put up with a slightly
less comfortable notation for the few more complicated arithmetic
expressions that are encountered.

The existence of trivial syntax makes macros both simply and
profoundly powerful.  One can, and often does, build rather
sophisticated compilers for brand-new sublanguages which are
appropriate for a particular application.  So one gets paid back
_immediately_ 10X to 100X in productivity for the slight inconvenience
of a syntax that doesn't happen to be taught in graded school.

>LISP is, after all, the second oldest language in common use.

Yes, and it is now old enough that many of its proponents are willing
to blithely throw away some of the most powerful and productive
features of the language -- e.g., trivial syntax, programs as _lists_
(not character strings in a file system), reflexivity (eval), etc.

"Pragmatic Parsing in Common Lisp".  ACM Lisp Pointers 4,2 (Apr-Jun
1991), 3-15, shows how to parse strings and lists in Lisp, but
simultaneously shows how macros and reader macros can be effectively
used to extend the language -- something impossible to conceive in
C/C++/...  (In my ftp directory.)

      Henry Baker
      Read ftp.netcom.com:/pub/hbaker/README for info on ftp-able papers.

