10 ms·

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp ins

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp inspired many programmers like the founder of Ruby. But I would not think of Lisp when it comes to solving day to day problems. I rather pick Python because it helps me solve all kinds of problems. There are many more solutions I can think of (Ruby, Node, Go, even Perl).

weavie 9y ago
We are getting to the stage now where a lot of languages are catching up with the features that lisp had in the 70's, so the huge benefits of lisp aren't quite as obvious as they used to be.
- flavio81 9y ago
  >so the huge benefits of lisp aren't quite as obvious as they used to be They still haven't caught up. I don't find any other language that gives at least 3 of these features - Fully interactive development -- i can recompile/redefine a function while the code is running - Fully interactive OOP development -- i can recompile/redefine a class while the code is running - OOP system based on multiple dispatch/multimethods - true metaprogramming done using the same language's syntax, not a special, cumbersome lib. - execution speed on par with the JVM and sometimes approaching C speed.
Jach 9y ago
Your confusion will go away once you recognize that Scheme is not Lisp. For most purposes, Lisp means Common Lisp, or one of the Lisps that ended up merging into Common Lisp. That means that Lisp does all of these things and more, which you might not expect if you've only seen Scheme/SICP: * Multi-paradigm programming (functional programming in the immutable sense is not dominant, the Lisp OOP system is top class, mutable state can be everywhere) * Rich looping mechanisms that don't require tail call contortions * Explicit typing that leads to optimized code and compile time warnings! (https://news.ycombinator.com/item?id=13389287 https://news.ycombinator.com/item?id=13389287) * Warnings at compile time (not run time!) about things like undefined functions/vars/wrong args/unused vars (https://news.ycombinator.com/item?id=14780381 https://news.ycombinator.com/item?id=14780381) * A pretty good set of libraries et al that (once you set up quicklisp) are just a function call away from trying out (https://notabug.org/CodyReichert/awesome-cl https://notabug.org/CodyReichert/awesome-cl) * (edit: one more since I like it a lot) Out of the box the Lisp system contains features you have to get from IDEs in other languages like breakpoints, tracing, inspection, code location questions like "who calls foo"... of course working with that system via emacs or something is nicer but it's basically all there in the base system (http://malisper.me/debugging-lisp-part-1-recompilation/ http://malisper.me/debugging-lisp-part-1-recompilation/)
- firepoet 9y ago
  To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language) https://en.wikipedia.org/wiki/Scheme_(programming_language)
  - bjoli 9y ago
    Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.
    - kamaal 9y ago
      Lisp user base is so small enough that these categories largely look pointless to people outside. For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.
      - lispm 9y ago
        > For all practical purposes CL, Scheme, Clojure and Elisp are all lisps. Since only CL and Emacs Lisp can and do share actual Lisp code, I call only them Lisp for practical purposes. For 'unpractical' purposes - they share no source code but are influenced by practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.
        kamaal 9y ago
        >>Since only CL and Emacs Lisp can and do share actual Lisp code But what exactly is 'actual lisp'. I mean what is this strict definition? Forgive me, I understand calling Scheme and CL as same might feel like saying Java and C++ as same. But one would be right in saying Java and C++ both come from a C based paradigm. On the same lines one could say CL and Scheme come from lisp paradigm. At this point in time both communities compared to any major language community are so small that one could refer to both as Lisp.
        9y ago
