4 ms·

Could you enumerate the lies for us? Your comment is arresting but not enlightening without more information.

kazinator 12y ago
I'm an Lisp programmer, so I can. The language ANSI Common Lisp certainly has its fair share of "syntactic cruft". For instance numerous "macro dispatch characters" like #'func #:sym #c(2.0 4.1) #(vec tor). None of the syntactic cruft requires a LR(1) algorithm to work out; most of it is based on recognizing a character or two of prefix material and dispatching a read function. When the dispatch involves two characters, the first one is almost always # (though for programming your own nonstandard read syntax, that is not a fixed rule.) Read syntax is not even considered "real" syntax by Lisp programmers; "real" syntax is the structure of macros. But since macro forms are unambiguously written as nested lists, they already express the phrase structure almost directly; there is no phrase structure that needs to be applied to get a syntax tree. There isn't any syntactic cruft in Lisp that will have you scratching your head as to what goes with what. There are semantic head-scratchers related to syntax, like working out the implied actions of complicated, nested backquotes. There is never a question of syntax, though: nested backquotes are not ambiguous syntactically: they are just nested lists, with some sprinkling of a simple prefix-based notation throughout (splices and unquotes).
mkautzm 12y ago
Lisp is the hardly the simplest language. It has way less 'stuff' to learn, but that 'stuff' in imperative languages is generally useful abstractions that you don't to learn, but instead simply know of. By that measurement, x86 Assembly is really the simplest language of them all, but I don't think I need to explain why that's equally absurd. Lisp is a difficult language due to it's density and unreadability. Useful stuff hasn't been built in functional languages until very recently, exception being some AI. Haskell and friends are making functional languages cool and useful (and that's great!) but if you want to build something useful as soon as possible, learn .NET, Java, Python or Ruby.
- noblethrasher 12y ago
  What you mean to say is that Lisp is simple but not easy, but that's true of a lot of things. You might enjoy this: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy
Tloewald 12y ago
I wouldn't say "lies" so much as overly optimistic opinions. The idea that you can write a useful program in Lisp faster than in other languages is pretty unsupportable. For most users, the time and effort spent getting Lisp up-and-running on their machine of choice will already have lost. Incidentally, I played with the interactive REPL and it wouldn't advance beyond the second page. And, if you do write a useful program in Lisp, you run into the deployment problem. The deployment problem is pretty bad. Apple's Advanced Technology Group at one point had one of the highest concentrations of Lisp-heads in the world and produced a bunch of stuff like Dylan, Sk8, etc. that was intimately tied to their Lisp implementation. Not only was this not cross-platform, and pretty hard to distribute and deploy even on the platform it was created for (680x0 Macs) it was killed by the transition to PowerPC. This isn't as big a problem if you're writing server software, but it's absolutely disastrous if you're writing desktop or mobile software. One could show someone how to do something useful and deployable in Python, PHP, Perl, Javascript, or whatever in a few minutes and chances are they could have a usable dev environment set up in a few minutes.
- ScottBurson 12y ago
  The only thing that makes programs easy to deploy is the popularity of the language/environment they're written for. If the language you're using is popular enough that you can download the implementation using your system's package manager, deployment is easy. If not, it's harder. And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain. So I think you have it backwards: Lisp is not unpopular because it's hard to deploy; it's hard to deploy because it's never cracked the popularity threshold.
  - Blackthorn 12y ago
    This is only telling half the story. It is perfectly true for, say, Python (still a pain to deploy on Windows, or at least it was the last time I tried), but newer languages that are less popular like Go do not have this problem. Even Rust, a language that is only in alpha, does not have this problem! Why is this? It's because they can live in, and interact with, the common linking and loading ecosystem that the rest of the world lives in: the C ABI. If you can link your output into something that respects the C ABI, you can deploy it[1]. Common Lisp implementations could immediately solve their deployment problem by living in this ABI. So far, the only one that has done so is ECL (which is an excellent project). [1] A few alternatives exist. The Java and .NET ecosystems are also viable link targets (as I think Clojure has proved).

