Why do people like C? (Was: Comparison: Beta -
Mark Hopkins
(In relation to C's argv, argc interface)
From mi...@pacifix.cs.uoregon.edu:
> Of course, in Lisp you wouldn't need argc, because Lisp arrays
> record their own length... :-)
And there you have it, the essential difference and the preference for C.
One language gives you the option to include X in Y or not, and the other
does not.
In general, this will argue for any low-level language with an unencumbered
implementation (e.g. no behind-the-scenes subterfuges or processes), which
simultaneously also has an abstraction facility in it to allow you to
write applications in as high a level manner as you want. In other words, a
language that is low level and high level at the same time.
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.
LISP is, after all, the second oldest language in common use.
Henry G. Baker
>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.
Erik Naggum
| And there you have it, the essential difference and the preference for
| C. One language gives you the option to include X in Y or not, and the
| other does not.
|
| In general, this will argue for any low-level language with an
| unencumbered implementation (e.g., no behind-the-scenes subterfuges or
| processes), which simultaneously also has an abstraction facility in it
| to allow you to write applications in as high a level manner as you
| want. In other words, a language that is low level and high level at
| the same time.
have you looked behind the scenes of the C language recently? it's naīve
to believe that nothing wild is going on. for starters, see malloc and
free. then look at longjmp. then at the calling sequence and techniques
for variadic functions compared to non-variadic functions. take a look at
the stack frames of function calls in C programs when you feel ready to be
let down.
have you looked behind the scenes of those "high-level" programs done in C?
they're implementing badly what lisp compiler builders have worked on,
specifically, to make efficient, not kluge up to make their programs run at
all. this difference of focus makes the behind-the-scenes view of such
applications much, much less appealing than that of a language with real
support for these things.
because of the mess behind the scenes in C, you can't even build all the
real languages you want in it without either too much overhead or lots of
non-portable assembly code.
| One might also look at the syntax as an obvious reason a preference for
| C.
obvious? I think you should look at C's typedef when you have some spare
time. and be sure to take a close look at the "macro preprocessor".
| 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.
could you provide some references for this history lesson? I'd like to
update my insufficient view on this one.
| LISP is, after all, the second oldest language in common use.
so? how long do you think C will survive the test of time, or C++?
I thought I knew all there was to know about programming, and found it more
and more boring as time went on. then I had to use C++, and since that is
the most horribly kluged language in popular existence, I started to look
around for real languages. it has been a humbling experience. so much fun
is going on in functional languages! not just syntax, but ideas, concepts,
principles. and, what's worse, it's been going on for decades. it's just
that I lost out on all this while I thought C was the Language. bummer.
#<Erik>
--
Microsoft is not the answer. Microsoft is the question. NO is the answer.
Mark Hopkins
part of the C Library. I could even use my own version if I wanted.
Mark Hopkins
> So, McCarthy admitted that his initial prejudice in favor of infix
You're arguing the case of people's preferences based on the authority of a
person who you've already established to be 180 degrees out of synch with
peoples' preferences. Therefore, one must infer the exact opposite from
his current position.
Tim Bradshaw
> | 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.
> could you provide some references for this history lesson? I'd like to
> update my insufficient view on this one.
It is I think basically true. The paper by Steele & Gabriel (`History
of Lisp' which is at least at
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/doc/history/evo_lisp.pgz)
says pretty much this: there was intended to be a different representation for
lisp programs (and maybe sexps were for data?) but then someone wrote
an interpreter using the standard syntax and it stuck.
Of course that doesn't alter the fact that Lisp is way easier to type
for me than languages with spot plague like C.
--tim
Jeff Dalton
>| 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.
>
>could you provide some references for this history lesson? I'd like to
>update my insufficient view on this one.
That "history" contains elements of the truth but is misleading.
And since I just happened to write something on this a while back,
I can repeat it here (below).
BTW, a CFG appears in the Lisp 1.5 book and McCarthy was presumably
familiar with the BNF work for Algol. So even if we suppose CFGs
weren't available on Day One, they were there in plenty of time for
Lisp 1.5.
Some history:
The list / S-expr notation for Lisp was not originally meant to be
used for programming. Instead there were M-exprs which looked more
like an ordinary language. A translation from M-exprs to S-exprs
was defined so that Lisp programs could be represented using a
data structure that could be manipulated in Lisp. That made it
possible to write a "universal function" (interpreter) for Lisp
in Lisp. McCarthy wrote it in the M-notation and, it seems,
thought of it as having chiefly theoretical interest. Steve Russell
then noticed that it could be "hand compiled" to give an actual
interpreter, and we've been using the S-expr notation ever since.
In fact, the notation was surprisingly popular, and alternative
syntaxes have not been very successful. Nonetheless, M-exprs are
still around here and there. McCarthy has used a version of the
notation in lecture notes, John Allen's Anatomy of Lisp uses
M-exprs, and a fairly recent textbook whose name I've forgotten
used M-exprs and even provided a reader for them so that students
could use them to write programs.
Anyway, here's an example:
mapcar[fn;l] =
[null[l] -> ();
t -> cons[fn[car[l]]; mapcar[fn; cdr[l]]]]
";"s and "[...]"s are very common. f[a;b] is a two-arg fn call.
The [p1 -> e1; p2 -> e2; ...; pn -> en] is a conditional expression.
It can be translated directly into COND, which is where COND gets its
somewhat odd syntax.
>| LISP is, after all, the second oldest language in common use.
Lisp is not really a single language these days.
-- jeff
Jeff Dalton
>* Erik Naggum wrote:
>> | 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.
>
>> could you provide some references for this history lesson? I'd like to
>> update my insufficient view on this one.
>
>It is I think basically true.
Well, let's see.
The list syntax was not designed as a holdover.
Lisp doesn't lack an M-expr parser because "McCarthy never got around
to finishing his project".
There's substantial reason to doubt that the status of CFGs was
a factor. (See e.g. my earlier message.)
But, ok, there's a little left that is basically true.
-- jd