4 ms·

The big question is whether in fifty years Lisp will still be a chameleon that lurks in the shadows, never quite getting out where the common people are. Like i

by mixmax 18y ago

The big question is whether in fifty years Lisp will still be a chameleon that lurks in the shadows, never quite getting out where the common people are. Like it has in the last fifty years. It's interesting to see that while Lisp is superior in many ways, it's never been widely adopted. Why is that? I'm pretty sure it's not only because of pointy haired bosses, after all they take their cues from the fancy trade rags that are written by people that would at least know about the existence of Lisp. PHP reached a wide audience without the backing of a large corporation, so that argument is probably stale. I can think of a couple of reasons: - It's different. The syntax of Lisp is unlike any other language, which might turn people off. - The Lisp community is not very beginner-friendly. Since we all start out as beginners, there will be no experts if there are no beginners. - It's fragmented. There has been a history of a number of different dialects that are almost but not quite compatible. This might be a turn-off for people actually wanting to use Lisp for production systems where stability and maintenance of the distro is paramount. - It's hard. "Lisp is the only language where you spend more time thinking than writing code" - I can't remember where the quote is from, but probably Stallmann, Raymond or PG. - There are few libraries. Even though it's the oldest language still in wide use there seems to be a lack of libraries. This is probably the main reason PHP became so popular, along with it's friendliness towards beginners. Unfortunately the (fragmented) Lisp community doesn't seem interested in addressing any of these problems, so my guess is that in fifty years Lisp will still be a minority language only used by a select few.

cperciva 18y ago
Lisp is the only language where you spend more time thinking than writing code That may be true for some people, but it's definitely not true for me. I'd say I spend on average 10 hours thinking for every 1 hour I spend writing code -- and I write in C.
- wheels 18y ago
  I think the commenter meant something different from the original author. I think they meant that you spend more time thinking about how to write it in Lisp. I'd contest both points, really. First, I think if you're sufficiently comfortable in almost any language, you can translate pretty fluidly from idea to implementation. There are real differences, but they're overstated. In that respect, Lisp's "hardness" is really not being deep into the language and natively breaking problems down in a way that maps to functional languages. Second, and I think your point, is that getting to that point where you've got the problem broken down into its components is the hard part. I think there are tasks where that's true and ones where it's not, and again, that's largely language independent, though the amount of time needed for the more menial aspects does vary.
  - Zak 18y ago
    Lisp's "hardness" is really not being deep into the language and natively breaking problems down in a way that maps to functional languages. I think that may be a valid argument if you're talking about a mostly-functional dialect of Lisp like Clojure. Common Lisp and Scheme don't really offer any resistance to writing in an imperative style
- parenthesis 18y ago
  I was going to say: but a project like tarsnap, by its nature, is going to have a particularly high ratio of ideas to loc. However, even in a language like C, whose basic building blocks are much simpler than those available in a Lisp, and even when writing a routine program with no fancy math or theory behind it — if one finds oneself having to write lots of loc per thought, then one is doing it wrong: and one stops and thinks, and works out a way to abstract out the drudgery with more sophisticated data structures and preprocessor macros, or whatever.
- jacquesm 18y ago
  That is the way it should be, not the other way around. Solving problems is hard, solving them in the 'right' way is even harder. For every hour that you spend thinking about your code you are probably saving 10 hours on code that you'll end up tossing anyway or that will perform horribly and will need extensive rewriting or optimization. If there is one common mistake I am guilty of then it is to sit down and start coding too soon.
gaius 18y ago
Philip Greenspun - he also mentioned SQL and I think ML. The current generation of Lisp users is the last one. Python and Ruby have enough of Lisp's features that switching to a "real" Lisp offers rapidly diminishing returns. Haskell and F#/OCaml and Erlang are alive and well and gaining new users and taking things in a different direction. The argument "but it's too difficult for commercial programmers" makes Lispers feel good, but it simply isn't true. Commercial programmers once wrote vastly complex systems in assembly language. And anyone who can use C++ in anger is certainly smart enough to learn any language. If there's hope it lies in Clojure but again, it's not entirely clear that Clojure offers significant advantages to someone who is already getting stuff done in one of those others (and the average Java programmer doesn't understand why anyone would use anything other than Java).
- gibsonf1 18y ago
  "The current generation of Lisp users is the last one" Hmm, I guess time will tell on that. The future is much harder to predict than most people realize. I'm guessing, though, that more successful large Lisp projects will keep the language alive and cause the conversion of more programmers to lisp. Our little startup converted one Java programmer over, and I can only imagine the impact ITA is having with its Orbitz product. Also, the move to more "semantic" approaches may also spark more interest in Lisp. We'll see.
