Hacker News Reader

Comment by brlewis | Hacker News Reader

There are many hypotheses out there that Lisp lacks popularity for this or that flaw in the language or in the community. The problem with these hypotheses is that you can point to similar or bigger flaws in languages that have grown popular. If a language has good qualities, people will figure out ways around the problems.

My hypothesis is that Lisp is unpopular for the exact same reason some of us love it: concise code. Everybody praises concise code, but humans love looking at things that have repeated patterns. The more you compress information, the fewer repeated patterns there are to look at.

I wish PG well with Arc, but I don't think popularity will come from fixing anything that's wrong with Lisp. By my hypothesis, Lisp only becomes popular by fixing what's right with it.

View on HN

I'll throw in my 2 cents... Up until recently, one "flaw" that Lisp had that other languages didn't was one obvious best implementation. If you want to work in Perl, Python, Java, Ruby, etc. you knew where to get them, and you know they would work similarly across platforms, so programs you wrote on your Mac would work on Windows and Linux, etc. With Lisp, different implementations did the "interesting" stuff (threads, sockets, FFI, etc.) differently, and hackers didn't want to invest time learning one implementation if everyone else decided that a different one was the best. No one wants to bet on the loser (Blu-Ray vs. HD-DVD), so they stay away until a clear winner emerges. It looks like SBCL is becoming that best implementation, and once threads work on Windows so the web frameworks will "work", that will help greatly.

Another barrier is having to learn emacs/SLIME to have a decent development environment. That is a big piece of yak shaving for the average developer. Hopefully Cusp in Eclipse or something else will help.

Tell me, where's the clear winner between ruby and python? Between python and PHP? Between PHP and Perl? Between OCAML and Haskell? Plenty of languages have managed to rise in popularity through a time when you didn't know if any of your code might run on the future winner. At least with Lisp implementations you know some of your code will work with the winner. "Waiting for a clear winner" is not a reason for Lisp not to grow in popularity.

Perl, PHP, Python, Ruby -- none of these emerged from the womb with a full-grown development environment. They managed to grow to the point where people wrote Eclipse plugins or what have you. Lack of a "mainstream" development environment is not a reason for Lisp not to grow in popularity.

Unless you're implying that each Lisp interpreter is its own language, I don't think your contention really applies. If I learn Lisp on Lispworks, and go sit down at GNU CLisp, I'm not programming in a different language - I'm using a different sub-set thereof. When I sit down to a Ruby program, and then switch to a PHP script - there are fundamental differences between the two languages that transcend the library or features either provides.

Ralphc's point wasn't about there being a clear winner in the dynamic language space, but that each of the languages mentioned had one canonical interpreter.

The issue here is human decisions, not a taxonomy of programming tools. Or do you suggest that Lisp dialects diverge further? If you called them separate languages, would there be a better chance of them growing popular?

On the contrary, I'm suggesting that Lisp dialects do not diverge as far from each other as the various dynamic languages do. That means that the idiosyncrasies each dialect has are going to be more glaring. The other dynamic languages don't (yet) have dialects, so you don't have to take the design decisions of the interpreter into consideration - after you've decided on the language.

In that case, I think that there might be a better chance of a sub-set of Lisp dialects becoming popular if they were described as separate languages. It will be interesting to see how Arc develops from MzScheme, and whether or not it becomes more popular with non-Lispers.

Perl, PHP, Python, and Ruby are all interesting failures. They are important for their effect on languages that will last longer (Lisp, ECMAScript) though.

Edit: I don't mean these are "failures" now, just that they're doomed in the long run. Does anyone think they'll be able to stand any of these languages in 2018? I don't they'll have evolved much by that point either. The older a language gets, the harder it is for it to evolve. And if it tries to make too big a leap, people simply don't go for it (PHP5, Perl 6).

Like it or not, I don't think you can call any of those languages failures. Certainly not PHP, Python, or Ruby. I would venture to guess that all three are more commonly used than Lisp.

