
And, Why Didn't Dijkstra Like Lisp? - fogus
http://kazimirmajorinc.blogspot.com/2010/05/and-why-didnt-dijkstra-like-lisp.html
======
j_baker
Dijkstra's opinion on Lisp appears to have eventually changed though:

[http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD03x...](http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html)

"The third project I would not like to leave unmentioned is LISP, a
fascinating enterprise of a completely different nature. With a few very basic
principles at its foundation, it has shown a remarkable stability. Besides
that, LISP has been the carrier for a considerable number of in a sense our
most sophisticated computer applications. LISP has jokingly been described as
"the most intelligent way to misuse a computer". I think that description a
great compliment because it transmits the full flavour of liberation: it has
assisted a number of our most gifted fellow humans in thinking previously
impossible thoughts."

[http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD12x...](http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html)

"I must confess that I was very slow on appreciating LISP's merits. My first
introduction was via a paper that defined the semantics of LISP in terms of
LISP, I did not see how that could make sense, I rejected the paper and LISP
with it. My second effort was a study of the LISP 1.5 Manual from MIT which I
could not read because it was an incomplete language definition supplemented
by equally incomplete description of a possible implementation; that manual
was so poorly written that I could not take the authors seriously, and
rejected the manual and LISP with it. (I am afraid that tolerance of
inadequate texts was not my leading characteristic)."

~~~
JeanPierre
Yeah, I always thought Dijkstra liked LISP because of the "the most
intelligent way to misuse a computer"-quotation. When I read that text, I was
completely confused.

Thanks for the heads up!

------
ced
It's not fair to say that Lisp programs "modify their own instructions",
certainly not in the sense that some assembly programs do. Lisp macros are
better thought of as code _generators_ , or as small compilers. They should
never modify their inputs.

It'd be an error to modify code in Common Lisp anyway. But presumably, back
when Lisp was mostly interpreted, it would have been possible. I wonder how
much that was used.

Hey, in a dynamically-scoped, interpreted Lisp, would it be possible to
simulate a closure by modifying code? Assuming that a list whose CAR is
'LAMBDA is a proper function, then one could simply replace the closed over
variables with SUBLIS, at run-time. Then add in a level of indirection to get
mutability. That'd be horribly slow, granted.

------
biotech
The article quotes McCarthy musing about a possible successor language to
lisp:

"[the language] will be more like a declarative description of the facts about
a goal and the means available for attaining it than a program per se."

It sounds like he's talking about Prolog.

~~~
jurjenh
Also sounds a little like O-Meta (at least from what I understand of it...) -
which is something Alan Kay and others have been working on for a fair while
now. And this seems a little more alive and modern than prolog.

This seems to take a similar approach, by simplifying (once you understand it)
the programming method, and by doing so, drastically reducing the LOC needed
for a functional system.

------
wheaties
I felt like I had a flash back to 1983, staring at a black screen with green
letters. It took a second to realize I would not going to be reading BASIC.

------
daniel-cussen
I've been teaching Lisp to a friend and one of the things he likes best is the
syntax. He likes that there is only one kind of punctuation, the parenthesis.

~~~
ekiru
Well, that's not really the case. Parentheses are the main type of bracket
used in most Lisps(which can be nicer than having [], (), and {}, some of
which frequently have entirely different meanings depending on what syntactic
context they are used in(for example, languages which use "{}" for both blocks
and dictionaries, or "[]" for both list/array construction and indexing)).
However, in Common Lisp for example,(with many present in other lisps) there's
also the quote, the semicolon, the double quote for strings, the backquote and
comma for partial quoting, #\ for character literals, #' for functions, #( )
for vectors, #* for bitvectors, #: for uninterned symbols, #. for read-time
evaluation, #B for binary rational literals, #O for octal, #X for hexadecimal,
#R for arbitrary bases, #C for complex numbers, #A for arrays, #S for
structures, #P for paths, #n=foo and #n# for labeling objects for back-
reference, #+ and #- for read-time testing for available features, and #| |#
for comments. And of course, Common Lisp supports reader macros, so you could
end up with a lot of potential syntactic punctuation.

Of course, most of the time, you won't need most of that syntax. And, it does
have the advantage of mostly being defined in Common Lisp and being fairly
consistent.

But parentheses are definitely not the only punctuation in Lisp.

~~~
lukev
But parenthesis are the only _required_ punctuation. Any of those others you
mentioned can be equivalently expressed by parenthetical expressions.
Homoiconicity is preserved.

~~~
ekiru
I don't think that that is true, at least not for Common Lisp.

How do you express any of the following constructs using only parentheses and
symbols?

#:foo #.(foo) #+ FOO (bar) #- FOO (baz)

For the original Lisp, parentheses and symbols were all that was necessary.
For more recent derivatives, that is not necessarily the case.

