Hacker News Reader

There's no one lisp; there are many. Here are the top three:

Clojure: http://clojure.org/getting_started

Racket: http://docs.racket-lang.org/getting-started/

Common Lisp: https://www.quicklisp.org/beta/

Lisp is a family of languages. All the dialects are good in their own way - "standardization", if such a thing even makes sense, would be counter-productive.

The history of Haskell is described in this PDF: http://research.microsoft.com/en-us/um/people/simonpj/papers...

This paper describes the situation in the mid-1980s as a "lazy Tower of Babel" with competing lazy-functional languages like Miranda, MLs, Orwell, Clean, Ponder, each good in its own way, but none of them with critical mass. Thus they decided to create Haskell as a new, common language. No doubt each language designer felt that Haskell compromised on their particular vision, but rallied around it anyways, resulting in a far more potent force for lazy functional programming than ever could have been achieved working separately.

Why does this not describe LISP today? Honest question.

Lisp thrives in Babel, while the other kinds of languages may be harmed by it. Lisp is a meta-language and it facilitates building a Babel tower of eDSLs for each and every little project. It is the main source of its unmatched power.

But this doesn't require the proliferation of implementations. Each little project doesn't require its own garbage collector, for example.

The paper I linked discusses some of the "practical" areas of Haskell: profiling, debugging, packaging, FFI, compiler errors and optimizations, etc. Surely there's a lot of energy being expended replicating this stuff across the various Lisp implementations?

There happens to be wide community consensus around a single Haskell compiler, GHC, at the moment, but that's a contingency and there are some other compilers, interpreters, and stuff like GHCJS. Profiling and debugging support is a feature of GHC (and other implementations), not of the language standard.

Common Lisp has unified packaging and FFI and stuff through various community projects like ASDF and Quicklisp.

If you're talking about Lisp in the general vague sense of "Lisps" then there can't be general interoperability because that umbrella term covers lots of very different languages with no formal common ground.

There aren't that many Lisp implementations, especially those that are considered to be mature and ready for production.

For Common Lisp, the open source ones are SBCL and Clozure CL, and the proprietary ones are Allegro CL and LispWorks.

For Scheme, there are Racket (PLT Scheme), Chicken Scheme, and Guile.

I'm quite certain that the majority of people who use Common Lisp and/or Scheme use one of the aforementioned implementations.

Even GC cannot be a common ground for everything. Take a look at Harlan, a Lisp-like language with a region-based memory management. Unification harms diversity and flexibility.

It describes Common Lisp.

Scheme is another language with its own common standards.

The way people are so quick to talk about "Lisp" as a general meta-language is kind of confusing.

We could invent a definition by which Ruby, Python, and Perl are "really the same language" that just failed to standardize, but that would be obviously silly.

You could say Ruby, Python, Perl, C, Java, etc are really ALGOL-like languages whose data structures are generally mutable, and whose syntax is made for expressing how the state of the program is mutated in-place.

Whereas LISP-like languages have data structures that are generally immutable, and whose functional orientation results in expressing the computation of new data from old (mostly) without mutating in-place.

The thing about imperative programming languages is that the paradigm matches up to the mental model of "a computer" that most programmers would recognize and find comfortable. Without having any concrete evidence, I have a hunch that this paradigm difference is what deters new developers the most. And stacked on top of that you have the non-ALGOL syntax and the lack of libraries.

In my opinion, anyway.

Your opinion is about an idea of Lisp that's simply not true. Both Common Lisp and Scheme are pervasively mutable and imperative constructs occur just as often as in "Algol." Clojure diverges from this with its nice immutable data structures, but that's a rather novel and distinguishing feature, not a core trait of "Lisp."

I'm curious about where the idea originated that Lisp is an especially non-mutating language. Some of it is just that it's a garbage collected language with first class functions, so it's easy to classify it as "functional" which has associations to "pure functional." But Lisp is very far from a pure functional language. It's more like a general multi-paradigm language—like Perl and Ruby.

Common Lisp _IS_ the consolidation of various Lisp dialects that you've asked about.

Back in the 70s and 80s there are numerous Lisp dialects (way, _way_ more then there are today, since each dialects has their own sub-dialect and so forth), and so Common Lisp was created back in the 80s (the work started in 1981 and finished in 1994) to unified various Lisp dialects into one common language.

And Common Lisp accomplishes that objective, well mostly anyway. Soon(-ish) most people, companies, and institutions ported their Lisp code base to Common Lisp, and by the late 80's and early 90's, when you say Lisp most people will (correctly) assume that you mean Common Lisp, not MacLisp or InterLisp, or some earlier, long depreciated dialects.

You can read more about the nitty gritty details in the Evolution of Lisp essay by Richard Gabriel here: http://www.dreamsongs.com/Essays.html

Now, about Scheme. Remember when I said that Common Lisp _mostly_ accomplishes its objective of unifying various Lisp dialects? Yeah, basically the Scheme community didn't like how Common Lisp turns out, so they decided to stick with Scheme. And it is understandable why they feel this way, because despite outward appearance, the two languages are very different, with Scheme focuses on small (and mathematically elegant) core language, while Common Lisp, with its focus on being practical, is a huge language with a standard library that includes everything and a kitchen sink. Scheme also has a totally different evaluation model compared to Common Lisp and its own macro system with emphasis on hygienic. Not to mention that Scheme has its own standard, the R*RS (now in its 6th revision, with 7th in the drafting process).