SlipperySlope 9y ago
Graham built a lisp shopping cart in the 1990s and sold it for funds that led to this website.
bjoli 9y ago
What made it click for me is the nature of scheme: a few, very well thought out abstractions, that compose well to build a really neat language. I never really made friends with other languages. Where scheme composes the primitives for problem solving, I find that languages like python or ruby provide either one way for each different thing, or a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with. The feeling I got when learning scheme was that of liberation. People have that epiphany all the time, but with different languages and techniques. For me it was scheme. And of course, I could never be bothered with syntax. If something becomes too verbose in scheme, I write a macro to simplify it. The only thing I need to know is whether something is a function or a macro. After 3 years of writing python on and off, I still manage to mess up syntax unless I think very hard before writing. I am however not a programmer, and of average intelligence. In fact I am on the very top of the bell curve, looking down on the rest of you.
- jstimpfle 9y ago
  > a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with. List comprehensions, to me, are what makes Python a productive (or the most productive) prototyping language. It allows me to think and program in mathematical relations without much fuss. Add to that nice sets and dicts (needed for asymptotic efficiency), and I can easily forgive it that it is built on an everything-is-an-object paradigm (there are few things I detest more than OOP). I've never truly understood why you need the meta-capabilities of LISP. I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing"). Macros amount to code generation. Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks. So far I've only ever generated a few C structs and enums, but I'm not sure it was an entirely good idea. It was super easy to generate from Python, anyway.
  - segmondy 9y ago
    Code generation is great. If you have a well understood domain, Lisp macros allows you to construct an effective DSL so that your programmers no longer have to write "lisp code" but to program in the new language. We do this today using functions/methods, but the issue tends to be that besides understanding these functions, we need to learn how to orchestrate them and write boiler code all around them. A good DSL hides all that. The issue as I've observed is that when most people create a DSL, they really forget that they have indeed created a new language and don't document it enough. The consumers of the DSL because they can read lisp code, don't focus and live in the DSL layer but wish to peer below then get terrified when they see the macros. Most developers get terrified when they peer one level below. Have you seen the bytecode generated by python or asm code by C? Do you think those are bad because those are code generation that don't look the way you think they ought to?
Zak 9y ago
The OP lists several features Lisp had decades before they were common to find in more widely used languages, so some of it is for historical reasons. There are two things lisps, including Scheme and Clojure have that are weak or absent in most popular languages: One is macros. Being able to transform code before it is run using the language's built-in data structures provides a solution when the language just doesn't have the abstraction you need. Used properly, this can be invaluable. Used improperly, of course, it can make a mess. The other is REPL-driven development. Most languages have a REPL, but they don't really embrace it the way Lisp does. I find this frustrating. Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time?
- falcolas 9y ago
  > Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time? All my opinion, of course: The time (cost) required to create such easily available introspection is too high for the comparatively small gains. REPLs in modern languages (when even implemented) are just so often a completely separate mode of operation.
  - mikelevins 9y ago
    The gains from Lisp-like support of live-environment programming are not small, but they are hard to communicate succinctly. The costs are real, but not onerous for a language designed to support such features. But a person designing and implementing programming-language tools has to deliberately choose to provide the needed features because implementing them after the fact raises the costs and lowers the benefits. That means such a person must believe that the gains are worth the cost. The only people likely to believe that are people already familiar with those kinds of systems.
    - auganov 9y ago
      On a fundamental level, there's not much difference between Lisps and any other language with real runtime eval. It's just that, say, in your average JS project you're going to have a lot of state all over the place, state that depends on side effects. I don't think Lisps do much to solve that. Clojure helps by discouraging state and side-effects, namespaces let you have everything sort of be a global in a manageable way. I actually like to use the 'repl' module in nodejs. With a little bit of effort, you can make the dev experience much easier.
wolfgke 9y ago
> Honestly curious why Lisp has so much admiration and praise on HN. Paul Graham and Robert Tappan Morris, two of the founders of YCombinator, love Lisp/Scheme. They got rich by selling their company Viaweb to Yahoo. You guessed it: Viaweb was written in LISP and Paul Graham believes that this was their secret weapon: > http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html Also the software that drives Hacker News is written in Arc, a Lisp dialect that was invented by Paul Graham. So Hacker News and YCombinator are indeed at least historically very attached to Lisp/Scheme.
- hbk 9y ago
  Also Y Combinator is a technique to do recursion on lambda calculus which lisp is built upon.
  - mbrodersen 9y ago
    Haskell (and other functional languages) is also built on the lambda calculus. Lisp isn't special in that regard.
