http://www.reddit.com/r/lisp/comments/cs94g/on_preferring_li...

Most programmers who achieve mastery in a fringe language find themselves having to justify their choice of tool to others. I think that poster did a good job in that regard.

Btw, Lisp vs Haskell debates can either lead to intellectually stimulating discussions, or they can devolve into a bum-fight. The decision that leads to the choice of either language over something more "popular" is the same: a quest for beauty and profound insight.

Then on top of all this is built on linked lists which are essentially an obsolete data structure in their simplest form.

There is no reason to learn something with backwards syntax and ancient tools when there isn't even any payoff. Write something in C and the program is fast, small, native and can be compiled anywhere in a fraction of a second. There is still a payoff for all the very real pain. In lisp there is just no reason to use it from any angle other than how clever someone can be with macros and that is the exact opposite of good sustainable programming.

How many times have you written a dozen lines of for-loop that could've been one map/reduce? How many times have you written a whole page of Object { this.foo = ... } just to add the simplest of new features?

Literally the reason I got out of programming after high school almost 15 years ago and wrote it off as 'not for me' was that kind of tedium, and learning Lisp and FP were the point in my return when I said 'Oh, wait, actually this is pretty great; where the hell was this when I was a kid?'

Lisp didn't take off because 1) home-computer-ready implementations were largely out of reach for three decades, and 2) Lisp and FP both were embracing the importance of expressive power during an era in which most programming still worshiped doing things the hardest way possible. Shit, when I was a kid, you weren't a 'real programmer' unless you did everything in assembly. Then it was C above all, to be followed by EnterpriseFactoryJavaFactoryFactories.

By the standards of most of the programming world, where there are still real bosses who grade coder performance in KLOC, Lisp is 'wrong'. But pumping out thousands of lines of repetitive boilerplate is not equal to efficiency, it just looks like it to a work culture that only understands output of work rather than quality of work. If programmer A takes 1 hour to solve the problem with 100 LOC, and programmer B thinks for 45 minutes and then solves the same problem with 4, who's the most efficient in that scenario?

And more to the point, which of those two work environments do you want to sign on for?

I think there's too much hand-waving going on to agree or disagree with the premise. Language popularity is notoriously fickle and driven by considerations that don't even earn a footnote in the OP.

For example, one of the most popular languages in the world today is Javascript, a language that owes a little of its heritage to Lisp and none at all to Haskell. Why is it eating Lisp's lunch and Haskell's lunch today? Because it ships as the default runtime for the most popular application in the world, the web browser.

Another language that has the same breadth of reach is PHP. Again, its popularity is due to the fact that it is a default runtime for most of the world's hosted web server platforms.

If we are to guess which language is going to gorge itself on everyone else's lunches in the future, I would suggest we spend our time thinking about which platform is going to be insanely popular and what new language might be its default runtime.

I'm not providing any fresh insight, of course:

Let's start by acknowledging one external factor that does affect the popularity of a programming language. To become popular, a programming language has to be the scripting language of a popular system. Fortran and Cobol were the scripting languages of early IBM mainframes. C was the scripting language of Unix, and so, later, was Perl. Tcl is the scripting language of Tk. Java and Javascript are intended to be the scripting languages of web browsers.

http://www.paulgraham.com/popular.html

Only worse languages win, because people are masochochists, but throwing away this possible user base is always a win.

In my opinion, most modern dynamically-typed languages are actually better than Common Lisp in almost all regards that matter for social, collective programming:

- they are usually much more functional and declarative: more immutability, more value-oriented approach (Erlang, Clojure), less unpredictable mutation, more useful abstractions built into the language. They provide modern data structures in standard libraries in a useful and uniform way.

- they provide a builtin class/object/prototype common language for their ecosystems (CLOS in Common Lisp and Moose in Perl 5 are examples of too flexible opt-in OOP systems that fragment ecosystems instead of unifying them); this also gives decent namespaces, which are crucial for cooperation between teams.

- they usually have a good async story (iterators/generators/coroutines, promises/futures, async/await), again, built into the language and enabling async ecosystems on top of them.

- they have good(-ish) story about package management. Lispers seem to like to write everything from scratch.

- they have good story about testing infrastructure. Lispers are usually too proud of keeping the world in their heads and of their REPL-driven bug-fixing dopamine cycle to actually think about having computer test their code. The ability to change a running program from the inside is actually a detriment to abstract thinking about what code is meant to do and describing that in more declarative invariants like type systems and tests.

- tooling has finally caught up: with LSP and treesitter, programmers do not have to bear the pain of S-expressions to have structural editing anymore. A sufficiently educated programmer recognizes syntax trees as a valid data structure in any language. If really needed, modern languages do provide abstractions to manipulate their AST (`import ast, dis` in Python, `erl_syntax` in Erlang, `ast` in Go, declarative and procedural macros in Rust, Template Haskell, etc).

