6 ms·

And, Why Didn't Dijkstra Like Lisp?

86 points by fogus 16y ago

j_baker 16y ago
Dijkstra's opinion on Lisp appears to have eventually changed though: http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html 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/EWD12xx/EWD1284.html 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 16y 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 16y ago
Dijkstra had some fairly strong opinions on a lot of things in CS.
fleitz 16y 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
- DannoHung 16y 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 16y ago
    Could you go into your interpretations of the implications?
    - DannoHung 16y ago
      I am ill equipped to express it eloquently, unfortunately. But in poor words, it means that we can find unification between fields of mathematical thought. Taking ideas from one area, finding ways to regularly manipulate them, and then applying them in a novel way. Being able to find parallels between unrelated work because they are similar in how they are transformed. Abstract algebra is the subject dedicated to that notion in general, category theory the one that, it would seem, is explicitly dedicated so.
daniel-cussen 16y 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.
- ekiru 16y 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 16y ago
    But parenthesis are the only required punctuation. Any of those others you mentioned can be equivalently expressed by parenthetical expressions. Homoiconicity is preserved.
    - ekiru 16y ago
      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.
wheaties 16y 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.
wendroid 16y 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 16y 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.
  - wendroid 16y 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.
  - wendroid 16y 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 :)
ced 16y 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 16y ago
Saying that Dijkstra blogged sounds very wrong somehow.
biotech 16y 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 16y 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.

86 points by fogus 16y ago

Dijkstra's opinion on Lisp appears to have eventually changed though: http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html 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/EWD12xx/EWD1284.html 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 16y 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 16y ago

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

fleitz 16y 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

DannoHung 16y 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 16y ago
  Could you go into your interpretations of the implications?
  - DannoHung 16y ago
    I am ill equipped to express it eloquently, unfortunately. But in poor words, it means that we can find unification between fields of mathematical thought. Taking ideas from one area, finding ways to regularly manipulate them, and then applying them in a novel way. Being able to find parallels between unrelated work because they are similar in how they are transformed. Abstract algebra is the subject dedicated to that notion in general, category theory the one that, it would seem, is explicitly dedicated so.

daniel-cussen 16y 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.

ekiru 16y 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 16y ago
  But parenthesis are the only required punctuation. Any of those others you mentioned can be equivalently expressed by parenthetical expressions. Homoiconicity is preserved.
  - ekiru 16y ago
    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.

wheaties 16y 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.

wendroid 16y 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 16y 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.
- wendroid 16y 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.
- wendroid 16y 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 :)

ced 16y 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 16y ago

Saying that Dijkstra blogged sounds very wrong somehow.

biotech 16y 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 16y 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.