M-J Dominus: “Why Lisp Won’t Win” — Still Applicable?

Mark-Jason Dominus on “why lisp won’t win”:

Here’s the real reason why Lisp won’t win. The Lisp programmers don’t want it to win. They’re always complaining that not enough people are using Lisp, and that Lisp isn’t popular. But they humiliate and insult newcomers whenever they appear in the group. (The group regulars would no doubt respond to this that the newcomers deserve this, because they’re so stupid and argumentative.) If Lisp did become popular, it would be the worst nightmare of the comp.lang.lisp people.


This is from 2003. Now in 2005 there exist things like Practical Common Lisp, which seems to be all of the lisp and none of the attitude.

And we have Reddit.com, where — I counted — one fifth of the current stories on the front page are about Lisp or Scheme, some of them very old stuff (the classic Scheme textbooks, “How To Design Programs” and even more classic, “Structure and Interpretation of Computer Programs,” are both front page items as I write this.)

Could it be that there has been some kind of transformation in the last year or two in the classic Lisper attitude?

Is it just me or is there a crazy huge Lisp buzz these days? It could just be that I read Reddit a lot and it’s run on lisp and backed by Paul “Lispmonster” Graham.

BTW, I found “Why Lisp Won’t Win” on Reddit’s new page. It was one of two further lisp links that hadn’t yet been promoted to the front page. (The other was this one.

I’m betting those will shoot to the front page too soon. Lisp posting seems to be as easy a formula for Reddit popularity as Microsoft bashing has classically been for Slashdot popularity.

Ruby Adequately Lispy?

I wrote a little while ago that “I have a feeling that in terms of the ‘defining new syntax structures by being able to take unevaluated code chunks’ aspect of macros, you can get a lot of mileage out of Ruby’s blocks for doing macro-like things. However, macros can do a lot more than that.”

Turns out I’m not the only one to think that Ruby’s a good way to go if you want something with a lot of Lisp groove, including some portion of the power of macros, without jumping all the way into Lisp. Great article there; well worth reading if you’re interested in that sort of thing.

Top 10 custom JavaScript functions of all time

Top 10 custom JavaScript functions of all time

If there was ever a universal common.js shared among the entire develosphere, you’d fine these ten (plus one bonus) functions. It would be the swiss army knife no developer would go into production without. They have no doubt been tested tried and true and have proven usefulness and helpfulness to all those who’ve used them. So without further ado, here are what I believe to the top ten greatest custom JavaScript functions in use today.

I’m glad I’m not the only one who was baffled by the lack of a getElementsByClass.

Interestingly inArray() adds a method to the Array prototype object, rather than creating an independent function. I think that is a way cool way to program, but for some reason I was under the impression Safari couldn’t handle it. Maybe they’ve changed that in the version of Safari I have or something, because I tested it and it works great.

Via Reddit.

Thoughts Reading Practical Common Lisp

In my last post I mentioned reading Practical Common Lisp. I went on through several more chapters since I wrote that (quite a few more) and one practically made me stop. The first “practical” exercise is writing a library that makes it less horrifically painful to use Common Lisp to deal with reading directories.

It was a pretty quick little library and I’m sure effective, but at that time, I was kind of tired of hearing explanations of how “this has a meaningless name, for historical reasons,” or “this is completely contrary to how you’d expect it to be considering other parts of the language” or whatever. There’s a lot to just get used to in Common Lisp. Seeing an entire “practical” chapter devoted to creating a library to fix kludgy implementation problems stemming from Common Lisp’s advanced age was offputting.

But then I realized that a little ahead were the chapters on CLOS, the Common Lisp Object System, something I had always wanted to understand and never quite got. I didn’t really understand how Object-Oriented systems based on multi-method dispatch worked.

It was a really good explanation. I think I understand it now. One point that was made was that it is not a “message-passing” type of OO, the way Smalltalk and Ruby are. I realized that while CLOS is pretty cool, I really like the message-passing style of OO. It made me wistful for Ruby.

But CLOS is way powerful, and the book had a great explanation of it. Now if I take a look at other multi-method-dispatch systems I’ll have a better context from which to understand them.

The chapter on LOOP-fu was interesting. LOOP is a mini-language implemented with macros within common lisp that lets you write Python-like loop constructs (probably more powerful than Python’s loops) in a not-very-Lispy notation. It made me think Python might have been influenced by Common Lisp LOOPs.

I also wanted to check out the chapter on packages, because that was a big part of Common Lisp I didn’t previously understand. Turns out they’re a lot like Perl, but that it’s easier to shoot yourself in the foot using them than with Perl.

I still haven’t read most of the “practical” chapters yet. (I skipped forward to get to some of what I considered the good stuff.) But overall it didn’t make me want like crazy to program in Common Lisp. It made me feel like I could if I wanted to for some reason. It cleared up a lot of what was mysterious to me about Common Lisp. The only thing that Common Lisp has that I really desperately wish I had in other languages is its glorious macro system. I have a feeling that in terms of the “defining new syntax structures by being able to take unevaluated code chunks” aspect of macros, you can get a lot of mileage out of Ruby’s blocks for doing macro-like things. However, macros can do a lot more than that.

Overall it made me think fondly of Ruby, because Ruby uses a style of object orientation that seems more natural/intuitive to me, and can do a lot of (though by no means all) the spiff stuff Lisp can do.

It also made me think fondly of Scheme, because Scheme is a lot less ass-ugly than Common Lisp, and can do a lot of the same good stuff, though it doesn’t have even a tiny fraction of the built-in cool stuff in the standard.

It definitely made me open to using Common Lisp if I ever think of a project where it would come in really handy. And I do plan to finish the book when I get a chance.

Fun Fact about Common Lisp: standard Common Lisp has no networking libraries at all, but it does have a built in function to print integers as Roman numerals — using either the new style (14=XIV) or the old-style (14=XIIII) Roman numerals. Huh.