I'm an Lisp programmer, so I can. The language ANSI Common Lisp certainly has its fair share of "syntactic cruft". For instance numerous "macro dispatch characters" like #'func #:sym #c(2.0 4.1) #(vec tor). None of the syntactic cruft requires a LR(1) algorithm to work out; most of it is based on recognizing a character or two of prefix material and dispatching a read function. When the dispatch involves two characters, the first one is almost always # (though for programming your own nonstandard read syntax, that is not a fixed rule.) Read syntax is not even considered "real" syntax by Lisp programmers; "real" syntax is the structure of macros. But since macro forms are unambiguously written as nested lists, they already express the phrase structure almost directly; there is no phrase structure that needs to be applied to get a syntax tree. There isn't any syntactic cruft in Lisp that will have you scratching your head as to what goes with what. There are semantic head-scratchers related to syntax, like working out the implied actions of complicated, nested backquotes. There is never a question of syntax, though: nested backquotes are not ambiguous syntactically: they are just nested lists, with some sprinkling of a simple prefix-based notation throughout (splices and unquotes).

mkautzm 12y ago

Lisp is the hardly the simplest language. It has way less 'stuff' to learn, but that 'stuff' in imperative languages is generally useful abstractions that you don't to learn, but instead simply know of. By that measurement, x86 Assembly is really the simplest language of them all, but I don't think I need to explain why that's equally absurd. Lisp is a difficult language due to it's density and unreadability. Useful stuff hasn't been built in functional languages until very recently, exception being some AI. Haskell and friends are making functional languages cool and useful (and that's great!) but if you want to build something useful as soon as possible, learn .NET, Java, Python or Ruby.

noblethrasher 12y ago
What you mean to say is that Lisp is simple but not easy, but that's true of a lot of things. You might enjoy this: http://www.infoq.com/presentations/Simple-Made-Easy http://www.infoq.com/presentations/Simple-Made-Easy

Tloewald 12y ago

I wouldn't say "lies" so much as overly optimistic opinions. The idea that you can write a useful program in Lisp faster than in other languages is pretty unsupportable. For most users, the time and effort spent getting Lisp up-and-running on their machine of choice will already have lost. Incidentally, I played with the interactive REPL and it wouldn't advance beyond the second page. And, if you do write a useful program in Lisp, you run into the deployment problem. The deployment problem is pretty bad. Apple's Advanced Technology Group at one point had one of the highest concentrations of Lisp-heads in the world and produced a bunch of stuff like Dylan, Sk8, etc. that was intimately tied to their Lisp implementation. Not only was this not cross-platform, and pretty hard to distribute and deploy even on the platform it was created for (680x0 Macs) it was killed by the transition to PowerPC. This isn't as big a problem if you're writing server software, but it's absolutely disastrous if you're writing desktop or mobile software. One could show someone how to do something useful and deployable in Python, PHP, Perl, Javascript, or whatever in a few minutes and chances are they could have a usable dev environment set up in a few minutes.

ScottBurson 12y ago
The only thing that makes programs easy to deploy is the popularity of the language/environment they're written for. If the language you're using is popular enough that you can download the implementation using your system's package manager, deployment is easy. If not, it's harder. And for any language that's popular now, there was a time that it wasn't yet popular, and deployment was a pain. So I think you have it backwards: Lisp is not unpopular because it's hard to deploy; it's hard to deploy because it's never cracked the popularity threshold.
- Blackthorn 12y ago
  This is only telling half the story. It is perfectly true for, say, Python (still a pain to deploy on Windows, or at least it was the last time I tried), but newer languages that are less popular like Go do not have this problem. Even Rust, a language that is only in alpha, does not have this problem! Why is this? It's because they can live in, and interact with, the common linking and loading ecosystem that the rest of the world lives in: the C ABI. If you can link your output into something that respects the C ABI, you can deploy it[1]. Common Lisp implementations could immediately solve their deployment problem by living in this ABI. So far, the only one that has done so is ECL (which is an excellent project). [1] A few alternatives exist. The Java and .NET ecosystems are also viable link targets (as I think Clojure has proved).