- mattmanser 9y ago
  Which promptly got rewritten after pg left. EDIT: From the years being here, and having played with LISP myself, it's a language that appeals to a certain type of programmer, who claim to find it very productive compared to other languages. And everyone else hates it. So you pick a LISP language you're severely limiting your hire pool.
  - kamaal 9y ago
    The whole point of picking Lisp as a language for many people is to have a hiring pool of small but good programmers.
  - flavio81 9y ago
    >So you pick a LISP language you're severely limiting your hire pool. I'd rather have 5 very good Lisp programmers than 50 code monkeys.
TurboHaskal 9y ago
I second this, I actually find the whole s-expr thing a bit lacking, now that the Kool-aid faded off. Ultimately, what I really love are expression oriented languages, and the ALGOL/C and APL families have alternatives with a more succinct and expressive syntax (Perl, K). One might also argue that Scheme is a poor man's Forth.
agentultra 9y ago
Perhaps it has features that Python, Go, Node, and even Perl do not have. The reader is built in the same language as the rest of the compiler which means you can change it: you don't have to fork and compile a new version of a Lisp compiler to parse a completely different syntax or interpret a new kind of grammar. It has amazing error handling in its conditions and restarts system. It has the best OOP system I've ever used: being able to run the game I'm making, change a class definition of an entity and have all the live instances update while the program is running... is quite awesome. It's still one of the best developer-experience languages out there. The tooling is amazing. The fundamental structures underlying Lisp are quite solid. I like the distinction Phil Wadler makes: Lisp was discovered while languages like Python were invented. Everything in Lisp fits well together. Other languages in this vein are Haskell, SML, OCaml, etc. You can spot these languages because all of their features are usually built from the primitives of the language. An invented language forces the inventor to try and remember how a new feature may interact with all of the others... and sometimes it doesn't work out.
- kamaal 9y ago
  Perl 6 has hygienic macros, so you can count Perl out of that list. Also Perl 6 is written in itself.
segmondy 9y ago
If you find yourself in such a scenario, then you haven't reached the enlightenment level. Reaching for a "safe and familiar" procedural/imperative language is like most people reaching for a claw hammer when they wish to hammer and nail something in. To most people, it's the same, they are just hitting something. To a pro, they know when they reach for their claw hammer, a sledge hammer, a mallet, a ball pein, club hammer or cross and straight pein. If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you?
- dragonwriter 9y ago
  > If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you? Arguably, yes, most especially when several of them apply to the same process, rather than to separate pieces of data.
  - allthesethings 9y ago
    Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses. We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that. So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.
mikelevins 9y ago
Paul Graham is a Lisper and made his fortune with a Lisp application. Moreover, he wrote a widely-read essay claiming that Lisp was the secret weapon that enabled his startup to outcompete its rivals. In that context, it shouldn't be suprising to find sympathy for Lisp in discussions hosted by Paul Graham's firm. Lisp is quite practical for solving day-to-day problems, as long as you are a knowledgeable Lisper.
- mbrodersen 9y ago
  And 10000+ other people/companies have made fortunes using programming languages other than Lisp. So what's your point?
  - mikelevins 9y ago
    I was replying to submeta, who said: > Honestly curious why Lisp has so much admiration and praise on HN. So my point is that Paul Graham says Lisp was important in his success. His success was important in the creation of Y Combinator and therefore of Hacker News. So we should not be particularly surprised that readers of Hacker News include many that are favorably disposed toward Lisp. submeta also said: >But I would not think of Lisp when it comes to solving day to day problems. ...so I mentioned that Lisp is quite practical for day-to-day programming, if you know it well. For what it's worth, I've been using it for day-to-day programming for thirty years.
