8 ms·

Why Lisp Did Not and Never Will Gain Enough Traction

49 points by drmrkela 14y ago

mbleigh 14y ago
Parentheses.
- Kilimanjaro 14y ago
  Readability
  - dsrguru 14y ago
    Do you mean because the syntax isn't sugary or because Lisp lends itself to a DSL-driven style of development where user-defined constructs are used more extensively than in any other language family? If the former, I'd argue that's just because you're not used to looking at Lisp code. If anything, its extreme concision should make visually parsing code faster than parsing equivalent code in other languages. If the latter, pg makes a good argument in section 4.8 of On Lisp: "So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them. If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."
    - voyou 14y ago
      "Its extreme concision should make visually parsing code faster than parsing equivalent code in other languages." You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
      - wonderzombie 14y ago
        I'm not quite sure I understand your point, but you're disagreeing with the above quote whereas I agree wholeheartedly with the quote. Compare a language which forces you to write this ll = [] for x in xx: if bar(x): ll.append(x) This is Python, but imagine you're doing this in Java or C++ instead. Every time you read a for loop, you have to re-derive what the author intended. Are they just iterating? Are they composing a new list? Remember, these loops are often more than just two lines and they are common. Contrast the above with ll = [x for x in xx if bar(x)] Or even (in Haskell) filter bar xx When your language gives you primitives to talk at a higher level, you can write more crisply and concisely. The simple, trivial code you've written 1e9 times is replaced by a very clear, simple definition of what you're doing. The important code, the interesting code may now speak for itself.
        drmrkela 14y ago
        To be honest that Python list comprehension is really hard for me to internalize. I find Ruby way much more natural. xx.select { |x| bar(x) } Even Clojure is better (filter (fn[x](bar x)) xx) or (filter #(bar %) xx)
        osener 14y ago
        You don't need that anonymous function in Clojure, (filter bar xx) is enough just like Haskell.
        deleted 14y ago
        [deleted]
        drmrkela 14y ago
        You are right. Thanks.
        wonderzombie 14y ago
        Sure, I do, too. Ruby is one of the languages that made me experience how expressive the higher-order function pattern really is. That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
    - Kilimanjaro 14y ago
      http://news.ycombinator.com/item?id=1803815 http://news.ycombinator.com/item?id=1803815 Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world. My point stands: READABILITY.
- KirinDave 14y ago
  If this really is what turns you off to Lisps, then probably programming is only going to get harder and harder for you. Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.
  - e40 14y ago
    In fact, the syntax of s-expressions is the key to Lisp's power. The form of program and data are the same, which allows the powerful macro facility and the functions read and eval. I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.
    - colomon 14y ago
      When people say they hate "parentheses" in Lisp, I'm pretty sure what they really mean is "I hate s-expressions." You may find them natural to work with, but it's pretty clear most programmers do not. Witness the crazy amount of work compiler writers put into writing parsers that could be trivially done away with if they just switched to using s-expressions. Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.
      - KirinDave 14y ago
        S-expressions are neither wonderful nor terrible. They are just A Decision. Certainly you can have bad syntaxes and good syntaxes, as well.
    - derekp 14y ago
      From my perspective, it comes from being used to parentheses in English. Specifically, you have a man thought, then you have some other modifiers that may expand on that concept which you enclose in parentheses. This fits well with C style functions, for example. But with Lisp, the main thought (the function name) is also enclosed in parentheses along with all its modifiers, which makes it a bit harder to follow the code. However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).
- dhkl 14y ago
  The parentheses may seem like a disaster at first, but one can quickly learn to use and abuse them. Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit http://emacswiki.org/emacs/ParEdit).
  - osener 14y ago
    I've been seriously spoiled by paredit. It is a brilliant, absolutely brilliant way to edit code. Editing code written in those so called free form readable languages is absolute pain compared to structured editing in paredit. It is a reason to program in Lisps by itself. You don't need that filter on your data? Easy, you just need one keystroke (M-r) to raise the inner expression. Everyone should experience it, it certainly makes me want to write more and more code in Clojure.
