11 ms·

Why didn't Common Lisp fix the world?

83 points by weeber 10y ago

lispm 10y ago
For those who don't know Peter Norvig, let me mention that he wrote one of the best Lisp books: http://norvig.com/paip.html http://norvig.com/paip.html
- dragonquest 10y ago
  Not just one of the best Lisp books; but one of the best books on programming, period.
  - S4M 10y ago
    I think it's a programming book that happens to use Lisp as an example language to explain AI concepts and algorithms, rather than a Lisp book.
    - lispm 10y ago
      Actually not. The book is full of beautiful code, combined with deep Lisp lore how to write that code.
sklogic 10y ago
Norvig nailed it - instead of being sissy about macros altogether the mainstream languages must rather enforce a certain discipline. And the rules for the macros done right are very simple and well known.
- jeffreyrogers 10y ago
  Honestly, I don't get the fuss about macros. I haven't seen many (any?) use cases for them, where they don't make the code harder to understand while doing something that isn't already straightforward in the base language.
  - sklogic 10y ago
    > Honestly, I don't get the fuss about macros. DSLs are an ultimate solution. And DSLs are best implemented with macros. > where they don't make the code harder to understand Macros are there to make code easier to understand. I just explained it in detail elsewhere: https://news.ycombinator.com/item?id=11705170 https://news.ycombinator.com/item?id=11705170
    - jeffreyrogers 10y ago
      Yes, I get theory, but I haven't seen much use for them in practice.
      - sklogic 10y ago
        It puzzles me too, that people are not using the most powerful development technique. I cannot imagine not using macros for pretty much everything I do.
        wry_discontent 10y ago
        I've written a handful of Clojure and Emacs Lisp, but I don't get macros. How is a macro different than passing a quoted list to a function? Maybe I just need to start slinging more lisp, but I don't see how they're particularly different from functions.
        sklogic 10y ago
        > How is a macro different than passing a quoted list to a function? Macro is a function that is executed in compile time. Think of it as a way of extending your compiler with new functionality. For example, your language does not have support for pattern matching originally. It's not a problem - you can define a macro that adds such a functionality to a language. You cannot do it with functions - it must be compiled and optimised before execution, and functions cannot introduce new identifiers into a scope. Another simple example would be something like list comprehensions - also introducing variables and also requiring optimisations in compile time. And at extreme level, macros can be used to turn your host language into something totally different. Not just add few new features, but turn it into another language. Lisp can become an ML or Haskell, or Prolog, or Java, or whatever else you can imagine. Macros can change syntax, can implement new semantics. None of it can be done with just functions.
smcl 10y ago
It's interesting to see Peter Norvig replying, but his answer is a little unsatisfying "oh but it did..." The more interesting and honest reply in my opinion is ranked in second place by Robert Smith - sounds like he did some proper reflecting on what it is to be a Lisp programmer nowadays and what the language's (or implementation, since this question is for CL specifically) shortcomings are
VeejayRampay 10y ago
It might not have fixed the world, but it has been an influence on other PLs and programming in general. It helped bring several interesting concepts to the forefront and it at least provided an alternative, which is nice and healthy. LISP didn't "fix the world", but in my view, it helped make it slightly better.
chvid 10y ago
Why on earth would it fix the world? It was a step forward in the history of programming languages; but somehow the end of it, the final fix? Why would anyone expect that? Programming languages are about providing a useful way for humans to formulate and implement their ideas. Starting by turning things on their head reverse polish notation style is bad start as it is counter intuitive to nearly everyone.
- pjc50 10y ago
  but somehow the end of it, the final fix? Why would anyone expect that? Have you met a Lisp advocate? More seriously, programming is as you say a way of turning thoughts into mechanical implementations. But not everyone thinks the same way or finds the same things intuitive. So some people stumble across Lisp or Forth and find it matches their way of thinking so perfectly that they can't understand why not everyone agrees. Pragmatism counts for a lot in programming language deployment too. There was no big platform that required or encouraged Lisp in the way that Sun did for Java, the browser does for Javascript, or web backend did for PHP and Perl.
- dunkelheit 10y ago
  My theory is that because programming is mostly about fighting incidental complexity, it is very easy to believe that if there were some way of getting rid of it, programs would write itself and programming would be reduced to sipping daiquiris on a beach. Lisp (especially compared to C) indeed helps to reduce incidental complexity to some extent. So it is easy fall into almost religious belief that Lisp is the way to pure programming bliss. Of course the promise is never fulfilled because domain complexity and even incidental complexity is here to stay.
  - sklogic 10y ago
    > helps to reduce incidental complexity to some extent This extend stays untapped. You cannot even imagine how far this ability to eliminate complexity extends. Of course, it's not just Lisp, it's Lisp (or any other meta-language) combined with a certain design methodology. A methodology which pretty much boils down to a notion that "everything is a compiler". And, since compilers are trivial and there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms, this way you can eliminate all possible complexity, no matter what your domain is. Yet, I find it amusing that only a handful of people are even aware of this ultimate methodology.
