6 ms·

Richard P. Gabriel: The Art of Lisp & Writing

59 points by astine 17y ago

mark_l_watson 17y ago
An old article, but a great read. Tying together writing and programming Lisp is insightful and if I could extend his ideas a little: writing using a light weight but very powerful tool like Latex seems similar to programming in a Lisp environment that may also be powerful but after a learning curve, the language and environment stay out of your way. Writing with Latex seems that way to me.
- expeditious 17y ago
  > writing using a light weight but very powerful tool like Latex Can you please explain in what way LaTeX is lightweight? IIRC, LaTeX is a macro layer above TeX which is a layer above something written in "web" which (don't know the details here, but) I think may be translated to C (web2c) for building. Also, last time I looked, the Texlive distribution is something like at least 100 MB.
  - mark_l_watson 17y ago
    Light weight in the sense that adding Latex formatting to a text document is easy and does not (much) get n the way of writing. Also, moving material around, referring to figures, sections, etc. is all easy. I have not tweaked my Latex setup in a long time.
KirinDave 17y ago
It really irks me when people misrepresent the discovery of quantum effects as some kind of science-shattering event that overturned everything we knew, setting scientists kicking stones for the next 80 years. But it's a whole new level of wtf to say, “at least opening the door for a new kind of formulation (other than mathematics) for describing the truth about reality.” What? Otherwise, good article.
- archgoon 17y ago
  That and the line "Scientists, though, perhaps because of their desire for accuracy and precision have had the worst luck of all in pinning down the truth of the universe." convinced me it would be a waste of time to continue with the article.
plinkplonk 17y ago
"The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you're inadvertently making." Lisp vs Java is one thing but there is an undercurrent of "static typing is terrible" running through this paragraph (and others). I am not sure I agree. Haskell for example is very expressive(at least to me). And I am not sure a static type system gets in the way of "prototyping" much. "Lisp, of course, and especially Common Lisp are my languages. Not since the 1960s have I programmed professionally in a language other than Lisp." With all due respect to Richard Gabriel, (and this probably blasphemy) perhaps he should? Haskell or Erlang or Factor are mind expanding in ways Common Lisp never was. (Not to deride Common Lisp, but I am tired of people implying it is some kind of unsurpassed acme of language design excellence)
- asimjalis 17y ago
  "Haskell or Erlang or Factor are mind expanding in ways Common Lisp never was." I see Lisp is more mind-reflecting beyond just being mind-expanding. It's easier to write Haskell programs in Lisp than the converse.
  - plinkplonk 17y ago
    " It's easier to write Haskell programs in Lisp than the converse." You can write a compiler for one in the other (as you could do with any two Turing Complete programming languages), but other than that this seems to be a meaningless play on words. But, ok let us take your claim that it is "easier to write Haskell programs in lisp than lisp programs in Haskell". Care to point at some specific significant "haskell programs in lisp" that are "easier to write" than the corresponding "lisp programs in haskell" that are harder to write?
    - devinj 17y ago
hxa7241 17y ago
> ". . . most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art." This is not a very good way of putting it. The essence of engineering is determinate knowledge, i.e. scientific, logical knowledge. That is not to say it excludes other things, or that that essence alone is sufficient, just that it is the definitive, distinctive, fundamental feature. Experiment produces determinate knowledge -- the most specific, detailed kind. Scientific research produces the broad, general know-how, and experiment fills the gaps for a particular task. If engineering were not fundamentally about determinate knowledge, then experiment could not work. The knowledge produced by the experimental trial would not even have the generality to transfer to the intended use. Associating engineering and software with art seems of little value. From what I remember of aesthetic philosophy, art does not have substantial, useful, or perhaps any correspondence with engineering -- let alone the vagueness of what art is anyway. One cannot fault the real content of the article, but the arty leaning is ultimately empty. The limit of engineering is evolution, not art. When there is no knowledge, engineering design can't work, and instead evolution is the way. Proof of the effectiveness of that alternate approach is all around.
chipsy 17y ago
I'm pretty sure that Lisp isn't as worthy as Gabriel paints it, for this simple reason: We grasp the static-verse more readily than the dynamic. At most levels of work, we aren't actually making enormous changes all at once - even in the writing analogy, a story has to be written one sentence at a time, and if the concepts start changing partway through, the rewrite has to be done....one sentence at a time. The breakthrough concept that turns everything on its head is usually itself just one sentence. In programming, we change two lines and then run the program again, we build on known, tested libraries and languages, we develop a concept on paper and then implement it. And because these things are built on a small foundation of logical concepts, we can build the language to ensure ever-greater levels of self-consistency that would otherwise only be manifested at runtime. Feedback loops. The fiction writer has a short feedback loop - the "state" of a story is small - no explosions of complexity as one would get with loops or recursion - so its progression can be kept in her head. The programmer has a longer feedback loop, because her expectation is not to maintain the entire progression of the program in her head, but to let the computer do it and then display the results in some manner. Dynamicness optimizes the feedback loop for greater incrementalism: the program runs until it hits any one point where an irreconcilable error is encountered, and then multiple options are available to fix the error and even let the program continue. Staticness optimizes the feedback loop for "batch" error-checking: the programmer writes a full body of code she thinks is correct, with no run/test cycle to speak of, and then gets all the errors at once. When the program compiles, it works. Since we can't implement either ideology perfectly, it's probably best to have some of _both_.

59 points by astine 17y ago

An old article, but a great read. Tying together writing and programming Lisp is insightful and if I could extend his ideas a little: writing using a light weight but very powerful tool like Latex seems similar to programming in a Lisp environment that may also be powerful but after a learning curve, the language and environment stay out of your way. Writing with Latex seems that way to me.

expeditious 17y ago
> writing using a light weight but very powerful tool like Latex Can you please explain in what way LaTeX is lightweight? IIRC, LaTeX is a macro layer above TeX which is a layer above something written in "web" which (don't know the details here, but) I think may be translated to C (web2c) for building. Also, last time I looked, the Texlive distribution is something like at least 100 MB.
- mark_l_watson 17y ago
  Light weight in the sense that adding Latex formatting to a text document is easy and does not (much) get n the way of writing. Also, moving material around, referring to figures, sections, etc. is all easy. I have not tweaked my Latex setup in a long time.

KirinDave 17y ago

It really irks me when people misrepresent the discovery of quantum effects as some kind of science-shattering event that overturned everything we knew, setting scientists kicking stones for the next 80 years. But it's a whole new level of wtf to say, “at least opening the door for a new kind of formulation (other than mathematics) for describing the truth about reality.” What? Otherwise, good article.

archgoon 17y ago
That and the line "Scientists, though, perhaps because of their desire for accuracy and precision have had the worst luck of all in pinning down the truth of the universe." convinced me it would be a waste of time to continue with the article.

plinkplonk 17y ago

"The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you're inadvertently making." Lisp vs Java is one thing but there is an undercurrent of "static typing is terrible" running through this paragraph (and others). I am not sure I agree. Haskell for example is very expressive(at least to me). And I am not sure a static type system gets in the way of "prototyping" much. "Lisp, of course, and especially Common Lisp are my languages. Not since the 1960s have I programmed professionally in a language other than Lisp." With all due respect to Richard Gabriel, (and this probably blasphemy) perhaps he should? Haskell or Erlang or Factor are mind expanding in ways Common Lisp never was. (Not to deride Common Lisp, but I am tired of people implying it is some kind of unsurpassed acme of language design excellence)

asimjalis 17y ago
"Haskell or Erlang or Factor are mind expanding in ways Common Lisp never was." I see Lisp is more mind-reflecting beyond just being mind-expanding. It's easier to write Haskell programs in Lisp than the converse.
- plinkplonk 17y ago
  " It's easier to write Haskell programs in Lisp than the converse." You can write a compiler for one in the other (as you could do with any two Turing Complete programming languages), but other than that this seems to be a meaningless play on words. But, ok let us take your claim that it is "easier to write Haskell programs in lisp than lisp programs in Haskell". Care to point at some specific significant "haskell programs in lisp" that are "easier to write" than the corresponding "lisp programs in haskell" that are harder to write?
  - devinj 17y ago

hxa7241 17y ago

> ". . . most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art." This is not a very good way of putting it. The essence of engineering is determinate knowledge, i.e. scientific, logical knowledge. That is not to say it excludes other things, or that that essence alone is sufficient, just that it is the definitive, distinctive, fundamental feature. Experiment produces determinate knowledge -- the most specific, detailed kind. Scientific research produces the broad, general know-how, and experiment fills the gaps for a particular task. If engineering were not fundamentally about determinate knowledge, then experiment could not work. The knowledge produced by the experimental trial would not even have the generality to transfer to the intended use. Associating engineering and software with art seems of little value. From what I remember of aesthetic philosophy, art does not have substantial, useful, or perhaps any correspondence with engineering -- let alone the vagueness of what art is anyway. One cannot fault the real content of the article, but the arty leaning is ultimately empty. The limit of engineering is evolution, not art. When there is no knowledge, engineering design can't work, and instead evolution is the way. Proof of the effectiveness of that alternate approach is all around.

chipsy 17y ago

I'm pretty sure that Lisp isn't as worthy as Gabriel paints it, for this simple reason: We grasp the static-verse more readily than the dynamic. At most levels of work, we aren't actually making enormous changes all at once - even in the writing analogy, a story has to be written one sentence at a time, and if the concepts start changing partway through, the rewrite has to be done....one sentence at a time. The breakthrough concept that turns everything on its head is usually itself just one sentence. In programming, we change two lines and then run the program again, we build on known, tested libraries and languages, we develop a concept on paper and then implement it. And because these things are built on a small foundation of logical concepts, we can build the language to ensure ever-greater levels of self-consistency that would otherwise only be manifested at runtime. Feedback loops. The fiction writer has a short feedback loop - the "state" of a story is small - no explosions of complexity as one would get with loops or recursion - so its progression can be kept in her head. The programmer has a longer feedback loop, because her expectation is not to maintain the entire progression of the program in her head, but to let the computer do it and then display the results in some manner. Dynamicness optimizes the feedback loop for greater incrementalism: the program runs until it hits any one point where an irreconcilable error is encountered, and then multiple options are available to fix the error and even let the program continue. Staticness optimizes the feedback loop for "batch" error-checking: the programmer writes a full body of code she thinks is correct, with no run/test cycle to speak of, and then gets all the errors at once. When the program compiles, it works. Since we can't implement either ideology perfectly, it's probably best to have some of _both_.