jonathanyc 14y ago
I think that this article was posted a while back. I agree with most points, except for the one about lack of "pre choice" - I've been playing around with Racket (formerly PLT Scheme) for a while, and the one thing I've been amazed at is the amount of choice. There are a ridiculous number of built-ins. I think that the failure of Lisp to gain traction is probably better attributed to the other point about too much minimalism being madness. Some of the forms in Racket are pretty crazy.
- dsrguru 14y ago
  The failure of Lisp to gain traction historically might also be a result of marketing. Now that people are associating Clojure with things like startups, Heroku, concurrency, and the JVM, it seems to be catching on outside of the Lisp community.
  - dsrguru 14y ago
    I just found this chart (http://tinyurl.com/9f7pxnq http://tinyurl.com/9f7pxnq) of languages Clojure users came from [or are still using] from cemerick's 2012 State of Clojure survey, which suggests that Clojure is not only catching on outside of the LISP community, but almost exclusively so.
outworlder 14y ago
The 'ball of mud' analogy is spot-on. An artist can create wonderful sculptures with it, but a beginner won't be able to do much, besides flinging it around and making a mess. And that is not a bad thing. But really, how many Picassos and Da Vincis and Michelangelos have we produced so far? That's not something you could ever call "mainstream"...
KirinDave 14y ago
None of these applies to Clojure, and by and large Clojure basically obsoletes Ruby and Python unless you have concerns about the jvm startup time (which you can work around with Nailgun, but many people don't). No, seriously, Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world, only with fantastic performance and more flexible syntax. Indeed, criticizing "lisp" is difficult because it isn't really clear what you mean. Common Lisp? Well that has a lot of work done for you. Scheme? That's deliberately minimalist because it's not meant for everyday work until you go outside the core spec (e.g., PLT Scheme's libraries). Clisp? MacLisp? What? Lisp didn't take off because it didn't take off. There isn't some deep unconscious wisdom being tapped by the masses that we can read with tea leaves and subtlety. These things are random. There is a parallel universe not far from this one where Anic is a big deal and Pike took off in place of Python. Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion. All you and I can do in our quest to be great software engineers is try and choose tools that split the difference between The Best For the Job and the Best We Can Manage.
- drmrkela 14y ago
  Why do you think it obsoletes Ruby&Python? It does target Ruby developer with borrowing some syntax, but the paradigm shift needed to jump on the "functional" train is quite big. It is nice language but it solves the problem that I don't have (performance&concurrency) so I am not all that eager to make a switch.
  - KirinDave 14y ago
    Everyone has performance and concurrency problems, eventually. What's great about Clojure is it gives you a path to ease into them. Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?
rbanffy 14y ago
How much is "enough"?
- drmrkela 14y ago
  I don't know. Maybe to be in the top 10 on TIOBE index? It's paradoxal that you have this superior paradigm that not only is not dominating but it's not even in top 5 languages that are used. (Not to mention that all dialects account for that 13-th place, so if you disperse percentage on all of them - they are of the chart)
donall 14y ago
I don't mean to nit-pick, but although I found the content to be very interesting, I also found it difficult to follow because it feels like the author's grasp of English isn't quite where it needs to be (although it's very close). In particular, the phrase "back in a day" is used twice and I'm still not 100% certain whether it means that the actions were performed in a single day (which would be odd phrasing) or, more likely, if it's meant to be "back in the day", in the sense of "at an unspecified point in the past". That said, I don't wish to put people off from blogging in English, especially considering it was an interesting article that I would not have been able to enjoy if it was written in Croatian. My (intended to be friendly) advice is to recruit native-English proof-readers. I think you won't need them for long.
- drmrkela 14y ago
  Hey, thanks for the feedback. I was supposed to be "back in the day". But I feel it is best to just throw it out since it sounds kind of fake.
rbanffy 14y ago
One other thing to consider is when it's so easy to roll out your own [server|language|framework] no single implementation gains critical mass and fragmentation prevents newcomers from joining in.
scoith 14y ago
Tbe reason that functional programming languages, including LISP, will never dominate the world is because most people are doing engineering, not maths or getting out CS papers. CS people like to abstract away the computation from physical hardware, but the apparent fact is computation _is_ physical, and it's limits lie in physics and not in mathematics or philosophy (see Shor's algorithm for instance). It's only natural to write programs in a language that follows the same flow as the underlying physical computer. A classical computer is represented by it's assembly language, thus it makes sense to have languages like C. Concepts like "stateless programs" don't even exists in a classical computer. It's as crazy as trying to build a quantum algorithm that does away with measurements! In addition the physical world does not work anything like a stateless machine. As most useful programs imitate a physical process rather than a pure mathematical object, the notion of writing programs in such languages is not-intuitive and requires transformation of the actual problem at a both low (hardware) and high (software output) level. Finally I would like to speculate that the whole concept will never be intuitive in the future (post-quantum computer era). In the era of quantum computers, because they will always be physical objects with a particular state, and it's this very fact that they have a well-defined state allows us to perform a computation.
- dbecker 14y ago
  I don't think the relationship between a language's model of computation and the physical computing mechanism is particularly important. It's more important for a language to follow our MENTAL model of computing. Fortunately, the mental model of computing can change over time as you become familiar with new paradigms. The same thing can be said about "which model of computation resemble physical reality." Each of us can have different mental models of physical systems. Personally, the functional paradigm is closer to my mental model than declarative, but imperative still feels the most natural. This isn't a statement about reality, but rather about how you think about it.
  - scoith 14y ago
    I think there is a confusion here: our "mental" grasp of a physical process and intuition is tightly related to how the world works. We develop our intuition from real-world experience. They're not two separate things. This's also why quantum physics is so non-intuitive for us, and why we struggle dealing with it (counter-intuitive it is, we do it anyways, because that's just the way the Nature works --it's not something man-made like Lisp). That being said, the physical processes don't depend on people's understanding. Physics doesn't depend on how you think about the world. The quantum state (or a classical state) is there, and it won't go away just because you want mathematical elegance or try to see things in a different way in your inner world as hard as you can. That being said, of course it matters the way you write your software. There is a huge gap between actual CPU instructions and Lisp. Between Lisp and the machine is an automated, soft layer of emulation, which may or may not be optimal and is extra work anyway.
pnathan 14y ago
Lisp being too minimalistic or offering too many choices is an interesting argument. It's not wholly untrue. Lisps culturally offer power and flexibility. Many- most perhaps - developers don't want that. They want a golden road to deployment, a KISS mechanism to write basic code to do basic things and keep doing them. Flexibility and power expand the solution space too much for their taste. Well, that's OK for them. I'll just be doing my Lisp as much as I can.
- bokchoi 14y ago
  It's not that developers don't want flexibility or power. It's that it comes at a cost of collaboration with other developers and tools.
agumonkey 14y ago
Dick Gabriel, IIRC, mentioned that many PL research was done in lisp, but your PhD would look dull if it was just a set of lisp macros, so students devised a concrete syntax and built a separate native compiler. I believe lisp as an atom will never be more popular than in the Symbolics era (lisp from top to metal, hard to beat), lisp genes,though, are all over the place recently.
MaysonL 14y ago
And Beethoven will never beat out the Beatles. It's a pop culture, baby! Live with it.

49 points by drmrkela 14y ago

mbleigh 14y ago

Parentheses.

Kilimanjaro 14y ago
Readability
- dsrguru 14y ago
  Do you mean because the syntax isn't sugary or because Lisp lends itself to a DSL-driven style of development where user-defined constructs are used more extensively than in any other language family? If the former, I'd argue that's just because you're not used to looking at Lisp code. If anything, its extreme concision should make visually parsing code faster than parsing equivalent code in other languages. If the latter, pg makes a good argument in section 4.8 of On Lisp: "So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them. If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."
  - voyou 14y ago
    "Its extreme concision should make visually parsing code faster than parsing equivalent code in other languages." You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.
    - wonderzombie 14y ago
      I'm not quite sure I understand your point, but you're disagreeing with the above quote whereas I agree wholeheartedly with the quote. Compare a language which forces you to write this ll = [] for x in xx: if bar(x): ll.append(x) This is Python, but imagine you're doing this in Java or C++ instead. Every time you read a for loop, you have to re-derive what the author intended. Are they just iterating? Are they composing a new list? Remember, these loops are often more than just two lines and they are common. Contrast the above with ll = [x for x in xx if bar(x)] Or even (in Haskell) filter bar xx When your language gives you primitives to talk at a higher level, you can write more crisply and concisely. The simple, trivial code you've written 1e9 times is replaced by a very clear, simple definition of what you're doing. The important code, the interesting code may now speak for itself.
      - drmrkela 14y ago
        To be honest that Python list comprehension is really hard for me to internalize. I find Ruby way much more natural. xx.select { |x| bar(x) } Even Clojure is better (filter (fn[x](bar x)) xx) or (filter #(bar %) xx)
        osener 14y ago
        You don't need that anonymous function in Clojure, (filter bar xx) is enough just like Haskell.
        deleted 14y ago
        [deleted]
        drmrkela 14y ago
        You are right. Thanks.
        wonderzombie 14y ago
        Sure, I do, too. Ruby is one of the languages that made me experience how expressive the higher-order function pattern really is. That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.
  - Kilimanjaro 14y ago
    http://news.ycombinator.com/item?id=1803815 http://news.ycombinator.com/item?id=1803815 Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world. My point stands: READABILITY.
KirinDave 14y ago
If this really is what turns you off to Lisps, then probably programming is only going to get harder and harder for you. Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.
- e40 14y ago
  In fact, the syntax of s-expressions is the key to Lisp's power. The form of program and data are the same, which allows the powerful macro facility and the functions read and eval. I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.
  - colomon 14y ago
    When people say they hate "parentheses" in Lisp, I'm pretty sure what they really mean is "I hate s-expressions." You may find them natural to work with, but it's pretty clear most programmers do not. Witness the crazy amount of work compiler writers put into writing parsers that could be trivially done away with if they just switched to using s-expressions. Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.
    - KirinDave 14y ago
      S-expressions are neither wonderful nor terrible. They are just A Decision. Certainly you can have bad syntaxes and good syntaxes, as well.
  - derekp 14y ago
    From my perspective, it comes from being used to parentheses in English. Specifically, you have a man thought, then you have some other modifiers that may expand on that concept which you enclose in parentheses. This fits well with C style functions, for example. But with Lisp, the main thought (the function name) is also enclosed in parentheses along with all its modifiers, which makes it a bit harder to follow the code. However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).
dhkl 14y ago
The parentheses may seem like a disaster at first, but one can quickly learn to use and abuse them. Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit http://emacswiki.org/emacs/ParEdit).
- osener 14y ago
  I've been seriously spoiled by paredit. It is a brilliant, absolutely brilliant way to edit code. Editing code written in those so called free form readable languages is absolute pain compared to structured editing in paredit. It is a reason to program in Lisps by itself. You don't need that filter on your data? Easy, you just need one keystroke (M-r) to raise the inner expression. Everyone should experience it, it certainly makes me want to write more and more code in Clojure.

jonathanyc 14y ago

I think that this article was posted a while back. I agree with most points, except for the one about lack of "pre choice" - I've been playing around with Racket (formerly PLT Scheme) for a while, and the one thing I've been amazed at is the amount of choice. There are a ridiculous number of built-ins. I think that the failure of Lisp to gain traction is probably better attributed to the other point about too much minimalism being madness. Some of the forms in Racket are pretty crazy.

dsrguru 14y ago
The failure of Lisp to gain traction historically might also be a result of marketing. Now that people are associating Clojure with things like startups, Heroku, concurrency, and the JVM, it seems to be catching on outside of the Lisp community.
- dsrguru 14y ago
  I just found this chart (http://tinyurl.com/9f7pxnq http://tinyurl.com/9f7pxnq) of languages Clojure users came from [or are still using] from cemerick's 2012 State of Clojure survey, which suggests that Clojure is not only catching on outside of the LISP community, but almost exclusively so.

outworlder 14y ago

The 'ball of mud' analogy is spot-on. An artist can create wonderful sculptures with it, but a beginner won't be able to do much, besides flinging it around and making a mess. And that is not a bad thing. But really, how many Picassos and Da Vincis and Michelangelos have we produced so far? That's not something you could ever call "mainstream"...

KirinDave 14y ago

None of these applies to Clojure, and by and large Clojure basically obsoletes Ruby and Python unless you have concerns about the jvm startup time (which you can work around with Nailgun, but many people don't). No, seriously, Clojure is a uniform attack on everything of value in the Ruby, Python and Node.js world, only with fantastic performance and more flexible syntax. Indeed, criticizing "lisp" is difficult because it isn't really clear what you mean. Common Lisp? Well that has a lot of work done for you. Scheme? That's deliberately minimalist because it's not meant for everyday work until you go outside the core spec (e.g., PLT Scheme's libraries). Clisp? MacLisp? What? Lisp didn't take off because it didn't take off. There isn't some deep unconscious wisdom being tapped by the masses that we can read with tea leaves and subtlety. These things are random. There is a parallel universe not far from this one where Anic is a big deal and Pike took off in place of Python. Because to assume otherwise that would imply that everyone knows every language and some are uniform winners over others. Do you know every language you have rejected? Heck, do you even know the general characteristics of Lisp, or Haskell, or ML, or Anic, or Pike, or APL? No, and to really try and learn all of them would take a lot of time unless you're quite gifted. So the premiere and popular programming languages are as unpredictable as fashion. All you and I can do in our quest to be great software engineers is try and choose tools that split the difference between The Best For the Job and the Best We Can Manage.

drmrkela 14y ago
Why do you think it obsoletes Ruby&Python? It does target Ruby developer with borrowing some syntax, but the paradigm shift needed to jump on the "functional" train is quite big. It is nice language but it solves the problem that I don't have (performance&concurrency) so I am not all that eager to make a switch.
- KirinDave 14y ago
  Everyone has performance and concurrency problems, eventually. What's great about Clojure is it gives you a path to ease into them. Compare a Noir or even bare Compojure web service vs. a Sinatra web service. Is there really a big winner on brevity?

rbanffy 14y ago

How much is "enough"?

drmrkela 14y ago
I don't know. Maybe to be in the top 10 on TIOBE index? It's paradoxal that you have this superior paradigm that not only is not dominating but it's not even in top 5 languages that are used. (Not to mention that all dialects account for that 13-th place, so if you disperse percentage on all of them - they are of the chart)

donall 14y ago

I don't mean to nit-pick, but although I found the content to be very interesting, I also found it difficult to follow because it feels like the author's grasp of English isn't quite where it needs to be (although it's very close). In particular, the phrase "back in a day" is used twice and I'm still not 100% certain whether it means that the actions were performed in a single day (which would be odd phrasing) or, more likely, if it's meant to be "back in the day", in the sense of "at an unspecified point in the past". That said, I don't wish to put people off from blogging in English, especially considering it was an interesting article that I would not have been able to enjoy if it was written in Croatian. My (intended to be friendly) advice is to recruit native-English proof-readers. I think you won't need them for long.

drmrkela 14y ago
Hey, thanks for the feedback. I was supposed to be "back in the day". But I feel it is best to just throw it out since it sounds kind of fake.

rbanffy 14y ago

One other thing to consider is when it's so easy to roll out your own [server|language|framework] no single implementation gains critical mass and fragmentation prevents newcomers from joining in.

scoith 14y ago

Tbe reason that functional programming languages, including LISP, will never dominate the world is because most people are doing engineering, not maths or getting out CS papers. CS people like to abstract away the computation from physical hardware, but the apparent fact is computation _is_ physical, and it's limits lie in physics and not in mathematics or philosophy (see Shor's algorithm for instance). It's only natural to write programs in a language that follows the same flow as the underlying physical computer. A classical computer is represented by it's assembly language, thus it makes sense to have languages like C. Concepts like "stateless programs" don't even exists in a classical computer. It's as crazy as trying to build a quantum algorithm that does away with measurements! In addition the physical world does not work anything like a stateless machine. As most useful programs imitate a physical process rather than a pure mathematical object, the notion of writing programs in such languages is not-intuitive and requires transformation of the actual problem at a both low (hardware) and high (software output) level. Finally I would like to speculate that the whole concept will never be intuitive in the future (post-quantum computer era). In the era of quantum computers, because they will always be physical objects with a particular state, and it's this very fact that they have a well-defined state allows us to perform a computation.

dbecker 14y ago
I don't think the relationship between a language's model of computation and the physical computing mechanism is particularly important. It's more important for a language to follow our MENTAL model of computing. Fortunately, the mental model of computing can change over time as you become familiar with new paradigms. The same thing can be said about "which model of computation resemble physical reality." Each of us can have different mental models of physical systems. Personally, the functional paradigm is closer to my mental model than declarative, but imperative still feels the most natural. This isn't a statement about reality, but rather about how you think about it.
- scoith 14y ago
  I think there is a confusion here: our "mental" grasp of a physical process and intuition is tightly related to how the world works. We develop our intuition from real-world experience. They're not two separate things. This's also why quantum physics is so non-intuitive for us, and why we struggle dealing with it (counter-intuitive it is, we do it anyways, because that's just the way the Nature works --it's not something man-made like Lisp). That being said, the physical processes don't depend on people's understanding. Physics doesn't depend on how you think about the world. The quantum state (or a classical state) is there, and it won't go away just because you want mathematical elegance or try to see things in a different way in your inner world as hard as you can. That being said, of course it matters the way you write your software. There is a huge gap between actual CPU instructions and Lisp. Between Lisp and the machine is an automated, soft layer of emulation, which may or may not be optimal and is extra work anyway.

pnathan 14y ago

Lisp being too minimalistic or offering too many choices is an interesting argument. It's not wholly untrue. Lisps culturally offer power and flexibility. Many- most perhaps - developers don't want that. They want a golden road to deployment, a KISS mechanism to write basic code to do basic things and keep doing them. Flexibility and power expand the solution space too much for their taste. Well, that's OK for them. I'll just be doing my Lisp as much as I can.

bokchoi 14y ago
It's not that developers don't want flexibility or power. It's that it comes at a cost of collaboration with other developers and tools.

agumonkey 14y ago

Dick Gabriel, IIRC, mentioned that many PL research was done in lisp, but your PhD would look dull if it was just a set of lisp macros, so students devised a concrete syntax and built a separate native compiler. I believe lisp as an atom will never be more popular than in the Symbolics era (lisp from top to metal, hard to beat), lisp genes,though, are all over the place recently.

MaysonL 14y ago

And Beethoven will never beat out the Beatles. It's a pop culture, baby! Live with it.