Failure in the Grahammian sense of being a dead-end.

"I think that, like species, languages will form evolutionary trees, with dead-ends branching off all over. We can see this happening already. Cobol, for all its sometime popularity, does not seem to have any intellectual descendants. It is an evolutionary dead-end-- a Neanderthal language." - http://www.paulgraham.com/hundred.html

Though I disagree with most of the conclusions in that essay, and in particular the expectation that Lisp (or a direct descendant) is going to be the language of the future, I still think it's way too early to call the above languages failures, even in the "Grahammiam" sense.

Python and Ruby especially are growing in popularity, and I think it's awfully premature to consider them evolutionary dead ends at this stage in the game.

I don't necessarily agree that those languages are dead either. I was just clarifying the point I thought he was trying to make. Plus I wanted to turn pg into an adjective :)

I mean failure like the tyrannosaurus rex. That is, from an an evolutionary perspective. Not at the arbitrary present. And I'd wager that Perl is still actually more used than Python or Ruby, it just doesn't get the love on social news sites and elite blogs.

I think Perl has been relegated to short scripts and legacy code bases. I don't see a lot of new projects being developed in Perl. That's what I meant by leaving it off the list.

I really don't find that lisp, at least common lisp, is particularly concise. Consider lambda functions, one of those things that lisp is particularly praised for;

   common lisp: (lambda (x) (+ x 1))
   C#3        : x=> x + 1
   ruby       : { |x| x + 1 }
   python     : lambda x: x + 1
   Haskell    : \x -> x + 1

Just in terms of character count, CL is the longest of the lot.

No, the problem with trying to get a lisp under your belt has alredy been mentioned. Compared to the alternatives;

- choosing an implementation is a research project (clisp? sbcl? allegro?) - documentation is weaker - libraries are harder to find and install (ASDF vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn - examples are few and far between - the language itself (the words, not the punctuation) is inelegant (mapcar, setq, cdadr)

I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark.

You can shorten (+ x 1) to (1+ x), and if you get annoyed typing "lambda", it's not that hard to change it to something shorter like "fn". Also, CL has a lot of built-ins so I don't find I need to write lambdas nearly as often as in other languages. In this example, just say "1+".

Another thing you'll find is that for trivial problems, Lisp might take a few extra characters, but it scales much better. Try making your Python lambda print the value of x first. Try telling your Ruby lambda that x (and x+1) fits in a machine word so it can compile the function into only a couple of CPU instructions. Try writing a metacircular evaluator in C#. :-)

When you're just getting started, in any language, it doesn't really matter which implementation you pick. (FWIW, CLISP is byte-compiled, SBCL is a native compiler, and Allegro costs $600. Not unique to Lisp: you can find expensive proprietary C++ compilers, too.)

As a Lisp and Ruby programmer, I disagree that Lisp's documentation is weak. I would be very happy if Ruby's docs were even half as good as Lisp's.

I type "sudo apt-get install library-name" for both Lisp and Python libraries, so no difference there. (Ruby gems are less frequently packaged, and aren't compatible with the FHS, so they're a little harder.)

Lisp examples seem to be more often found in (dead tree) books, while Ruby and Python examples are more often found on the web. Since Ruby and Python libraries (and even syntax) are still in flux, and Lisp predates the web, this kind of makes sense. If you can't buy a couple books, it can be rough, though some good Lisp books are becoming available on the web for free.

Those symbols you picked are a little weird, but when's the last time you actually saw a cdadr? It is at least consistent (which is more than can be said for some languages!). I don't find "unshift" or "__gt__" any better.

I don't want to sound like a pure apologist. I admit that Slime is an investment (if you don't already know Emacs). Apparently there is a Lisp plugin for Eclipse, but I know nothing about it. It is a shame more IDEs don't support Lisp well, though I can see why they don't.