wglb 9y ago
Peter Norvig, a serious lisper, calls Python "an acceptable lisp": https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815
- lispm 9y ago
  If you read that post he actually didn't say that. He moved from Lisp to Pseudocode to Python for his co-written AI Book (AIMA). If you also look at the pseudocode or the python code, it's not very Lispy. Python more or less is used on a level of an object-oriented BASIC.
  - kamaal 9y ago
    https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common-Lisp-fix-the-world?share=1 https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common... In the above answer to a question in Quora, he seems to suggest that most of the features in lisp eventually got adopted in most other mainstream languages. Or in other words the concept of 'acceptable lisp'. I get what you are saying, and I feel the same way. But I think what people try to imply here- If you are using Lisp for a certain set of features, most of them are now available else where.
    - lispm 9y ago
      > Today, all those features, except for macros, are common in the popular languages. But not in the same language and/or less well integrated. Example: mostly no popular language has flexible macros as tightly integrated in the language as Lisp has. Those who have macros, either have a different view on macros and/or have them as preprocessing steps. You find very few languages with generic functions. There are lots of attempts to add them to languages like Java, but they are mostly experiments and not used. Similar for Common Lisp exception handling mechanism. Very few language have that. More direct influence languages like PERL6, Julia, R etc. look and feel very different from Common Lisp. Even if you think language have features like Clojure has a REPL - but it lacks the Lisp interpreter, the integrated error handling, the break loops, ... It's not the number of components, it's the integration. You can bolt wings to a ship, but the thing won't fly well.
flavio81 9y ago
>why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot Just consider that, while being a very beautiful language, Scheme is different to Common Lisp. If you are faced with doing a production system, you'll feel the benefits of Common Lisp, particularly now in 2018 where the tooling and libs are much better. Scheme can do everything that CL can do IF you add a ton of extensions and libraries and stick to a particular scheme implementation. So you would have a "custom" platform. Where as with plain-vanilla Common Lisp you would have all these features but in a totally standardized way.
RivieraKid 9y ago
I've been programming for 10+ years, tried many different languages and just don't get the appeal of Lisp. Swift for example is simply more productive and fun to use in most use cases. Same with Haskell. I don't believe PG's claim that Lisp made a significant difference in productivity for them.
- vzcx 9y ago
  How well do you know lisp?
  - RivieraKid 9y ago
    Hard to tell, not an expert, not a beginner. Enough to conclude that other languages are more productive for me.
- mbrodersen 9y ago
  I also don't believe PG's claim. I know Common Lisp, Scheme and Clojure well enough to be able to say that. Also, lots of people/companies made fortunes not using Lisp. So PG's claim proves nothing.
vzcx 9y ago
That depends heavily on what your day to day problems are. If you work in a complex or rapidly evolving domain, I cannot think of a better choice than Lisp. If you are doing a lot of text processing or writing CRUD apps, then you will probably not get much benefit.
- flavio81 9y ago
  >If you work in a complex or rapidly evolving domain, or if you are creating a big system that needs to work reliably and be able to be corrected (patched) while it's operating
mbrodersen 9y ago
I agree. I understand and have programmed in Common Lisp, Scheme and Clojure. And yes I fully understand macros. I even implemented Lisp style languages just for fun (using C++ and Haskell). But I never wanted to use it for production code.
- mbrodersen 9y ago
  Lisp seems to be optimum for team sizes of one. Maybe two or three if they are very "world view" compatible or have a dominant "alpha" dog. But using it for large scale development?
  - lispm 9y ago
    'One' seems to be false. You can program in teams with ten or in companies with hundred Lisp developers. Usually the team size does not need to be that large. Lucent for example developed a Lisp based network switch (similar to what Ericsson did later with Erlang) and they had around 100 developers. It was competing with a much larger team developing a similar product in C++. ITA had around 100 developers for their flight search in Lisp. Symbolics had at its height around 1000 employees and my guess would be that 40% were Lisp programmers. Personally I'd say there would be little problem working in a team with ten Lisp developers - you just have to find or educate them.