euske 10y ago
Common Lisp doesn't have type checking and well defined namespace. And it has eval. That's certainly a no go for people like me. Most programmers in the world don't have to invent/implement a radical new idea in five minutes.
- adwf 10y ago
  Eval? The entire point of Lisp macros is toying around with evalulation in a safe fashion. It's other languages that do it so dangerously that gives eval a bad name. Lisp is the shining example of how to do it right.
  - chvid 10y ago
    AFAIK macros in Lisp are turing complete and executed at compile time. This means (in principle) that there is no guarantee that a Lisp compile will ever terminate. I don't know why the OP is been down voted. Lisp is not for everyone and every application; I think that is a perfectly reasonable point of view.
    - pjc50 10y ago
      C++ templates are also turing complete, executed at compile time, and can result in extremely high compile times: http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turing-complete.html http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turi... I don't think that failure to terminate compiles is too big a problem in practice; treat it as just another form of compile-time error and fix your program.
      - chvid 10y ago
        It is a problem for tool support; one of the reasons why Java and C# has better editors.
        sklogic 10y ago
        It's only a problem if your tools are done the wrong way. The proper tools can benefit from the macros instead. Of course, some discipline in how macros are implemented is required.
adwf 10y ago
I often think it's because Common Lisp was one of the last pre-web languages to be designed (or standardised anyway). Newer languages like Java/Javascript/Clojure/etc. had the advantage of being able to build a strong community on the web. Whereas Lisp was just on its way out as the web was rising. The hardware and the long standardisation process didn't help either. That, combined with it being both an old and a new language, meant that when the spec was done there wasn't the excitement you get with a new language like Python or Clojure. It missed the boat with building a web community and missed again in building hype. However, Norvig is completely correct in saying that just because the CL language itself may not have taken off, doesn't mean the ideas didn't make it everywhere.
- paddy_m 10y ago
  Perl and python, and c++. Perl especially was influenced by newsgroups, so maybe that doesn't count.
  - adwf 10y ago
    Yeah, but they arose as the web was starting in the 90s. Whereas Lisp had been around since the 50's. The standardisation effort wasn't the development of an exciting new language, just the finalisation of an old one.
- hga 10y ago
  There's also the factor that the over promising of what expert systems and AI in general could do that lead to the AI Winter were conveniently blamed on Lisp, seeing as how it couldn't have been simple failures to execute, or execute the impossible. Or so goes one version of the Official Story, I wasn't really a witness to more than the beginning of that, when they were grossly over-hyped. Or solved the wrong problem, my favorite example there being DEC's configuration -> part numbers to order expert system. Sun made it simple, at the lowest level of a workstation, the major choices of the sort DEC was optimizing came down to which keyboard and power cord you ordered to fix your country's standards.