Finally, it could be simply that Lisp doesn't map well to your mind. (I don't mean this as an insult -- everybody's different. Maybe Smalltalk or Prolog or Sisal is your cup of tea.) I don't think Ruby maps well to mine, though I know some people who seem like Matz reincarnate -- which could explain why the docs are so sparse! The core of programming, to me, is having fun building good abstractions, and if Lisp isn't doing it for you, by all means, find (or invent!) something that does. Cheers!

Hi, Ken. Thanks for the reply.

I think what's happening currently in programming is that lisp-isms are filtering through to other languages. What used to be unique lisp-juice is available more generally, so the switch to lisp isn't perhaps as compelling.

Anyway. I'm off to write that metacircular evaluator in c# ;)

In my experience, Common Lisp often doesn't come out best at the code snippet level. Where it shines is in building whole systems. After a while one passes an inflection point where one realizes, "Holy cow - what I'm doing now is supposed to be way harder than it is". I probably have this experience every week.

You obviously put a lot of sincere effort into learning Lisp and I agree with much of what you say. After all that work, I wish I knew an easy way to communicate the joyful side to you.

The best demonstration of that "big system" effect that I've seen, that's easy and small enough to read and comprehend, is the database[1] or unit testing[2] chapters in Practical Common Lisp. They show good examples of using macros and HOFs to completely remove boilerplate code, and that it's simple enough to do it for even simple boilerplate.

[1] http://www.gigamonkeys.com/book/practical-a-simple-database....

[2] http://www.gigamonkeys.com/book/practical-building-a-unit-te...

Unfortunately that is not really what people mean with "big system" - although I do agree with your point. It shows how nice it can be when you add on complexity.

I really should get that book in paper form.

Yeah, but the bigger the system, the harder it is to create a non-IP protected, easily digestible example.

Which means you have to rely on he said/she said, hearsay and other totally non objective accounts.

To find out for myself, I plan on one day doing something large and messy with arc. I pick arc cause I figure in the eons it will be before I get around to it, arc will still be around (s/arc/a lisp/)

It may well be that it only really becomes apparent on larger projects. It's hard to get to that point, though, and maybe that's why the takeup is low.

OTOH, some languages are particularly good on small things, but don't offer much help for large problems.

Just out of curiosity, did you like working in Lisp? I mean, if you can abstract away from the annoyances you cited, did you actually enjoy the Lisp mode of programming (basically, writing syntax trees)?

I did, and I didn't.

The "I did": It seems very sensible to use s-expressions for everything. That lispy syntax meant that I started seeing ways to encode almost everything as lisp. I even started keeping a todo list in s-expressions;

(do (buy bread) (tidy (kitchen living-room bathroom)) (get life))

The classic XKCD cartoon had it perfectly: "I felt a great enlightment. I saw the naked structure of Lisp code unfold before me. The patterns and metapatterns danced. Syntax faded"

I didn't: when it came to actual common lisp, cracks started to appear. The crazy mini-language for looping. The arbitrary-sounding names. The feeling that, if I ever wanted to do anything remotely windows-specific I would face years of horror.

I've blooged about it more at http://www.stevecooper.org/2008/02/13/impractical-uncommon-l..., if you've got too much free time. ;)

I read your post. So, you appreciated the core beauty of the thing but the details got you down. What a shame.

I think what happens to most of us who love Lisp is that, at a certain point, the initial frustrations are eclipsed by how much more productive we are (and liberated, if I may put it that way). That point comes sooner for some than others. In your case, not soon enough. But Lisp will no doubt still be around if you ever do decide to get back to it.

i never really touched lisp until Arc. i knew lisp was the language i wanted to be programming in, but common lisp feels mainframey and scheme has an ivory-tower anal aura about it

once Arc gets its own independent implementation i will probably start using it more heavily and seriously

> - choosing an implementation is a research project (clisp? sbcl? allegro?) - documentation is weaker - libraries are harder to find and install (ASDF vs Rubygems, Python eggs, etc.) - emacs/slime is an investment to learn - examples are few and far between - the language itself (the words, not the punctuation) is inelegant (mapcar, setq, cdadr)