weavie 9y ago

We are getting to the stage now where a lot of languages are catching up with the features that lisp had in the 70's, so the huge benefits of lisp aren't quite as obvious as they used to be.

flavio81 9y ago
>so the huge benefits of lisp aren't quite as obvious as they used to be They still haven't caught up. I don't find any other language that gives at least 3 of these features - Fully interactive development -- i can recompile/redefine a function while the code is running - Fully interactive OOP development -- i can recompile/redefine a class while the code is running - OOP system based on multiple dispatch/multimethods - true metaprogramming done using the same language's syntax, not a special, cumbersome lib. - execution speed on par with the JVM and sometimes approaching C speed.

Jach 9y ago

Your confusion will go away once you recognize that Scheme is not Lisp. For most purposes, Lisp means Common Lisp, or one of the Lisps that ended up merging into Common Lisp. That means that Lisp does all of these things and more, which you might not expect if you've only seen Scheme/SICP: * Multi-paradigm programming (functional programming in the immutable sense is not dominant, the Lisp OOP system is top class, mutable state can be everywhere) * Rich looping mechanisms that don't require tail call contortions * Explicit typing that leads to optimized code and compile time warnings! (https://news.ycombinator.com/item?id=13389287 https://news.ycombinator.com/item?id=13389287) * Warnings at compile time (not run time!) about things like undefined functions/vars/wrong args/unused vars (https://news.ycombinator.com/item?id=14780381 https://news.ycombinator.com/item?id=14780381) * A pretty good set of libraries et al that (once you set up quicklisp) are just a function call away from trying out (https://notabug.org/CodyReichert/awesome-cl https://notabug.org/CodyReichert/awesome-cl) * (edit: one more since I like it a lot) Out of the box the Lisp system contains features you have to get from IDEs in other languages like breakpoints, tracing, inspection, code location questions like "who calls foo"... of course working with that system via emacs or something is nicer but it's basically all there in the base system (http://malisper.me/debugging-lisp-part-1-recompilation/ http://malisper.me/debugging-lisp-part-1-recompilation/)

firepoet 9y ago
To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language) https://en.wikipedia.org/wiki/Scheme_(programming_language)
- bjoli 9y ago
  Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.
  - kamaal 9y ago
    Lisp user base is so small enough that these categories largely look pointless to people outside. For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.
    - lispm 9y ago
      > For all practical purposes CL, Scheme, Clojure and Elisp are all lisps. Since only CL and Emacs Lisp can and do share actual Lisp code, I call only them Lisp for practical purposes. For 'unpractical' purposes - they share no source code but are influenced by practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.
      - kamaal 9y ago
        >>Since only CL and Emacs Lisp can and do share actual Lisp code But what exactly is 'actual lisp'. I mean what is this strict definition? Forgive me, I understand calling Scheme and CL as same might feel like saying Java and C++ as same. But one would be right in saying Java and C++ both come from a C based paradigm. On the same lines one could say CL and Scheme come from lisp paradigm. At this point in time both communities compared to any major language community are so small that one could refer to both as Lisp.
        9y ago

SlipperySlope 9y ago

Graham built a lisp shopping cart in the 1990s and sold it for funds that led to this website.

bjoli 9y ago

What made it click for me is the nature of scheme: a few, very well thought out abstractions, that compose well to build a really neat language. I never really made friends with other languages. Where scheme composes the primitives for problem solving, I find that languages like python or ruby provide either one way for each different thing, or a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with. The feeling I got when learning scheme was that of liberation. People have that epiphany all the time, but with different languages and techniques. For me it was scheme. And of course, I could never be bothered with syntax. If something becomes too verbose in scheme, I write a macro to simplify it. The only thing I need to know is whether something is a function or a macro. After 3 years of writing python on and off, I still manage to mess up syntax unless I think very hard before writing. I am however not a programmer, and of average intelligence. In fact I am on the very top of the bell curve, looking down on the rest of you.

