And, Why Didn't Dijkstra Like Lisp?

http://kazimirmajorinc.blogspot.com/2010/05/and-why-didnt-dijkstra-like-lisp.html

by fogus • 16 years ago

86 44 16 years ago

kazimirmajorinc.blogspot.com

j_baker• 16 years ago

Dijkstra's opinion on Lisp appears to have eventually changed though:

http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD03x...

"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...

"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• 16 years ago

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!

slashcom• 16 years ago

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

fleitz• 16 years ago

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

DannoHung4• 16 years ago

> 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.

corruption• 16 years ago

Could you go into your interpretations of the implications?

devinj4• 16 years ago

> 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.

tzs• 16 years ago

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

You could use type size, with operators one point larger than their operands. The nice thing is that this would discourage nesting things too deeply.

rdtsc• 16 years ago

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

Perhaps you could use indentation like Python or YAML, for example?

philh• 16 years ago

> functions as values in Mathematics just isn't considered as "normal" outside of fields concerned with the fundamental basis of mathematics.

It seems to be fairly common in linear algebra. The usual way to represent a linear function is as a matrix, and a function on that matrix is a function on a function. You also get fields of polynomials, in which differentiation is a linear operator.

wendroid5• 16 years ago

It's just that your eyes are closed, these are just about equivalent (same no of () anyway) :

    i.hate(parentheses).split().doyou()
 or
 
    (doyou (split (i.hate parentheses)))

"GOTO Considered Harmful" Considered Harmful

http://www.ecn.purdue.edu/ParaMount/papers/acm_may87.pdf

You use GOTO every time you turn on the computer, though JMP is the mnemonic instead.

zandorg• 16 years ago

But JMP is in a low-level language, and he's talking about higher level ones.

daniel-cussen2• 16 years ago

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.

ekiru2• 16 years ago

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• 16 years ago

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

daniel-cussen2• 16 years ago

Yeah, but in Java, you need four kinds of punctuation right off the blocks.

olliesaunders• 16 years ago

You get a similar sort of experience with concatenative languages too.

jacquesm2• 16 years ago

I didn't even know that such a thing existed until today, here is the other thread:

http://news.ycombinator.com/item?id=1373046

wheaties• 16 years ago

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.

ced• 16 years ago

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.

jergosh• 16 years ago

Saying that Dijkstra blogged sounds very wrong somehow.

biotech• 16 years ago

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• 16 years ago

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.

wendroid5• 16 years ago

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• 16 years ago

> 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.

wendroid5• 16 years ago

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.

wendroid5• 16 years ago

I should also say that I have experience working with Manchester cpus (AVR microcontrollers) where the code is fixed when you flash it and you cannot jmp into RAM. Of course one then writes an interpreter instead :)

And, Why Didn't Dijkstra Like Lisp?

Related Stories