- Exactly.

Last year I started reading about Lisp etc, and wanted to play with it a little bit.

These are the exact same obstacles I faced.

If you ask about "IDEs" for Lisp, you're met with downright hostility for not embracing the glory of emacs with open arms - anything else is just unfathomable.

Well, what if I'd like to just, you know, start using the language, and not learn a whole new world of an editor first?

"Why does emacs + SLIME have to be the only viable option?"

That's not a question you can ask, of course, but the answer would be something like "roll your own" anytime you need anything.

(Oh, and Xach is a prick. He and Krysztov(or whatever) are practically high-fiving each other on IRC every time they alienate another new would-be Lisper)

As for the implementation research, I sort of came to the conclusion that SBCL was the way to go, but documentation (for anything?) was pretty scarce, and ASDF feels like an obstacle too.

Later on, I realized that Scheme is more elegant as a language, but it's more or less in the same situation as CL.

Compared to these two, something like Python feels much more accessible to me (being a novice at all), because I get the feeling that I can just start using things whenever I want to make that effort.

But that's just it - with Python, there's only the effort of learning the language as you use it.

You learn the standard library as you go, and suddenly you notice you've accomplished a lot of things and had fun while at it.

- At least that's how I imagine it will be when I get around to working on my own super-secret web-startupy project.

With Lisps, you need to make a lot of effort just to get to the beginning, and that's a big problem.

Clozure Associates has an open source Common Lisp with an IDE for Mac OS X. We're also working on the documentation. We're specifically working to remove the speed bumps for new Lispers. Check out http://www.clozure.com/clozurecl.html. We plan to have IDEs for other OSes too in the future.

You can use CUSP (an Eclipse plugin which provides similar functionality to SLIME for EMACS), and the commercial impls have their own (admittedly EMACS-esque) IDEs. There's even a SLIME-derived plugin for vi! It really is worth the effort to learn EMACS, though.

I'm unconvinced that installing lisp libraries is so very horrible; I've had far more trouble with python ones, myself.

I even tried CUSP back then, but it was somehow confusing (or refused to work), I don't remember.

Maybe it's because I don't normally use Eclipse.

If someone is interested in other alternatives, here's one: http://phil.nullable.eu/

- Phil's "ABLE" editor. I tried it too, but it didn't work too well on Windows (something about CLISP, iirc).

m-x slime (starts slime and sbcl) c-x-2 (split window in two; one for coding one for REPL)

..open a file at the top window by pressing c-x-f and typing in hello-world.lisp <enter>

..yay, start coding..

c-c-c to eval forms c-c-k to eval/compile the entire file q to close down "popups" (exceptions .. etc.)

yawn .. what's the problem? .. are somewhat, "limited"?

"I've tried really hard to learn lisp, and it turns out that actually, while there may be some platonic lisp that IS great, actually programming common lisp, now, is a massive effort in struggling in the dark."

The weedout process has worked its magic again ;P

You usually get rewards proportional to the effort... I don't think lisp is beyond anyone's reach if they work faithfully on gaining proficiency in it for 3 months, maximum. 3 months is nothing if it makes you a much better programmer, and/or you get to use this awesome language.

I think it's important to first research lisp's benefits. Of course you won't be willing to spend the necessary efforts if you're not convinced... I know I just couldn't resist the appeal of closures, macros, CLOS (multiple inheritence, multimethods, class redefinitions) the condition system (restarts in particular), generalized variables and a bunch of other fun stuff.

"The weedout process has worked its magic again ;P"

Please don't call me a weed.

You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp.

Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions.

The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl.

"Please don't call me a weed."