jstimpfle 9y ago
> a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with. List comprehensions, to me, are what makes Python a productive (or the most productive) prototyping language. It allows me to think and program in mathematical relations without much fuss. Add to that nice sets and dicts (needed for asymptotic efficiency), and I can easily forgive it that it is built on an everything-is-an-object paradigm (there are few things I detest more than OOP). I've never truly understood why you need the meta-capabilities of LISP. I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing"). Macros amount to code generation. Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks. So far I've only ever generated a few C structs and enums, but I'm not sure it was an entirely good idea. It was super easy to generate from Python, anyway.
- segmondy 9y ago
  Code generation is great. If you have a well understood domain, Lisp macros allows you to construct an effective DSL so that your programmers no longer have to write "lisp code" but to program in the new language. We do this today using functions/methods, but the issue tends to be that besides understanding these functions, we need to learn how to orchestrate them and write boiler code all around them. A good DSL hides all that. The issue as I've observed is that when most people create a DSL, they really forget that they have indeed created a new language and don't document it enough. The consumers of the DSL because they can read lisp code, don't focus and live in the DSL layer but wish to peer below then get terrified when they see the macros. Most developers get terrified when they peer one level below. Have you seen the bytecode generated by python or asm code by C? Do you think those are bad because those are code generation that don't look the way you think they ought to?

Zak 9y ago

The OP lists several features Lisp had decades before they were common to find in more widely used languages, so some of it is for historical reasons. There are two things lisps, including Scheme and Clojure have that are weak or absent in most popular languages: One is macros. Being able to transform code before it is run using the language's built-in data structures provides a solution when the language just doesn't have the abstraction you need. Used properly, this can be invaluable. Used improperly, of course, it can make a mess. The other is REPL-driven development. Most languages have a REPL, but they don't really embrace it the way Lisp does. I find this frustrating. Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time?

falcolas 9y ago
> Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time? All my opinion, of course: The time (cost) required to create such easily available introspection is too high for the comparatively small gains. REPLs in modern languages (when even implemented) are just so often a completely separate mode of operation.
- mikelevins 9y ago
  The gains from Lisp-like support of live-environment programming are not small, but they are hard to communicate succinctly. The costs are real, but not onerous for a language designed to support such features. But a person designing and implementing programming-language tools has to deliberately choose to provide the needed features because implementing them after the fact raises the costs and lowers the benefits. That means such a person must believe that the gains are worth the cost. The only people likely to believe that are people already familiar with those kinds of systems.
  - auganov 9y ago
    On a fundamental level, there's not much difference between Lisps and any other language with real runtime eval. It's just that, say, in your average JS project you're going to have a lot of state all over the place, state that depends on side effects. I don't think Lisps do much to solve that. Clojure helps by discouraging state and side-effects, namespaces let you have everything sort of be a global in a manageable way. I actually like to use the 'repl' module in nodejs. With a little bit of effort, you can make the dev experience much easier.

wolfgke 9y ago

> Honestly curious why Lisp has so much admiration and praise on HN. Paul Graham and Robert Tappan Morris, two of the founders of YCombinator, love Lisp/Scheme. They got rich by selling their company Viaweb to Yahoo. You guessed it: Viaweb was written in LISP and Paul Graham believes that this was their secret weapon: > http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html Also the software that drives Hacker News is written in Arc, a Lisp dialect that was invented by Paul Graham. So Hacker News and YCombinator are indeed at least historically very attached to Lisp/Scheme.

hbk 9y ago
Also Y Combinator is a technique to do recursion on lambda calculus which lisp is built upon.
- mbrodersen 9y ago
  Haskell (and other functional languages) is also built on the lambda calculus. Lisp isn't special in that regard.