~~~
astine
Well, Packages are a reader-hack, so you couldn't express them with
parenthesis, although you should be able to IMHO.

 _#+FOO (bar)_

This could almost be: (when (member FOO _features_ ) (bar)) Just wrap it in an
eval-when.

------
slashcom
Dijkstra had some fairly strong opinions on a lot of things in CS.

------
jergosh
Saying that Dijkstra blogged sounds very wrong somehow.

------
fleitz
I can't say that I love the sheer number of parentheses required by the
language.

However, the code is data idea seems genius to me.

Most of the criticisms seem subjective, perhaps McCarthy and Dijkstra had
different problems to solve and thus chose different tools.

(Mea culpa: every now and then when I use a goto)

I wonder what Dijkstra would have thought about this: grep -R goto
linux-2.6.34

~~~
DannoHung
> I can't say that I love the sheer number of parentheses required by the
> language.

Come up with a better way of representing an Abstract Syntax Tree in text,
please.

> However, the code is data idea seems genius to me.

You know, I think that the reluctance to use functions as values in
programming by some of the early luminaries is that functions as values in
Mathematics just isn't considered as "normal" outside of fields concerned with
the fundamental basis of mathematics. Since the computer itself doesn't need
to be described nor does it necessarily benefit from those terms, it doesn't
immediately take hold that programs running on computers are a lot easier to
reason about once you've got functions being treated as values.

I mean, take differentiation and integration: fundamentally, those are two
functions that you can run on another function to get a third function as a
result. Does it ever actually get taught that way? I mean, is the implication
of that really remarked upon? You go over the fundamental theorem of calculus
in about twenty minutes in the first introduction to it, and then bam, here's
all the shortcuts for differentiating. No reflection on just what the
implications of that are.

~~~
devinj
> Come up with a better way of representing an Abstract Syntax Tree in text,
> please.

If in programming what we're really doing is telling the compiler stuff, and
the compiler only sees an abstract syntax tree, traditional syntaxes are a way
of representing an AST in text, and commonly considered to be "better" by the
particular language's adherents (Ruby programmers like Ruby syntax, Java
programmers like Java syntax, etc.). Sure, you don't get to apply proper
macros, but Java/Ruby/etc. programmers don't care about that. What
representation is "better" really boils down to taste and opinion.

~~~
DannoHung
I think you're focusing on the wrong part of Abstract Syntax Tree. Lisp,
fundamentally, has no syntax. It's just trees. That's the crux of how you
write it. When fleitz said that he doesn't like the parens, I was just
commenting, perhaps in too pithy a fashion, that the parentheses are
incidental to the language. A vessel to hold the substance, as a glass holds
water, if you will.

~~~
devinj
I see what you mean. But I don't think that's what he meant by Lisp.

After all, if you believe that, then Python is a Lisp too[1]. And when people
say "Lisp", they don't mean "Scheme and CL and [...] and Python".

Sure, like any class of languages, there is not a single syntax. But every
lisp has a syntax. And the languages people associate with the class "Lisp"
use parens. And in many peoples' opinions, there are better ways of
representing an AST. Like indentation, for example. Or curly brackets.

1: <http://norvig.com/python-lisp.html>

~~~
DannoHung
You'll notice that in the first paragraph there, he says:

> Python supports all of Lisp's essential features except macros, and you
> don't miss macros all that much because it does have eval, and operator
> overloading, and regular expression parsing, so some-- _but not all_ \--of
> the use cases for macros are covered.

Macros are a huge part of Lisp. Were they not, I don't think you'd see Lisp
programmers defending the bare bones not-syntax so fiercely.

For what it's worth, if you get good at a language, you start decomposing
things into trees yourself when you're faced with some tricky code.

------
wendroid
I think it's a bit disingenuous to say that such dislike is nailed to Lisp.
Mixing data and code in the memory of a running program is what has lead us to
every exploit involving a buffer overflow or a stack smash.

I expoect a different class of problems in their place but self modifying code
is rightfully highlighted as unprovably correct.

Lisp is not the only language that can build a string and throw it at an eval
function.

~~~
jpr
> Mixing data and code in the memory of a running program is what has lead us
> to every exploit involving a buffer overflow or a stack smash.

Not exactly. The totally unsafe programming model of C is what has caused
this. Once you have untyped pointers that need not point to objects owned by
your program, it is _very_ easy to fuck something up.

> Lisp is not the only language that can build a string and throw it at an
> eval function.

Well, evaluating a string in (Common) Lisp just returns the string. Evaluating
a symbol or list will actually do something interesting.

~~~
wendroid
Well, you know what I mean re: the last bit, it's not just Lisp that can
modify code at runtime.

As for C, it's not just the fault of pointers. You just can't shellcode
something that doesn't execute data.

Like I say, we'd just have a different class of problems, so it's not a
panacea.