Sorry :(

"You point out that the more effort you expend, the better you get. The problem is the rate of reward. Getting a productive lisp environment is hard work. Competing implementations, sometimes-compatible libraries, very little documentation -- these are things that make lisp, holistically, hard to adopt. Every other production language makes it easier to get to the programming. I can't think of a worse-supported production language than lisp."

I agree.

"Also, the benefits you mention are either not that uncommon, or that valuable. The only thing lisp has as a unique feature is it's macro system, thanks to it's syntax. It's the only thing that can't be adapted straight into another language. Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions."

Well, it's uncommon and valuable to have all of them in a coherent language. Especially since they're pretty orthogonal features that complement eachother well. The whole is greater than the sum of its parts.

"The thing is, I wanted to believe. I stocked up my library with PCL, SICP, the little schemer, and On Lisp. I learned emacs. I stuggled with asdf. What I found, though, did not seem to live up to the promise of a hidden pearl."

I'm sorry that you've come to the conclusion lisp is not right for you. Maybe in a couple years you can try again and most implementation/library/documentation/etc issues will be resolved?

"Sorry :("

Nah, that's ok. ;) CL isn't really for me, now. As I said, common lisp, right now, is too much work. Who knows what Arc 2020 will be like? ;)

"Otherwise, the features you mentioned are basically available elsewhere; Visual Basic has closures. C++ has multiple inheritance. Python has multimethods. Ruby has class redefinitions."

Exactly. Common Lisp is close to a superset of the features of other programming languages.

Even in cases where Common Lisp lacks a feature, if it's something that can be expressed by changing syntax, macros can get you pretty close. I remember a thread on comp.lang.lisp where several people had a go at adding pattern matching to Common Lisp, for example, and were able to get a pretty long way towards that goal in a short amount of time. Another example: seems like half of the Lisp books out there present an implementation of Prolog in Lisp.

According to Larry Wall:

"use Lingua::Perligata;

If you allow a language to mutate its own grammar within a lexical scope, how do you keep track of that cleanly? Perl 5 discovered one really bad way to do it, namely source filters, but even so we ended up with Perl dialects such as Perligata and Klingon. What would it be like if we actually did it right?

Doing it right involves treating the evolution of the language as a pragmatic scope, or as a set of pragmatic scopes. You have to be able to name your dialect, kind of like a URL, so there needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like. This is actually near the heart of the vision for Perl 6. We don't see Perl 6 as a single language, but as the root for a family of related languages. As a family, there are shared cultural values that can be passed back and forth among sibling languages as well as to the descendants."

I'd say Perl is getting comparable macro-level functionality. Perl also has one likable feature that is less present in lisp; different idioms look different. When I hear Paul Graham talk of (a i) being an array index or a function call, I start to think about concepts like Hungarian notation to keep my code more readable.

A uniform syntax structure isn't required for macros.

> "so there needs to be a universal root language, and ways of warping that universal root language into whatever dialect you like."

sounds like XML

> "A uniform syntax structure isn't required for macros."

it makes it a lot easier!

i don't understand what you mean by 'pragmatic scopes.' does perl 6 have macro functionality?

I would take 3 months to learn a new language, but then my startup would be dead.

I picked up Python in a day. I'm quite proficient at it a year later. A simple syntax + a great standard library is the best way to get things done, if not the best way to learn to write software.

Make it: 3 months full time, plus whatever amount of time is needed to become deeply conversant with all the underlying lambda calculus concepts.

You're saying nobody can become proficient (not "deeply conversant") in lisp in 3 months because I can't become deeply conversant in lambda calculus in 3 months?!

nobody, proficient, lisp. I, deeply conversant, lambda calculus. You're comparing apples and oranges.

I learned lisp (pretty deeply, I'd qualify myself as intermediate then and now) in what... 5 or 6 months? And I was alone. And I didn't know emacs. With some coaching and pointers I'm pretty sure I could have made it in 4. Aren't you happy?

Well, we have 2 data points now. I guess we can agree that it's harder to learn than Python :-)

For what it's worth, I think learning Lisp is useful for getting (re)acquainted with lambda calculus if nothing else.

lisp doesn't strike me as a difficult-to-learn language. it actually seems the easiest of them all, definitely not harder than python to pick up. c++ is at the other end

Reply on news.ycombinator.com