5 ms·

Most of the essay can summarized by this quote from it: Lisp is so powerful that problems which are technical issues in other programming languages are

by TY 15y ago

Most of the essay can summarized by this quote from it: Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. While this is not a bad essay I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today. Instead, I'd love to see that mental energy spent on advocacy/defence/adulation/hatred of various Lisp dialects on actually writing great software. Let's stop looking at Lisp as a religion and instead use it as a great tool to create beautiful things. Disclaimer: I've used CL, Scheme and Clojure on my various (mostly personal) projects. For the current one, I use Python as it fits better for what I'm doing today. My next project will use whatever it needs to work.

winestock 15y ago
"I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today." So am I. I wrote the essay because this idea has been banging in my head for some time and I had to let it out. The urgency shows in places. Elsewhere in this thread, others are pointing out that I don't know that much C. Guilty. Another commenter's suspicion about the "we lost because we're so awesome" theme also has merit. I suppose that Lisp must have some intrinsic problems, but reading about the Lisp Machine period makes the language so enchanting.
- lkesteloot 15y ago
  I've always suspected that Lisp is write-only. For example, it fails the squint test, which I wrote about here: http://www.teamten.com/lawrence/writings/the_language_squint_test.html http://www.teamten.com/lawrence/writings/the_language_squint... Being write-only would explain why there are so few collaborative Lisp projects. And I don't particularly buy the thesis of this essay that there are few collaborative Lisp projects because it's possible to do anything with a single person. You can always find sufficiently difficult problems that would require a team. Projects in Lisp should be putting projects in other languages to shame. I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself.
  - winestock 15y ago
    "I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself." That goes back to the point of the essay. The expressiveness of Lisp encourages, among other things, the creation of a "little language" for each project. This makes collaboration more difficult. Ergo, it's a social issue rather than a technical issue.
    - lkesteloot 15y ago
      Okay, I see what you mean by that now. I might still quibble that calling it a "social issue" (as opposed to technical) makes it sound like it's not Lisp's fault. A good feature that leads to a bad situation is a bad feature. I want to call out macros for what they are: a feature that contributes to Lisp not being used. Thinking about it more, I might describe macros as "anti-social" in that they help the programmer but hurt the team. This might be what you meant. Note that I'm not saying that the idea of macros is bad; only that Lisp's decision to make them look like function calls is bad. I once saw a macro system for Lua that made their invocation look clearly different than normal language.
      - waterhouse 15y ago
        > A good feature that leads to a bad situation is a bad feature. Pretty much every technological advancement ever has made it easier for people to get themselves into bad situations (and some people have indeed gotten themselves into bad situations). Cars enable you to move very fast, which enables you to crash and die, and many people have done just that. Clearly, cars have "led" to car accidents, which are surely "bad situations". But would you recommend eliminating or crippling cars for this reason? I don't think so. The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools. ... Perhaps you could find some way to make the tools safer without crippling them, and, sure, that would be nice. But what you said was that it was a "bad feature", implying that in the absence of any creative alternative ideas (to remake the feature so that the risks are mitigated while the functionality is retained), it should be thrown out. And in that case, my rebuttal stands.
pnathan 15y ago
There's also the tendency among lispers to shoot for the right solution, instead of the working one. I've encountered that a few times in #lisp. When I write Lisp, I am trying to Get Stuff Done. The Right Way matters, but not until it matters (Everything is fast when n < 10). So I'd rather advocate by - in due time - rolling out working projects for people to use, pointing, and saying, "Look, this is useful software in Lisp". c.f., Worse is Better, Worse is Worse, and Worse is Still Better, by rpg.
- Xurinos 15y ago
  ...so long as we balance the long term cost in future maintenance/extension work against the short term gain.
  - anamax 15y ago
    > so long as we balance the long term cost in future maintenance/extension work against the short term gain. There is no "long term" unless the short term system survives. Anything that ships is better than the best thing that didn't ship.
    - Xurinos 15y ago
      > Anything that ships is better than the best thing that didn't ship. Minor strawman... I did not advocate waiting to ship the "best". Rarely are things that ship "short term" systems. Watch the balance. If you have to maintain/update it, you must be mindful of the costs.