- Zak 18y ago
  Having recently made use of Clojure to make a simple, multithreaded image processing program[0], I can say the advantages over Python and Ruby are significant. Here's what I got, essentially free by using Clojure: Processing a directory full of flies using as many threads as there are cores. No UI-hanging due to long-running callbacks. Automatic queuing of actions started from the UI Fast, statically typed primitive operations, but only when I ask for them Friction-free access to Java's rather sizable collection of libraries I didn't write any macros, so all of this would have been possible in a language with Clojure's features and a non-Lisp syntax. That said, I have no doubt that if I write a longer program involving Swing, there will be macros involved, and they will save a significant amount of pain. [0] http://github.com/zakwilson/imagesieve/tree/master http://github.com/zakwilson/imagesieve/tree/master
brlewis 18y ago
PHP reached a wide audience by appealing to shared hosting providers, but that path to popularity is no longer available. To answer your reasons: - Yes, it's different. The Lisp community was interested enough in this problem to create Dylan, but that didn't work, and it wasn't really Lisp anymore. - Try finding something more beginner-friendly than DrScheme. Actually don't. You'll be wasting your time. - The Lisp community has always been interested in fighting fragmentation. SRFIs are being implemented in a wide range of Scheme implementations. I'm less familiar with the Common Lisp side, but I'm pretty sure a lot's been done there too. - I think by writing code. I wrote C for 12 years, and that code has more comments because I would first write what needed to be done as a series of comments, then fill in code under each comment. Lisp is actually a lot easier once you get used to it. - I use Kawa Scheme, which like Clojure and SISC runs on the JVM and has easy access to all Java libraries. But generally you choose a Lisp not to use libraries but to create a program that's in a class by itself.
- gruseom 18y ago
  But generally you choose a Lisp not to use libraries but to create a program that's in a class by itself. Boy, am I glad to see that somebody else figured this out. The lack of libraries which is the objection du jour against Lisp is actually connected to its strengths. First, there's less of a need for many libraries because it's so easy to write your own things. Second, Lisp's value goes up (and libraries' goes down) the more you get into problems that aren't well understood. But then a lot of problems get more open-ended, when you're working in a medium that encourages exploration.
  - jodrellblank 18y ago
    First, there's less of a need for many libraries because it's so easy to write your own things. If it's so easy, why aren't there good libraries for it? Nobody has done it because it's too easy? Eh? It's ridiculous and counter to the point of programming in general to suggest people ought to keep reinventing something because it's easy to do so. Even worse, if it is easy, then it's merely a distraction not a challenge - causing you to lose where you were in your program while you think about reinventing an easy wheel. Not that I believe it for a minute - implementing a good library to do something complex isn't easy - I just don't think "I want a script to process email, I could use Python and start with 'import email, pop' or I could go with Lisp and reimplement a POP client and an SMTP/MIME email parser it'll only take a minute".

by mixmax 18y ago

cperciva 18y ago

Lisp is the only language where you spend more time thinking than writing code That may be true for some people, but it's definitely not true for me. I'd say I spend on average 10 hours thinking for every 1 hour I spend writing code -- and I write in C.

wheels 18y ago
I think the commenter meant something different from the original author. I think they meant that you spend more time thinking about how to write it in Lisp. I'd contest both points, really. First, I think if you're sufficiently comfortable in almost any language, you can translate pretty fluidly from idea to implementation. There are real differences, but they're overstated. In that respect, Lisp's "hardness" is really not being deep into the language and natively breaking problems down in a way that maps to functional languages. Second, and I think your point, is that getting to that point where you've got the problem broken down into its components is the hard part. I think there are tasks where that's true and ones where it's not, and again, that's largely language independent, though the amount of time needed for the more menial aspects does vary.
- Zak 18y ago
  Lisp's "hardness" is really not being deep into the language and natively breaking problems down in a way that maps to functional languages. I think that may be a valid argument if you're talking about a mostly-functional dialect of Lisp like Clojure. Common Lisp and Scheme don't really offer any resistance to writing in an imperative style
parenthesis 18y ago
I was going to say: but a project like tarsnap, by its nature, is going to have a particularly high ratio of ideas to loc. However, even in a language like C, whose basic building blocks are much simpler than those available in a Lisp, and even when writing a routine program with no fancy math or theory behind it — if one finds oneself having to write lots of loc per thought, then one is doing it wrong: and one stops and thinks, and works out a way to abstract out the drudgery with more sophisticated data structures and preprocessor macros, or whatever.
jacquesm 18y ago
That is the way it should be, not the other way around. Solving problems is hard, solving them in the 'right' way is even harder. For every hour that you spend thinking about your code you are probably saving 10 hours on code that you'll end up tossing anyway or that will perform horribly and will need extensive rewriting or optimization. If there is one common mistake I am guilty of then it is to sit down and start coding too soon.

gaius 18y ago

Philip Greenspun - he also mentioned SQL and I think ML. The current generation of Lisp users is the last one. Python and Ruby have enough of Lisp's features that switching to a "real" Lisp offers rapidly diminishing returns. Haskell and F#/OCaml and Erlang are alive and well and gaining new users and taking things in a different direction. The argument "but it's too difficult for commercial programmers" makes Lispers feel good, but it simply isn't true. Commercial programmers once wrote vastly complex systems in assembly language. And anyone who can use C++ in anger is certainly smart enough to learn any language. If there's hope it lies in Clojure but again, it's not entirely clear that Clojure offers significant advantages to someone who is already getting stuff done in one of those others (and the average Java programmer doesn't understand why anyone would use anything other than Java).

gibsonf1 18y ago
"The current generation of Lisp users is the last one" Hmm, I guess time will tell on that. The future is much harder to predict than most people realize. I'm guessing, though, that more successful large Lisp projects will keep the language alive and cause the conversion of more programmers to lisp. Our little startup converted one Java programmer over, and I can only imagine the impact ITA is having with its Orbitz product. Also, the move to more "semantic" approaches may also spark more interest in Lisp. We'll see.
Zak 18y ago
Having recently made use of Clojure to make a simple, multithreaded image processing program[0], I can say the advantages over Python and Ruby are significant. Here's what I got, essentially free by using Clojure: Processing a directory full of flies using as many threads as there are cores. No UI-hanging due to long-running callbacks. Automatic queuing of actions started from the UI Fast, statically typed primitive operations, but only when I ask for them Friction-free access to Java's rather sizable collection of libraries I didn't write any macros, so all of this would have been possible in a language with Clojure's features and a non-Lisp syntax. That said, I have no doubt that if I write a longer program involving Swing, there will be macros involved, and they will save a significant amount of pain. [0] http://github.com/zakwilson/imagesieve/tree/master http://github.com/zakwilson/imagesieve/tree/master

brlewis 18y ago

PHP reached a wide audience by appealing to shared hosting providers, but that path to popularity is no longer available. To answer your reasons: - Yes, it's different. The Lisp community was interested enough in this problem to create Dylan, but that didn't work, and it wasn't really Lisp anymore. - Try finding something more beginner-friendly than DrScheme. Actually don't. You'll be wasting your time. - The Lisp community has always been interested in fighting fragmentation. SRFIs are being implemented in a wide range of Scheme implementations. I'm less familiar with the Common Lisp side, but I'm pretty sure a lot's been done there too. - I think by writing code. I wrote C for 12 years, and that code has more comments because I would first write what needed to be done as a series of comments, then fill in code under each comment. Lisp is actually a lot easier once you get used to it. - I use Kawa Scheme, which like Clojure and SISC runs on the JVM and has easy access to all Java libraries. But generally you choose a Lisp not to use libraries but to create a program that's in a class by itself.

gruseom 18y ago
But generally you choose a Lisp not to use libraries but to create a program that's in a class by itself. Boy, am I glad to see that somebody else figured this out. The lack of libraries which is the objection du jour against Lisp is actually connected to its strengths. First, there's less of a need for many libraries because it's so easy to write your own things. Second, Lisp's value goes up (and libraries' goes down) the more you get into problems that aren't well understood. But then a lot of problems get more open-ended, when you're working in a medium that encourages exploration.
- jodrellblank 18y ago
  First, there's less of a need for many libraries because it's so easy to write your own things. If it's so easy, why aren't there good libraries for it? Nobody has done it because it's too easy? Eh? It's ridiculous and counter to the point of programming in general to suggest people ought to keep reinventing something because it's easy to do so. Even worse, if it is easy, then it's merely a distraction not a challenge - causing you to lose where you were in your program while you think about reinventing an easy wheel. Not that I believe it for a minute - implementing a good library to do something complex isn't easy - I just don't think "I want a script to process email, I could use Python and start with 'import email, pop' or I could go with Lisp and reimplement a POP client and an SMTP/MIME email parser it'll only take a minute".