mattmanser 9y ago
Which promptly got rewritten after pg left. EDIT: From the years being here, and having played with LISP myself, it's a language that appeals to a certain type of programmer, who claim to find it very productive compared to other languages. And everyone else hates it. So you pick a LISP language you're severely limiting your hire pool.
- kamaal 9y ago
  The whole point of picking Lisp as a language for many people is to have a hiring pool of small but good programmers.
- flavio81 9y ago
  >So you pick a LISP language you're severely limiting your hire pool. I'd rather have 5 very good Lisp programmers than 50 code monkeys.

TurboHaskal 9y ago

I second this, I actually find the whole s-expr thing a bit lacking, now that the Kool-aid faded off. Ultimately, what I really love are expression oriented languages, and the ALGOL/C and APL families have alternatives with a more succinct and expressive syntax (Perl, K). One might also argue that Scheme is a poor man's Forth.

agentultra 9y ago

Perhaps it has features that Python, Go, Node, and even Perl do not have. The reader is built in the same language as the rest of the compiler which means you can change it: you don't have to fork and compile a new version of a Lisp compiler to parse a completely different syntax or interpret a new kind of grammar. It has amazing error handling in its conditions and restarts system. It has the best OOP system I've ever used: being able to run the game I'm making, change a class definition of an entity and have all the live instances update while the program is running... is quite awesome. It's still one of the best developer-experience languages out there. The tooling is amazing. The fundamental structures underlying Lisp are quite solid. I like the distinction Phil Wadler makes: Lisp was discovered while languages like Python were invented. Everything in Lisp fits well together. Other languages in this vein are Haskell, SML, OCaml, etc. You can spot these languages because all of their features are usually built from the primitives of the language. An invented language forces the inventor to try and remember how a new feature may interact with all of the others... and sometimes it doesn't work out.

kamaal 9y ago
Perl 6 has hygienic macros, so you can count Perl out of that list. Also Perl 6 is written in itself.

segmondy 9y ago

If you find yourself in such a scenario, then you haven't reached the enlightenment level. Reaching for a "safe and familiar" procedural/imperative language is like most people reaching for a claw hammer when they wish to hammer and nail something in. To most people, it's the same, they are just hitting something. To a pro, they know when they reach for their claw hammer, a sledge hammer, a mallet, a ball pein, club hammer or cross and straight pein. If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you?

dragonwriter 9y ago
> If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you? Arguably, yes, most especially when several of them apply to the same process, rather than to separate pieces of data.
- allthesethings 9y ago
  Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses. We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that. So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.

mikelevins 9y ago

Paul Graham is a Lisper and made his fortune with a Lisp application. Moreover, he wrote a widely-read essay claiming that Lisp was the secret weapon that enabled his startup to outcompete its rivals. In that context, it shouldn't be suprising to find sympathy for Lisp in discussions hosted by Paul Graham's firm. Lisp is quite practical for solving day-to-day problems, as long as you are a knowledgeable Lisper.

mbrodersen 9y ago
And 10000+ other people/companies have made fortunes using programming languages other than Lisp. So what's your point?
- mikelevins 9y ago
  I was replying to submeta, who said: > Honestly curious why Lisp has so much admiration and praise on HN. So my point is that Paul Graham says Lisp was important in his success. His success was important in the creation of Y Combinator and therefore of Hacker News. So we should not be particularly surprised that readers of Hacker News include many that are favorably disposed toward Lisp. submeta also said: >But I would not think of Lisp when it comes to solving day to day problems. ...so I mentioned that Lisp is quite practical for day-to-day programming, if you know it well. For what it's worth, I've been using it for day-to-day programming for thirty years.

wglb 9y ago

Peter Norvig, a serious lisper, calls Python "an acceptable lisp": https://news.ycombinator.com/item?id=1803815 https://news.ycombinator.com/item?id=1803815