by TY 15y ago

winestock 15y ago

"I'm experiencing a fatigue from reading articles/books/posts about great powers of Lisp and why Lisp is where it is today." So am I. I wrote the essay because this idea has been banging in my head for some time and I had to let it out. The urgency shows in places. Elsewhere in this thread, others are pointing out that I don't know that much C. Guilty. Another commenter's suspicion about the "we lost because we're so awesome" theme also has merit. I suppose that Lisp must have some intrinsic problems, but reading about the Lisp Machine period makes the language so enchanting.

lkesteloot 15y ago
I've always suspected that Lisp is write-only. For example, it fails the squint test, which I wrote about here: http://www.teamten.com/lawrence/writings/the_language_squint_test.html http://www.teamten.com/lawrence/writings/the_language_squint... Being write-only would explain why there are so few collaborative Lisp projects. And I don't particularly buy the thesis of this essay that there are few collaborative Lisp projects because it's possible to do anything with a single person. You can always find sufficiently difficult problems that would require a team. Projects in Lisp should be putting projects in other languages to shame. I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself.
- winestock 15y ago
  "I think there's something about Lisp that makes collaboration too difficult, and I suspect it's the expressiveness itself." That goes back to the point of the essay. The expressiveness of Lisp encourages, among other things, the creation of a "little language" for each project. This makes collaboration more difficult. Ergo, it's a social issue rather than a technical issue.
  - lkesteloot 15y ago
    Okay, I see what you mean by that now. I might still quibble that calling it a "social issue" (as opposed to technical) makes it sound like it's not Lisp's fault. A good feature that leads to a bad situation is a bad feature. I want to call out macros for what they are: a feature that contributes to Lisp not being used. Thinking about it more, I might describe macros as "anti-social" in that they help the programmer but hurt the team. This might be what you meant. Note that I'm not saying that the idea of macros is bad; only that Lisp's decision to make them look like function calls is bad. I once saw a macro system for Lua that made their invocation look clearly different than normal language.
    - waterhouse 15y ago
      > A good feature that leads to a bad situation is a bad feature. Pretty much every technological advancement ever has made it easier for people to get themselves into bad situations (and some people have indeed gotten themselves into bad situations). Cars enable you to move very fast, which enables you to crash and die, and many people have done just that. Clearly, cars have "led" to car accidents, which are surely "bad situations". But would you recommend eliminating or crippling cars for this reason? I don't think so. The solution is for the people who use these tools to become mindful of these dangers, not to get rid of the tools. ... Perhaps you could find some way to make the tools safer without crippling them, and, sure, that would be nice. But what you said was that it was a "bad feature", implying that in the absence of any creative alternative ideas (to remake the feature so that the risks are mitigated while the functionality is retained), it should be thrown out. And in that case, my rebuttal stands.

pnathan 15y ago

There's also the tendency among lispers to shoot for the right solution, instead of the working one. I've encountered that a few times in #lisp. When I write Lisp, I am trying to Get Stuff Done. The Right Way matters, but not until it matters (Everything is fast when n < 10). So I'd rather advocate by - in due time - rolling out working projects for people to use, pointing, and saying, "Look, this is useful software in Lisp". c.f., Worse is Better, Worse is Worse, and Worse is Still Better, by rpg.

Xurinos 15y ago
...so long as we balance the long term cost in future maintenance/extension work against the short term gain.
- anamax 15y ago
  > so long as we balance the long term cost in future maintenance/extension work against the short term gain. There is no "long term" unless the short term system survives. Anything that ships is better than the best thing that didn't ship.
  - Xurinos 15y ago
    > Anything that ships is better than the best thing that didn't ship. Minor strawman... I did not advocate waiting to ship the "best". Rarely are things that ship "short term" systems. Watch the balance. If you have to maintain/update it, you must be mindful of the costs.