The only thing which I think Common Lisp still does better is conditions/restarts, which seems a better way of error handling than just catching exceptions.

But it's probably everybody that is wrong, there is no way Python has a value proposal that is worth something to a lot of people.

I like the original article a lot, but what it failed to do for me is convince me why someone like me, a typical programmer, would want to choose Lisp over Python/Ruby/etc to solve a real world problem. Both Ruby and Python have powerful meta-programming abilities built into them. Lisp should be compared with these, not with C.

I still think that functional programming is extremely interesting (I'm in the long process of learning Haskell myself) and is useful is certain real world cases, but I was not convinced by this article. All the problems there are easily solved in modern and dynamic languages.

Lisp is a fascinating and very elegant language and every developer can learn something from it but I gave up waiting for the lisp revolution a while ago.

IIRC Richard Stallman also has a story about secretaries at MIT using Lisp for basically the same reason.

I think one issue that Common Lisp and many other programming languages face is that while a programmer’s time is more valuable than a machine’s, there are dynamics at play when maintaining commercial software projects that favor coding in more popular languages, such as the ability to easily hire developers knowledgeable in the language and/or paradigm. For example, imagine being a manager of a project written in Haskell that liberally uses functional programming concepts such as monads. It’s easier to hire developers knowledgeable in standard procedural or object-oriented programming languages than it is to find developers knowledgeable in functional programming, and getting a non-FP programmer up to speed on functional programming requires training, which takes time and money.

I love languages like Common Lisp, Scheme, and Smalltalk. However, if I’m working on a team project and my teammates don’t know these languages, then I choose a more common language like Python. Programming is more than just expressing computation; it’s also about communication, and one major purpose of language is to communicate with others.

I won't even be surprised if LISP has a market share of less than 0.01%. Even in the US. Do you have examples of popular system built using LISP?

If LISP was a big mainstream success there would be a huge literature on everything wrong with it, the same way everybody likes to bitch about Java.

I am deeply suspicious of explanations that boil down to, Lisp isn't popular because the average programmer isn't smart enough. Let me tell you, anyone smart enough to use C++ in anger is smart enough to use any language.

The real world is highly competitive, and organizations that think they can win by using niche languages, do. There's APL at Morgan Stanley, Ocaml at Jane Street Capital, K at Lehman's (OK, maybe that's not so good an example), F#, Haskell, blah blah. Lisp isn't even on the radar, anywhere. What does that tell you?

"Even C++ offers nearly everything that LISP does at this point; other than live code tree modification through macros, which aren’t anywhere near as powerful as C++’s algorithm and container library IMO, LISP has even lost the expression gap to C++ at this point."

As someone who has professionally been a C++ programmer and a lisp programmer, all I can do is laugh. The reason people like lisp is the basically infinitely mutable syntax we can build to fit specific target domains. It's still a radically different approach that most languages don't really touch. The only places I really see the "let's hack as a sub-language not as a framework" approach routinely is in the Ruby and Io communities.

Every C++ templating approach is a trivial macro hack. And macros get nearly all the benefits of C++ templates (including static analysis).

As for why lisp has been left behind in favor of other languages? Well, it's pretty much the same reason as why few people in America wear bowler hats these days, they're out of fashion. That's it. It's history, it's fashion, there isn't any good technical reason why! Most current lisp implementations are very competitive with their peers in most arenas. There are some social issues (the lisp communities are very fragmented, which makes it difficult for beginners to get traction).

It is true that stripped-down languages with almost no runtime features (e.g., C, C++ when you ignore dynamic_cast, etc) can produce "faster" code than lisp (meaning "does less with more lines of code, but executes quickly on modern hardware"), and that's good for them. But it's not like some kind of special privledge, _everyone_ uses C to bind into their language and make it fast. It's the native underpinnings of most modern operating systems, so this shouldn't be shocking.

Quoting again: "LISP is dead. If you really need a LISP, move to a modern LISP such as Clojure or Scala, or a modern near-lisp like Ruby. You’ll learn a lot about what LISP had kept from you."

I get the strong impression that this author doesn't like lisp (he probably knows it to some degree, but not well enough to really grok it). He freely and interchangeably mentions Scala, Ruby and Clojure as "replacements" to lisp. Clojure aside, mentioning Scala and Ruby in this way is ludicrous, and betrays a sore lack of insight into what lisp is and what the current state of lisp technology is. Anyone who looks at PLT Scheme and SBCL and doesn't see a fairly modern and powerful system (in PLT Scheme's case with some practical and interesting work on contract-based programming), then they're deliberately not looking.