lispm 9y ago
If you read that post he actually didn't say that. He moved from Lisp to Pseudocode to Python for his co-written AI Book (AIMA). If you also look at the pseudocode or the python code, it's not very Lispy. Python more or less is used on a level of an object-oriented BASIC.
- kamaal 9y ago
  https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common-Lisp-fix-the-world?share=1 https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common... In the above answer to a question in Quora, he seems to suggest that most of the features in lisp eventually got adopted in most other mainstream languages. Or in other words the concept of 'acceptable lisp'. I get what you are saying, and I feel the same way. But I think what people try to imply here- If you are using Lisp for a certain set of features, most of them are now available else where.
  - lispm 9y ago
    > Today, all those features, except for macros, are common in the popular languages. But not in the same language and/or less well integrated. Example: mostly no popular language has flexible macros as tightly integrated in the language as Lisp has. Those who have macros, either have a different view on macros and/or have them as preprocessing steps. You find very few languages with generic functions. There are lots of attempts to add them to languages like Java, but they are mostly experiments and not used. Similar for Common Lisp exception handling mechanism. Very few language have that. More direct influence languages like PERL6, Julia, R etc. look and feel very different from Common Lisp. Even if you think language have features like Clojure has a REPL - but it lacks the Lisp interpreter, the integrated error handling, the break loops, ... It's not the number of components, it's the integration. You can bolt wings to a ship, but the thing won't fly well.

flavio81 9y ago

>why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot Just consider that, while being a very beautiful language, Scheme is different to Common Lisp. If you are faced with doing a production system, you'll feel the benefits of Common Lisp, particularly now in 2018 where the tooling and libs are much better. Scheme can do everything that CL can do IF you add a ton of extensions and libraries and stick to a particular scheme implementation. So you would have a "custom" platform. Where as with plain-vanilla Common Lisp you would have all these features but in a totally standardized way.

RivieraKid 9y ago

I've been programming for 10+ years, tried many different languages and just don't get the appeal of Lisp. Swift for example is simply more productive and fun to use in most use cases. Same with Haskell. I don't believe PG's claim that Lisp made a significant difference in productivity for them.

vzcx 9y ago
How well do you know lisp?
- RivieraKid 9y ago
  Hard to tell, not an expert, not a beginner. Enough to conclude that other languages are more productive for me.
mbrodersen 9y ago
I also don't believe PG's claim. I know Common Lisp, Scheme and Clojure well enough to be able to say that. Also, lots of people/companies made fortunes not using Lisp. So PG's claim proves nothing.

vzcx 9y ago

That depends heavily on what your day to day problems are. If you work in a complex or rapidly evolving domain, I cannot think of a better choice than Lisp. If you are doing a lot of text processing or writing CRUD apps, then you will probably not get much benefit.

flavio81 9y ago
>If you work in a complex or rapidly evolving domain, or if you are creating a big system that needs to work reliably and be able to be corrected (patched) while it's operating

mbrodersen 9y ago

I agree. I understand and have programmed in Common Lisp, Scheme and Clojure. And yes I fully understand macros. I even implemented Lisp style languages just for fun (using C++ and Haskell). But I never wanted to use it for production code.

mbrodersen 9y ago
Lisp seems to be optimum for team sizes of one. Maybe two or three if they are very "world view" compatible or have a dominant "alpha" dog. But using it for large scale development?
- lispm 9y ago
  'One' seems to be false. You can program in teams with ten or in companies with hundred Lisp developers. Usually the team size does not need to be that large. Lucent for example developed a Lisp based network switch (similar to what Ericsson did later with Erlang) and they had around 100 developers. It was competing with a much larger team developing a similar product in C++. ITA had around 100 developers for their flight search in Lisp. Symbolics had at its height around 1000 employees and my guess would be that 40% were Lisp programmers. Personally I'd say there would be little problem working in a team with ten Lisp developers - you just have to find or educate them.