mtrycz 10y ago
While i do like the the idea of DSLs and they certainly do have a place, what I would love to have is to be able to enforce a strict subset of a language in a piece of code. Where first there was discipline and hardly passed on conventions, there now would be statically enforced rule coerction. I deeply believe that the utility of language is not in what it enables, but in what it forbids. For example Clojure and Rust have neat mechanisms to deal with mutability, where you need something extra to mutate a value. Contrast this to C where you need to go extra lenghts to make things const (ie nobody'll do it). Is this even possible without writing your own tools?
- klibertp 10y ago
  Racket. It's built as a platform for defining arbitrarily simple or complex languages and integrating them together. You should take a look at it. See http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____.html http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____.... : > To a language designer, Racket is a programming language laboratory. This does not mean that the language is unstable. The designers do not change the language in a whimsical manner. That is, Racket comes with a unique collection of linguistic mechanisms that enable the quick construction of reliable languages, language fragments, and their composition. These tools are so easy to use that plain programmers can design a language after a little bit of instruction. So when a well-trained programmer decides that none of the available dialects is well-suited for a task, he designs a new dialect and writes his program in it. As Paul Hudak said, “the ultimate abstraction is a domain specific language.”
- sklogic 10y ago
  You can have both a flexibility of DSLs and strict rule enforcement. Just write a restricted DSL.
- jeffreyrogers 10y ago
  Some languages have this. For example, SPARK is a subset of Ada that can guarantee certain properties about your code. Similarly D has a subset that the compiler will verify is type and memory safe.
chvid 10y ago
Yes. I have. People with gray beard, strong views on programming languages, politics and UFOs. I always assumed that were dressed up for the occasion and not really real; like someone doing a role playing game or maybe being Santa for the kids during Christmas.
- jordigh 10y ago
  You should meet Robert Smith or Peter Norvig, then, shatter some of those stereotypes.
- weavie 10y ago
  Hmm.. my beard isn't fully grey yet.
  - chvid 10y ago
    (Don't worry - it will be). Just making on joke what a "Lisp advocate" is. But seriously; if you meet people who really understand programming language design they will have full understanding for other ways of designing a language than whatever is their specialty. After all there is a reason why PL is still a developing field.
    - wolfgke 10y ago
      > (Don't worry - it will be). This assumes that weavie actually has a beard.
- chvid 10y ago
  Ok; HN really don't like jokes :-(
- dang 10y ago
  We detached this subthread from https://news.ycombinator.com/item?id=11712496 https://news.ycombinator.com/item?id=11712496 and marked it off-topic.
nabla9 10y ago
"And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?" -- Guy Steele, Sun Microsystems Labs (about Java) http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...
- jeffreyrogers 10y ago
  If Java is halfway to Lisp it's no surprise Lisp didn't take over the world.
  - wry_discontent 10y ago
    In what world is Java halfway to lisp?
    - dang 10y ago
      The world of its time.
    - wglb 10y ago
      In a world filled with COBOL, C, Powerbuilder, CICS. Oh, and TELON.
      - wglb 10y ago
        And there may have also been a language GOOFBOL (where BOL is Business Oriented Language), but I may have just made that up.
jordigh 10y ago
I'm pretty sure the biggest reason it hasn't caught on is the syntax. http://jordi.platinum.linux.pl/piccies/lisp.png http://jordi.platinum.linux.pl/piccies/lisp.png It's the most frequent complaint uttered against Lisp for a reason. All of the other things mentioned in the top responses are addressed by modern Lisp variants. If Rust or Swift were implemented with sexps and everything else about them were equal, they would have a lot of difficulty winning hearts and minds.
- mdpopescu 10y ago
  Agreed, but it's not just the parentheses - "car-or-zero"? Really? If you have a language where you can say "at least it's not APL", that's not a feature...
  - hga 10y ago
    That's where Common Lisp's roots that go back to the first version that ran as subroutines to punched card FORTRAN on a vacuum tube IBM computer show. Contents of Address and Decrement Registers -> car and cdr, for normal list processing they're often renamed or aliased first and rest. BUT, they hang around because of old code, and they're composable, e.g. the 2nd Lisp Machine design and first to be semi-mass produced was the CADR, as in (car (cdr list)), or (first (rest *list)), is in the 2nd item in the list. So, yeah, if you don't want to have to learn a lot of arcane stuff that's incidental complexity purely because of history, go for newer dialects like Scheme and Clojure which had the opportunity to rationalize a lot of this (but Scheme at least still has cadr and company because they're too useful).
    - mdpopescu 10y ago
      Oh, I know the history, I just dislike "because we've always done it this way" as a rule. Imagine having a code full of "moo x > 5", with "moo" instead of "if" because that was the sound made by the favorite pet of the initial programmer...
- pjmlp 10y ago
  Usually people that complain, don't spend time counting the amount of times () [] {} appear on their beloved programming languages. print(args) => (print args) if (cond) { exp1} else {exp2 } => (if (cond) (exp1) (exp2)) array[index] => (index array) And so on. On average there is probably the same amount, but visually it kind of appears to be more.
keymone 10y ago
i feel like a lot of lisps are trying to drag this "everything is a list" abstraction way too far than they should. clojure takes more practical and pragmatic approach of giving native residency in a language for useful data structures like arrays, maps and sets and it (along with many other features) has totally won me over. it's incredibly important for a language to be convenient. edit: and not only me it seems: https://www.google.com/trends/explore#q=%2Fm%2F03yb8hb%2C%20%2Fm%2F06zrb%2C%20%2Fm%2F01tlw%2C%20%2Fm%2F0974fb&cmpt=q&tz=Etc%2FGMT-2 https://www.google.com/trends/explore#q=%2Fm%2F03yb8hb%2C%20...
- nabla9 10y ago
  >i feel like a lot of lisps are trying to drag this "everything is a list" I think you are speaking out of ignorance here. "everything is a list" is just a metaphor. Everything is either list or atom and almost everything is atom.
  - arethuza 10y ago
    Common Lisp has a fairly rich set of standard data types - including hashtables, streams, arrays and the ability to define structures and then there is the exciting world of CLOS on top of all of that... https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node15.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node15.html
  - keymone 10y ago
    > Everything is either list or atom and almost everything is atom. how can you both say this and that i'm talking out of ignorance? you're basically confirming my words. larger point i was making is that "everything is a list" abstraction/metaphor influenced the decision to not include native representation of other data structures into the language. because parens are enough to represent everything. well they aren't enough for people looking for convenient, practical and simple languages.
    - Grue3 10y ago
      No, you're wrong. Common Lisp has hash-tables, arrays and pretty much any data structure you need. But they are not lists, they are atoms. Hence why almost everything is an atom. It's well known that linked lists are inefficient in many ways. Nobody writes programs using only lists.
starseeker 10y ago
It lacks a graphical application development framework that's portable and usable. Java eventually solved this problem (more or less) but neither Garnet nor CLIM ever reached a level where most Gtk/Qt/* programmers would seriously consider using them. Web front ends are find for certain things, but for a lot of the application domains where you might consider Lisp you want a proper desktop GUI application. (This would have been especially true in the early years.) The expressiveness and power of Lisp look a lot less attractive when you run headlong into the practical problems of combining that power with a modern GUI. There are still a few problem domains (like Computer Algebra) where Lisp provides enough benefits to be worth bridging the gap between its world and modern operating system environments, but by and large the inability to be a complete solution I think serves as a disincentive to use Lisp.
- _ph_ 10y ago
  For portable and easy to use there is LTk, and of course there are bindings to Gtk and Qt. I think though, if the Lisp community were a bit larger, these bindings would see more development and more refinement.
mathheaven 10y ago
Lisp is only a general idea about syntax and macros. If you want numerical computations you want a big library like blas, and the problem is about efficient memory allocation, cache and garbage collection. If you want deep learning you want a big library. Lisp is like arithmetic, without more concepts or libraries it doesn't work, you have to reinvent the wheel. R provides near 8000 useful packages, that's what makes a language a useful tool to solve a problem, and it can call routines in C, fortran or use C with armadillo. To sum up, a language without a great community and specific libraries is not a way to fix the world, on top of that there are few jobs using Lisp. Clojure is trying to take advantage of all those java libraries, that is a good step in the right direction. Clasp is another idea trying to use C++.
hack37 10y ago
Having recently been introduced to the lisp world (~1 year) it has been a revelation to me. It really changed the way I see programming and my expectations of it. I do not understand how it has not taken over the world. Background: I have ~15 years of experience in programming. In my spare time I learn new languages.
- rodgerd 10y ago
  > I do not understand how it has not taken over the world. > In my spare time I learn new languages. A moment's reflection on the latter would explain the former.
DonaldFisk 10y ago
I'll cons this onto my list of reasons why Lisp "failed". Other explanations are: Worse is Better: https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html The Bipolar Lisp Programmer: https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqvm3GXiE https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqv... The Lisp Curse: http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html Where Lisp Fails: http://www.loper-os.org/?p=69 http://www.loper-os.org/?p=69 Lisp is still my language of choice. I'm more productive in it than other languages (C, Java), not because I know the other languages less well, but because they're less expressive. So, for me, Lisp fixes the world. Why aren't people using it? There are three things often missed. (1) People's choice of programming languages perhaps isn't as rational as they might like to believe. There's a large amount of personal taste involved. For a personal project, that's no barrier, you can use your favourite language, but if you're working with a dozen other people, Lisp is unlikely to be adopted because more people on the team will prefer Java, C++, or Python. Multiply over all the commercial projects and you can see why you can't build a career around Lisp programming. (2) There are accidents of history. When DEC decided to discontinue the PDP-10, the days of the hacker community built around it were numbered. Those involved then went on to build Lisp machines, but they were undercut by cheaper, commodity hardware which ran Unix. Then, the AI winter arrived. It was bad for Lisp, but Prolog fared far worse. (3) Linguistic relativity. The Sapir-Whorf hypothesis might be dubious for natural language, but for programming languages it certainly does apply. If you're uncomfortable with Lisp, you won't be tackling problems at which Lisp excels, or (at best) you'll do them in a completely different way, and it will take you longer. The result is that people think their language of choice is fine for everything that matters, and the problems they don't tackle don't matter to them.
- hga 10y ago
  (2) There are accidents of history. When DEC decided to discontinue the PDP-10, the days of the hacker community built around it were numbered. Those involved then went on to build Lisp machines... Nit on this bit of history: the PDP-6/10/Decsystem 20 architecture was a dead end due to its maximum address space of 1 MiB (of 9 bit bytes), but was still a very healthy line of computers when the Lisp Machine effort started circa 1974, about a decade before DEC dumped the whole line, then a 100 million a year business (a lot of us looked at that and decided DEC's business sense was so poor we weren't going to invest any more then we could in their systems, which of course turned out to be absolutely right).
znpy 10y ago
I bought Graham's "Ansi Common Lisp" book and read it briefly, and tried to write some code as well. I also read "Successful Lisp" briefly. Hoping to give constructive feedback and not to start a flame, here are some opinions/impressions. Please note that : 1. These are mostly impressions, not complete opinions. 2. I am only talking about Common Lisp. I am not talking about Scheme, Clojure or other stuff. Ok then: 1) Lisp feels... Messy. Expecially when you're learning it. 2) Maybe... Too many implementations? This is not a problem per se, but sometime it happens that not all the implementation implement all of the features, or implement them differently enough that you have to write the same code for different interpreters. Example: https://github.com/stumpwm/stumpwm/blob/master/make-image.lisp.in https://github.com/stumpwm/stumpwm/blob/master/make-image.li... see the various #+clisp, #+sbcl and stuff. 3) Batteries not included. The ANSI standard defines the language and pretty much nothing more. Yeah you have libraries and quicklisp, but it feels fragile and quite "opaque". Also, I always used SBCL and I am not 100% sure all the libraries work with all of the interpreters/compilers. I feel it would be nice to have a new standard that defines a set of additional API that implementors should implement. Ideally, it would be nice to have common lisp to be "batteries included" like Python. But please let's avoid the Scheme SRFI mess. Consider this: it is a fact that MIT introductory programming class switched from Scheme to Python because among other things, students were spending too much time reading libraries manuals and implementation references instead of writing code. 5) The Common Lisp HyperSpec. Let's say I find it to have a poor usability. 4) Stuff is generally poorly documented, and fragmented. While things like quicklisp work, it's visible that those are basically one-man projects. This isn't reassuring. 5) Given the heritage, there is not such thing as a "Lisp community" and the lack of governance is quite evident in the sense of lack of direction and lack of uniformity in pretty much everything. 6) Emacs. "It's lisp!". Well actually emacs lisp and common lisp are different languages, and differences will come up. Emacs is my editor of choice, but I' starting to grow worried about it. These are some of the reasons why I decided not to "invest" in Common Lisp.
- hga 10y ago
  Consider this: it is a fact that MIT introductory programming class switched from Scheme to Python because among other things, students were spending too much time reading libraries manuals and implementation references instead of writing code. Nope, the decision was entirely political, driven by panic when post-dot.com crash enrollment dropped by more than half after being a steady 40% of the undergraduates for decades. And I believe your specifics are entirely wrong, but I don't know exactly how the course evolved, e.g. they threw in a couple of weeks of OO that isn't in SICP as that became popular. But at least in the beginning of the course, it's all self-contained in the book. Much of the rest of what you say is spot on, and are some of the reasons I gave up on mainline/Common Lisp 30+ years ago.
lazyant 10y ago
For the same reason a lot of people can play the guitar but not the violin; it's easier (at least to get started) and in many cases get the job done so the other option is not missed.
lcall 10y ago
While Lisp had big, influential ideas, it wasn't at any time the shortest path to getting their immediate task done, for "enough" programmers. The successful languages managed to be the shortest path to "done", for more use cases. (Which makes me think about my project for managing the world's knowledge, http://onemodel.org http://onemodel.org and how to be more practical like fortran or cobol were in their prime, and not primarily idealistic like Lisp in its prime. Hmm.)

83 points by weeber 10y ago

lispm 10y ago

For those who don't know Peter Norvig, let me mention that he wrote one of the best Lisp books: http://norvig.com/paip.html http://norvig.com/paip.html

dragonquest 10y ago
Not just one of the best Lisp books; but one of the best books on programming, period.
- S4M 10y ago
  I think it's a programming book that happens to use Lisp as an example language to explain AI concepts and algorithms, rather than a Lisp book.
  - lispm 10y ago
    Actually not. The book is full of beautiful code, combined with deep Lisp lore how to write that code.

sklogic 10y ago

Norvig nailed it - instead of being sissy about macros altogether the mainstream languages must rather enforce a certain discipline. And the rules for the macros done right are very simple and well known.

jeffreyrogers 10y ago
Honestly, I don't get the fuss about macros. I haven't seen many (any?) use cases for them, where they don't make the code harder to understand while doing something that isn't already straightforward in the base language.
- sklogic 10y ago
  > Honestly, I don't get the fuss about macros. DSLs are an ultimate solution. And DSLs are best implemented with macros. > where they don't make the code harder to understand Macros are there to make code easier to understand. I just explained it in detail elsewhere: https://news.ycombinator.com/item?id=11705170 https://news.ycombinator.com/item?id=11705170
  - jeffreyrogers 10y ago
    Yes, I get theory, but I haven't seen much use for them in practice.
    - sklogic 10y ago
      It puzzles me too, that people are not using the most powerful development technique. I cannot imagine not using macros for pretty much everything I do.
      - wry_discontent 10y ago
        I've written a handful of Clojure and Emacs Lisp, but I don't get macros. How is a macro different than passing a quoted list to a function? Maybe I just need to start slinging more lisp, but I don't see how they're particularly different from functions.
        sklogic 10y ago
        > How is a macro different than passing a quoted list to a function? Macro is a function that is executed in compile time. Think of it as a way of extending your compiler with new functionality. For example, your language does not have support for pattern matching originally. It's not a problem - you can define a macro that adds such a functionality to a language. You cannot do it with functions - it must be compiled and optimised before execution, and functions cannot introduce new identifiers into a scope. Another simple example would be something like list comprehensions - also introducing variables and also requiring optimisations in compile time. And at extreme level, macros can be used to turn your host language into something totally different. Not just add few new features, but turn it into another language. Lisp can become an ML or Haskell, or Prolog, or Java, or whatever else you can imagine. Macros can change syntax, can implement new semantics. None of it can be done with just functions.

smcl 10y ago

It's interesting to see Peter Norvig replying, but his answer is a little unsatisfying "oh but it did..." The more interesting and honest reply in my opinion is ranked in second place by Robert Smith - sounds like he did some proper reflecting on what it is to be a Lisp programmer nowadays and what the language's (or implementation, since this question is for CL specifically) shortcomings are

VeejayRampay 10y ago

It might not have fixed the world, but it has been an influence on other PLs and programming in general. It helped bring several interesting concepts to the forefront and it at least provided an alternative, which is nice and healthy. LISP didn't "fix the world", but in my view, it helped make it slightly better.

chvid 10y ago

Why on earth would it fix the world? It was a step forward in the history of programming languages; but somehow the end of it, the final fix? Why would anyone expect that? Programming languages are about providing a useful way for humans to formulate and implement their ideas. Starting by turning things on their head reverse polish notation style is bad start as it is counter intuitive to nearly everyone.

pjc50 10y ago
but somehow the end of it, the final fix? Why would anyone expect that? Have you met a Lisp advocate? More seriously, programming is as you say a way of turning thoughts into mechanical implementations. But not everyone thinks the same way or finds the same things intuitive. So some people stumble across Lisp or Forth and find it matches their way of thinking so perfectly that they can't understand why not everyone agrees. Pragmatism counts for a lot in programming language deployment too. There was no big platform that required or encouraged Lisp in the way that Sun did for Java, the browser does for Javascript, or web backend did for PHP and Perl.
dunkelheit 10y ago
My theory is that because programming is mostly about fighting incidental complexity, it is very easy to believe that if there were some way of getting rid of it, programs would write itself and programming would be reduced to sipping daiquiris on a beach. Lisp (especially compared to C) indeed helps to reduce incidental complexity to some extent. So it is easy fall into almost religious belief that Lisp is the way to pure programming bliss. Of course the promise is never fulfilled because domain complexity and even incidental complexity is here to stay.
- sklogic 10y ago
  > helps to reduce incidental complexity to some extent This extend stays untapped. You cannot even imagine how far this ability to eliminate complexity extends. Of course, it's not just Lisp, it's Lisp (or any other meta-language) combined with a certain design methodology. A methodology which pretty much boils down to a notion that "everything is a compiler". And, since compilers are trivial and there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms, this way you can eliminate all possible complexity, no matter what your domain is. Yet, I find it amusing that only a handful of people are even aware of this ultimate methodology.

euske 10y ago

Common Lisp doesn't have type checking and well defined namespace. And it has eval. That's certainly a no go for people like me. Most programmers in the world don't have to invent/implement a radical new idea in five minutes.

adwf 10y ago
Eval? The entire point of Lisp macros is toying around with evalulation in a safe fashion. It's other languages that do it so dangerously that gives eval a bad name. Lisp is the shining example of how to do it right.
- chvid 10y ago
  AFAIK macros in Lisp are turing complete and executed at compile time. This means (in principle) that there is no guarantee that a Lisp compile will ever terminate. I don't know why the OP is been down voted. Lisp is not for everyone and every application; I think that is a perfectly reasonable point of view.
  - pjc50 10y ago
    C++ templates are also turing complete, executed at compile time, and can result in extremely high compile times: http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turing-complete.html http://cpptruths.blogspot.co.uk/2005/11/c-templates-are-turi... I don't think that failure to terminate compiles is too big a problem in practice; treat it as just another form of compile-time error and fix your program.
    - chvid 10y ago
      It is a problem for tool support; one of the reasons why Java and C# has better editors.
      - sklogic 10y ago
        It's only a problem if your tools are done the wrong way. The proper tools can benefit from the macros instead. Of course, some discipline in how macros are implemented is required.

adwf 10y ago

I often think it's because Common Lisp was one of the last pre-web languages to be designed (or standardised anyway). Newer languages like Java/Javascript/Clojure/etc. had the advantage of being able to build a strong community on the web. Whereas Lisp was just on its way out as the web was rising. The hardware and the long standardisation process didn't help either. That, combined with it being both an old and a new language, meant that when the spec was done there wasn't the excitement you get with a new language like Python or Clojure. It missed the boat with building a web community and missed again in building hype. However, Norvig is completely correct in saying that just because the CL language itself may not have taken off, doesn't mean the ideas didn't make it everywhere.

paddy_m 10y ago
Perl and python, and c++. Perl especially was influenced by newsgroups, so maybe that doesn't count.
- adwf 10y ago
  Yeah, but they arose as the web was starting in the 90s. Whereas Lisp had been around since the 50's. The standardisation effort wasn't the development of an exciting new language, just the finalisation of an old one.
hga 10y ago
There's also the factor that the over promising of what expert systems and AI in general could do that lead to the AI Winter were conveniently blamed on Lisp, seeing as how it couldn't have been simple failures to execute, or execute the impossible. Or so goes one version of the Official Story, I wasn't really a witness to more than the beginning of that, when they were grossly over-hyped. Or solved the wrong problem, my favorite example there being DEC's configuration -> part numbers to order expert system. Sun made it simple, at the lowest level of a workstation, the major choices of the sort DEC was optimizing came down to which keyboard and power cord you ordered to fix your country's standards.

mtrycz 10y ago

While i do like the the idea of DSLs and they certainly do have a place, what I would love to have is to be able to enforce a strict subset of a language in a piece of code. Where first there was discipline and hardly passed on conventions, there now would be statically enforced rule coerction. I deeply believe that the utility of language is not in what it enables, but in what it forbids. For example Clojure and Rust have neat mechanisms to deal with mutability, where you need something extra to mutate a value. Contrast this to C where you need to go extra lenghts to make things const (ie nobody'll do it). Is this even possible without writing your own tools?

klibertp 10y ago
Racket. It's built as a platform for defining arbitrarily simple or complex languages and integrating them together. You should take a look at it. See http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____.html http://www.ccs.neu.edu/home/matthias/Thoughts/Racket_is____.... : > To a language designer, Racket is a programming language laboratory. This does not mean that the language is unstable. The designers do not change the language in a whimsical manner. That is, Racket comes with a unique collection of linguistic mechanisms that enable the quick construction of reliable languages, language fragments, and their composition. These tools are so easy to use that plain programmers can design a language after a little bit of instruction. So when a well-trained programmer decides that none of the available dialects is well-suited for a task, he designs a new dialect and writes his program in it. As Paul Hudak said, “the ultimate abstraction is a domain specific language.”
sklogic 10y ago
You can have both a flexibility of DSLs and strict rule enforcement. Just write a restricted DSL.
jeffreyrogers 10y ago
Some languages have this. For example, SPARK is a subset of Ada that can guarantee certain properties about your code. Similarly D has a subset that the compiler will verify is type and memory safe.

chvid 10y ago

Yes. I have. People with gray beard, strong views on programming languages, politics and UFOs. I always assumed that were dressed up for the occasion and not really real; like someone doing a role playing game or maybe being Santa for the kids during Christmas.

jordigh 10y ago
You should meet Robert Smith or Peter Norvig, then, shatter some of those stereotypes.
weavie 10y ago
Hmm.. my beard isn't fully grey yet.
- chvid 10y ago
  (Don't worry - it will be). Just making on joke what a "Lisp advocate" is. But seriously; if you meet people who really understand programming language design they will have full understanding for other ways of designing a language than whatever is their specialty. After all there is a reason why PL is still a developing field.
  - wolfgke 10y ago
    > (Don't worry - it will be). This assumes that weavie actually has a beard.
chvid 10y ago
Ok; HN really don't like jokes :-(
dang 10y ago
We detached this subthread from https://news.ycombinator.com/item?id=11712496 https://news.ycombinator.com/item?id=11712496 and marked it off-topic.

nabla9 10y ago

"And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?" -- Guy Steele, Sun Microsystems Labs (about Java) http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m...

jeffreyrogers 10y ago
If Java is halfway to Lisp it's no surprise Lisp didn't take over the world.
- wry_discontent 10y ago
  In what world is Java halfway to lisp?
  - dang 10y ago
    The world of its time.
  - wglb 10y ago
    In a world filled with COBOL, C, Powerbuilder, CICS. Oh, and TELON.
    - wglb 10y ago
      And there may have also been a language GOOFBOL (where BOL is Business Oriented Language), but I may have just made that up.

jordigh 10y ago

I'm pretty sure the biggest reason it hasn't caught on is the syntax. http://jordi.platinum.linux.pl/piccies/lisp.png http://jordi.platinum.linux.pl/piccies/lisp.png It's the most frequent complaint uttered against Lisp for a reason. All of the other things mentioned in the top responses are addressed by modern Lisp variants. If Rust or Swift were implemented with sexps and everything else about them were equal, they would have a lot of difficulty winning hearts and minds.

mdpopescu 10y ago
Agreed, but it's not just the parentheses - "car-or-zero"? Really? If you have a language where you can say "at least it's not APL", that's not a feature...
- hga 10y ago
  That's where Common Lisp's roots that go back to the first version that ran as subroutines to punched card FORTRAN on a vacuum tube IBM computer show. Contents of Address and Decrement Registers -> car and cdr, for normal list processing they're often renamed or aliased first and rest. BUT, they hang around because of old code, and they're composable, e.g. the 2nd Lisp Machine design and first to be semi-mass produced was the CADR, as in (car (cdr list)), or (first (rest *list)), is in the 2nd item in the list. So, yeah, if you don't want to have to learn a lot of arcane stuff that's incidental complexity purely because of history, go for newer dialects like Scheme and Clojure which had the opportunity to rationalize a lot of this (but Scheme at least still has cadr and company because they're too useful).
  - mdpopescu 10y ago
    Oh, I know the history, I just dislike "because we've always done it this way" as a rule. Imagine having a code full of "moo x > 5", with "moo" instead of "if" because that was the sound made by the favorite pet of the initial programmer...
pjmlp 10y ago
Usually people that complain, don't spend time counting the amount of times () [] {} appear on their beloved programming languages. print(args) => (print args) if (cond) { exp1} else {exp2 } => (if (cond) (exp1) (exp2)) array[index] => (index array) And so on. On average there is probably the same amount, but visually it kind of appears to be more.

keymone 10y ago

i feel like a lot of lisps are trying to drag this "everything is a list" abstraction way too far than they should. clojure takes more practical and pragmatic approach of giving native residency in a language for useful data structures like arrays, maps and sets and it (along with many other features) has totally won me over. it's incredibly important for a language to be convenient. edit: and not only me it seems: https://www.google.com/trends/explore#q=%2Fm%2F03yb8hb%2C%20%2Fm%2F06zrb%2C%20%2Fm%2F01tlw%2C%20%2Fm%2F0974fb&cmpt=q&tz=Etc%2FGMT-2 https://www.google.com/trends/explore#q=%2Fm%2F03yb8hb%2C%20...

nabla9 10y ago
>i feel like a lot of lisps are trying to drag this "everything is a list" I think you are speaking out of ignorance here. "everything is a list" is just a metaphor. Everything is either list or atom and almost everything is atom.
- arethuza 10y ago
  Common Lisp has a fairly rich set of standard data types - including hashtables, streams, arrays and the ability to define structures and then there is the exciting world of CLOS on top of all of that... https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node15.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node15.html
- keymone 10y ago
  > Everything is either list or atom and almost everything is atom. how can you both say this and that i'm talking out of ignorance? you're basically confirming my words. larger point i was making is that "everything is a list" abstraction/metaphor influenced the decision to not include native representation of other data structures into the language. because parens are enough to represent everything. well they aren't enough for people looking for convenient, practical and simple languages.
  - Grue3 10y ago
    No, you're wrong. Common Lisp has hash-tables, arrays and pretty much any data structure you need. But they are not lists, they are atoms. Hence why almost everything is an atom. It's well known that linked lists are inefficient in many ways. Nobody writes programs using only lists.

starseeker 10y ago

It lacks a graphical application development framework that's portable and usable. Java eventually solved this problem (more or less) but neither Garnet nor CLIM ever reached a level where most Gtk/Qt/* programmers would seriously consider using them. Web front ends are find for certain things, but for a lot of the application domains where you might consider Lisp you want a proper desktop GUI application. (This would have been especially true in the early years.) The expressiveness and power of Lisp look a lot less attractive when you run headlong into the practical problems of combining that power with a modern GUI. There are still a few problem domains (like Computer Algebra) where Lisp provides enough benefits to be worth bridging the gap between its world and modern operating system environments, but by and large the inability to be a complete solution I think serves as a disincentive to use Lisp.

_ph_ 10y ago
For portable and easy to use there is LTk, and of course there are bindings to Gtk and Qt. I think though, if the Lisp community were a bit larger, these bindings would see more development and more refinement.

mathheaven 10y ago

Lisp is only a general idea about syntax and macros. If you want numerical computations you want a big library like blas, and the problem is about efficient memory allocation, cache and garbage collection. If you want deep learning you want a big library. Lisp is like arithmetic, without more concepts or libraries it doesn't work, you have to reinvent the wheel. R provides near 8000 useful packages, that's what makes a language a useful tool to solve a problem, and it can call routines in C, fortran or use C with armadillo. To sum up, a language without a great community and specific libraries is not a way to fix the world, on top of that there are few jobs using Lisp. Clojure is trying to take advantage of all those java libraries, that is a good step in the right direction. Clasp is another idea trying to use C++.

hack37 10y ago

Having recently been introduced to the lisp world (~1 year) it has been a revelation to me. It really changed the way I see programming and my expectations of it. I do not understand how it has not taken over the world. Background: I have ~15 years of experience in programming. In my spare time I learn new languages.

rodgerd 10y ago
> I do not understand how it has not taken over the world. > In my spare time I learn new languages. A moment's reflection on the latter would explain the former.

DonaldFisk 10y ago

I'll cons this onto my list of reasons why Lisp "failed". Other explanations are: Worse is Better: https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html The Bipolar Lisp Programmer: https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqvm3GXiE https://groups.google.com/forum/#!topic/comp.lang.lisp/eicqv... The Lisp Curse: http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html Where Lisp Fails: http://www.loper-os.org/?p=69 http://www.loper-os.org/?p=69 Lisp is still my language of choice. I'm more productive in it than other languages (C, Java), not because I know the other languages less well, but because they're less expressive. So, for me, Lisp fixes the world. Why aren't people using it? There are three things often missed. (1) People's choice of programming languages perhaps isn't as rational as they might like to believe. There's a large amount of personal taste involved. For a personal project, that's no barrier, you can use your favourite language, but if you're working with a dozen other people, Lisp is unlikely to be adopted because more people on the team will prefer Java, C++, or Python. Multiply over all the commercial projects and you can see why you can't build a career around Lisp programming. (2) There are accidents of history. When DEC decided to discontinue the PDP-10, the days of the hacker community built around it were numbered. Those involved then went on to build Lisp machines, but they were undercut by cheaper, commodity hardware which ran Unix. Then, the AI winter arrived. It was bad for Lisp, but Prolog fared far worse. (3) Linguistic relativity. The Sapir-Whorf hypothesis might be dubious for natural language, but for programming languages it certainly does apply. If you're uncomfortable with Lisp, you won't be tackling problems at which Lisp excels, or (at best) you'll do them in a completely different way, and it will take you longer. The result is that people think their language of choice is fine for everything that matters, and the problems they don't tackle don't matter to them.

hga 10y ago
(2) There are accidents of history. When DEC decided to discontinue the PDP-10, the days of the hacker community built around it were numbered. Those involved then went on to build Lisp machines... Nit on this bit of history: the PDP-6/10/Decsystem 20 architecture was a dead end due to its maximum address space of 1 MiB (of 9 bit bytes), but was still a very healthy line of computers when the Lisp Machine effort started circa 1974, about a decade before DEC dumped the whole line, then a 100 million a year business (a lot of us looked at that and decided DEC's business sense was so poor we weren't going to invest any more then we could in their systems, which of course turned out to be absolutely right).

znpy 10y ago

I bought Graham's "Ansi Common Lisp" book and read it briefly, and tried to write some code as well. I also read "Successful Lisp" briefly. Hoping to give constructive feedback and not to start a flame, here are some opinions/impressions. Please note that : 1. These are mostly impressions, not complete opinions. 2. I am only talking about Common Lisp. I am not talking about Scheme, Clojure or other stuff. Ok then: 1) Lisp feels... Messy. Expecially when you're learning it. 2) Maybe... Too many implementations? This is not a problem per se, but sometime it happens that not all the implementation implement all of the features, or implement them differently enough that you have to write the same code for different interpreters. Example: https://github.com/stumpwm/stumpwm/blob/master/make-image.lisp.in https://github.com/stumpwm/stumpwm/blob/master/make-image.li... see the various #+clisp, #+sbcl and stuff. 3) Batteries not included. The ANSI standard defines the language and pretty much nothing more. Yeah you have libraries and quicklisp, but it feels fragile and quite "opaque". Also, I always used SBCL and I am not 100% sure all the libraries work with all of the interpreters/compilers. I feel it would be nice to have a new standard that defines a set of additional API that implementors should implement. Ideally, it would be nice to have common lisp to be "batteries included" like Python. But please let's avoid the Scheme SRFI mess. Consider this: it is a fact that MIT introductory programming class switched from Scheme to Python because among other things, students were spending too much time reading libraries manuals and implementation references instead of writing code. 5) The Common Lisp HyperSpec. Let's say I find it to have a poor usability. 4) Stuff is generally poorly documented, and fragmented. While things like quicklisp work, it's visible that those are basically one-man projects. This isn't reassuring. 5) Given the heritage, there is not such thing as a "Lisp community" and the lack of governance is quite evident in the sense of lack of direction and lack of uniformity in pretty much everything. 6) Emacs. "It's lisp!". Well actually emacs lisp and common lisp are different languages, and differences will come up. Emacs is my editor of choice, but I' starting to grow worried about it. These are some of the reasons why I decided not to "invest" in Common Lisp.

hga 10y ago
Consider this: it is a fact that MIT introductory programming class switched from Scheme to Python because among other things, students were spending too much time reading libraries manuals and implementation references instead of writing code. Nope, the decision was entirely political, driven by panic when post-dot.com crash enrollment dropped by more than half after being a steady 40% of the undergraduates for decades. And I believe your specifics are entirely wrong, but I don't know exactly how the course evolved, e.g. they threw in a couple of weeks of OO that isn't in SICP as that became popular. But at least in the beginning of the course, it's all self-contained in the book. Much of the rest of what you say is spot on, and are some of the reasons I gave up on mainline/Common Lisp 30+ years ago.

lazyant 10y ago

For the same reason a lot of people can play the guitar but not the violin; it's easier (at least to get started) and in many cases get the job done so the other option is not missed.

lcall 10y ago

While Lisp had big, influential ideas, it wasn't at any time the shortest path to getting their immediate task done, for "enough" programmers. The successful languages managed to be the shortest path to "done", for more use cases. (Which makes me think about my project for managing the world's knowledge, http://onemodel.org http://onemodel.org and how to be more practical like fortran or cobol were in their prime, and not primarily idealistic like Lisp in its prime. Hmm.)