Now, the thing about Common Lisp is that it is very hard, if not downright impossible, to change its standard. This means that it is not easy to make a substantial changes to the language and has the wider community adopt it (and we haven't even talk about changes that will break backward compatibility here). This is one of the reason that Rich Hickey created Clojure as an entirely new Lisp dialect (before this, he had implemented a Java FFI for Common Lisp). Clojure has a new syntax that is far more consistent than Common Lisp (which comes at the cost of breaking backward compatibility), as well as many new and experimental features, such as immutability, asynchronous operations, and the focus on functional programming style. All of these would be very hard to introduce into Common Lisp without significant efforts and time.

Excellent historical summary!

> Scheme focuses on small (and mathematically elegant) core language, while Common Lisp, with its focus on being practical

I don't think it's really fair to say modern Schemes aren't focused on being practical. Nor that they're small.

Take a look at Chicken or Racket, and you'll see that they have quite substantial libraries and many features above and beyond the specs that make them much more practical than the core Scheme spec alone.

Quite beside that, there's also the new R7RS[1] spec's "large" language is just that: large. It's also focused on being practical. So I wouldn't say that the traditional Scheme vs CL divisions in terms of size and practicality still hold.

I would say that Scheme is more elegant than CL, and more modern, and less crufty. Unfortunately, there are still far more programmers using CL than Scheme. Hopefully with Emacs' move to Guile that will change.

That said, I still love CL, and would far rather use it than any other language, except Scheme.

[1] - http://trac.sacrideo.us/wg/raw-attachment/wiki/WikiStart/r7r...

I would include Guile in this list of lisps :)

This is spot on for me. I actually have used lisp in one large project but I haven't used it since. It wasn't my choice then and the guy who's choice it was was a total lisp guru. I don't have his chops. I did enjoy parts of it but not enough to switch

The biggest issue for me vs other options is lack of community / packages

Pick Python, JavaScipt, even Perl and there's millions of solutions to pick from so you can get shit done. Maybe that stuff exists for lisp but I'm unaware of it.

If there was a popular lisp with something like npm, easy integration with non lisp libraries I might consider it.

There's also the issue of perf. The lisp I used was optimized for generating machine code for games. My understanding is most lisps don't perform at that level. Of course as a replacement for Python, perl, JavaScript that's not an issue. But it would be for C/C++ for games

Another issue is finding collaborators.

The easiest Lisp I would recommend is probably Racket, it is what got me into Lisp personally. After that I would give Clojure a shot, it has some amazing tools like lein.

I think first time setup is a huge key for programming languages. For example Go has the benefit of an amazing out of the box standard library, unlike D and Ruby where you would install via a package manager the right tools to get a web project going, you could do it all from vanilla Go code.

Of course in both Ruby and D you could do it from vanilla code, but it's not as seamless and tried and tested I suppose?

If you are reading SICP or want to, Racket is also a good choice here. I bounced between SICP and The Little Schemer with Racket. I didn't use the SICP language until later on but I found that Rackets documentation was so good that it was pretty easy to fill in any blanks.

All in all, that experience was useful to me to both learn Scheme, learn core concepts, such as recursion, higher order functions, closures and so on whilst also paving a familiarity that has aided in quickly picking up CL, Clojure and also, in my opinion, Haskell.

I would recommend Racket whole heartedly.

> Clojure is surely the best known modern LISP, but I do not want to depend on the JVM.

Why don't you want to depend on the JVM?

You are deliberate ignoring the most well known modern lisp, which has straightforward installation, great tooling, and lots of support available.

Not to mention the JVM is one of the most powerful and highly optimised vm platforms and has hundreds of thousands of man years invested in high quality libraries.

> Speaking as an outsider, I think LISP would gain a lot more traction if its community coalesced around a single implementation

And surely they would focus around a JVM implementation. The only other platforms that even come close are c/c++, and the .net clr.

> (Clojure is surely the best known modern LISP, but I do not want to depend on the JVM.)

What are the reasons you don't want to depend on the JVM that don't apply doubly so to Common Lisp?

All the modern lisps are installed just like anything else, whith apt-get install. I've no idea what are you talking about.

Usually apt-get doesn't feature the most recent up to date release, also you assume everyone uses a Debian derived distribution of Linux, bad assumption. I'm on openSUSE and I'm sure many are on Windows or Mac.

I meant "apt-get" or whatever else is used in your system - brew, yum, whatever.

If you need the absolute most recent release of a language to write code in it, that in my opinion is a bad sign -- maybe it's still a bit new and evolving rapidly, if there's a runtime component it might be awkward to distribute to machines you want to run on, and setting the dev environment up becomes a little painful which can discourage others from contributing. Not a dealbreaker, especially if you're just experimenting or doing a small private project, but for anything serious I would be worried if I couldn't develop and run it with whatever version of a language is shipped with the major Linux distros.

I'm on about it being behind 2 or more major versions.

I don't know if this is still the case, but for SBCL on Debian installing with apt-get would get you an incredibly outdated version, and all that common-lisp-controller nonsense. The standard advice was NOT to install with apt-get, but to install manually.

> (shiver)

Nice "syntactical" touch :)

Let me try a variation:

(shiver 'me 'timbers)

You can run Clojure on Node if you prefer. That's what I'm doing in a current project.