Patterns in static

A cult I almost joined





navigational aids:
 




News ticker:





topics covered:





the feedback logo. It rotates.

14 May 05.

[PDF version]

Although I had previously commented on how minimalist I want my life to be, I've found my limit--the point at which minimalism becomes madness, and that is lisp.

Lisp (list processing) is a programming language and a cult. Now, I know you're thinking that you've seen many a programmer's favorite whatever become cults, but lisp actually shows signs of culthood. Ms TNH of Nueva York, NY has this simple definition of a cult:

If, on appropriate occasions, the members tell, enjoy, trade, and/or devise transgressively funny jokes about their denomination, it's a church.

If such jokes reliably meet with stifling social disapproval, it's a cult.

So, I can't find any self-poking jokes about lisp. Self-deprecating Unix jokes, no problem. Jokes about frigging text editors, hilarious. But lisp has nothing but theological proselytizing. [The "My other car is a cdr" bumper-sticker doesn't count--it's not self-deprecating or transgressively funny, just an in-joke.]

See, we geeks never played sports, and even if we did, nobody would pick us for the team and we'd wind up on the shirts team just because nobody would want to see us on the skins team. And so, we pick teams by programming language. Which language you use doesn't just determine what kind of syntax you're going to stare at for the rest of the project, but also who you'll be associating with and who you're going to be making fun of. One could make Sapir-Whorfesque arguments about how different types of thinking are attracted to different languages, but those only go so far; like a sports team, it's a basically pointless division of a homogenous group of people which people wind up caring far too much about. [Of course, this essay is making fun of the lisp team. What can I say.]

Exhibit B: a guy who explains that lisp is a language for smart people, while everything else is for code monkeys. When I was on the fence between putting too much time into learning lisp and too much time learning python, this tipped me over the fence into python land. Do I really want to be on this guy's team? I'm up to number seven of this delightful computing tutorial right now, and glad I went with python. Have been judiciously avoiding articles entitled "Python vs. [anything]" since.

The next thing that stands out in how people praise lisp is the frequent mention of the fact that Yahoo! Stores run on lisp. When I was in Morocco, several different people told me that Neil Armstrong converted to Islam after seeing the Earth, and that Cat Stevens converted. At first, this was OK, but soon, after the third person or so mentioned this pair, I got to wondering, maybe they're the only ones. Islam seems to be doing OK for itself, but I know that lisp is not very commonly used, and it may be true that Yahoo! Stores is indeed one of the only global-scale successes of lisp. Oh, and Mathematica implements a lisp-like syntax, but sort of hides it from the user.

Open source proselytizers, conversely, have it easy: two-thirds of the web (69%) runs the open source Apache, which was written in C. MySQL is taking off, OpenOffice is used by various municipal governments, et frigging cetera. Whatever you're reading this with, be it Firefox or Internet Explorer or Safari, was written in a variant of C.

Which brings us to the fundamental question driving all discussion about lisp: if it's so great, why isn't anybody using it? Here's a story where Lisp follows the MIT/Stanford approach (good), while the rest of computing trundles along with the New Jersey approach (not good enough). [A great deal of what we use today was developed at Bell Labs, in NJ.] It's an amazing read-the archetype of the cult essay-because it explains the overall success of the dominant paradigm as being entirely due to its evilness. This is on par with an essay on how McDonald's sells so much because it sells fattening crap. Partly true, but it also packages blobs of animal fat in a cheap and convenient package, and cheap and convenient is good even if factory animal slaughter isn't. If we rate cult essayists by their ability to maintain the fiction that there are absolutely no good goals in the world but their own, our lisp author gets a gold star. [The rest of the article gives some pretty good self-critique of how to save lisp, and seems to recover from the juvenalia of the subessay I'm bitching about here.] Indeed, from what I can gather, lisp is a good language. Its key feature over the New Jersey languages (C, C++, Java, et cetera) is that it can execute its own output. It's easy to write a program that can modify its own code, or that can write new programs that improve upon itself. You don't have to be into artificial intelligence or computer learning to appreciate the coolness of a program-writing program.

(Don't like lisp's syntax (and ('nobody) does))? Then the first half of your program can be a set of instructions giving new syntax, and the second half can be the actual program, in your new, cozier syntax. This is also kind of cool.

As well as being cool, it is the death knell of the language for serious computing.

For the non-programmers among you, here's the executive summary of how to program: 1. Surf the Net for packages by other people that do what you need to get done. 2. Repeat step one until you've gathered everything you need. 3. Write a program that calls the modules you've collected. This is a great method, because step three is potentially very brief, provided there are enough modules out there. Here is Google's directory page for python; notice that thing in the corner where it says “Modules (249)”; that's a low estimate. Other comparable languages like Perl or Delphi have a comparable or greater abundance.

And lisp modules? Well, every part of the code can modify every other part. You can write a whole new grammar if you're so inclined. None of this helps with the goal of downloading a random package and easily calling whatever you want from it with minimal hassle. There's just a fundamental conflict between easy modularity on the one hand, which requires lots of restrictions and boring standard forms, and fluid modifiability on the other.

So with most proselytizing. If only you saw it our way, the proselytizers insist, you'd be a happier person. But we wouldn't be, because our goals fundamentally differ. I want efficient albeit boring; lisp programmers want fluid and clean; sales figures show that most people want a dancing paperclip. The more typical proselytizers have the same problem: they want inner peace, while most people just want to get laid.

Exacerbating the failure of communication, everybody lies about what they want: in the working-with-machines context they say they want to work quickly, but their true goals are to make the work go away as quickly as possible. Achieving the first involves finding good tools and reading their manuals while the second typically involves playing some music, not trying anything too hard, and generally tuning the tools out and thinking about sex. And we all want inner peace--provided it doesn't hinder our chances of getting laid.

And this is why lisp will always remain a cult. It provides cleverness and beauty, which we all want on the surface, but it's fundamentally at odds with laziness and transaprency. When we're pressed, the surface desire for beauty and elegance evaporate and reveal our base, underlying desire for the easy and fattening.


[link] [6 comments]
[Previous entry: "Colluding for a better world"]
[Next entry: "Rules, rules, rules, rules, rules"]

Replies: 6 comments

on Monday, May 16th, Andy said

Python?!? I am in favor of easy-breezy scripting but aren't you Mr. last-down-to-the-last-bit accuracy? What if Python automatically casts your int into a float or vice-versa?

on Sunday, May 3rd, Daniel Weinreb said

In your "Exhibit B", the guy (Paul Graham) does not even mention Lisp. On the other hand, it's true that there has been that kind of arrogance about Lisp, which is unfortunate. When I've seen it, it comes from young people being defensive when Lisp is attacked. I apologize on behalf of them.

There have been many, many successful Lisp applications. See the "Success Stores" section of http://common-lisp.net/~dlw/LispSurvey.html. The Yahoo! Stores example is cited and recalled so often because the team that wrote it sold their company to Yahoo! and became extremely wealthy, especially Paul Graham himself, and because so many people have read Paul Graham's essays.

That whole "New Jersey / MIT" story is very misleading. I, in fact, am the "MIT guy" cited in the story. (Bill Joy is the "New Jersey guy" even though I had left MIT and Bill Joy was never in New Jersey. We had the conversation at U. C. Berekely where Bill Joy worked.)

"Executing its own output" is not the clearest of putting it. Lisp is an extensible language. By using "Lisp macros", it is possible for you to add new syntactic constructs to the language. This is most important for building embedded domain-specific languages. Although Lisp is fifty years old, it has a sophisticated object-oriented programming facility, because we were able to easily add it
to the language.

The parenthesis syntax has proven valuable for making it easy to extend the language in this way. Adding a new lexical syntax is hard. But adding a new language construct when you don't need to deal with complex issues of lexical syntax is far easier. For example, when we added the Common Lisp Object System, we didn't need to define any new special uses of characters like hyphen-greater-then
arrows or whatever. Nobody has to learn new rules of operator precedence binding, either.

You say "every part of the code can modify every other part". This totally wrong; I'm surprised you'd publish an article criticizing Lisp with such a poor understanding of Lisp. First of all, Lisp code is compiled. Secondly, absolutely nobody ever writes code that does that, any more than you write programs that reach out and edit C and then run it. In fact, even less than that: there really
are programs that generate C code and then run them, whereas in Lisp you'd just do it with macros. The macros are all expanded by the compiler into straight minimal Lisp code; there is no modification of code at runtime whatsoever. There are many, many libraries that you can download and run with minimal hassle, just as with any language.

Good tools is exactly what Lisp has always been about. There have been excellent, powerful development environments for Lisp since long before C++ and Java existed, and there still are.

If you want to know how to use Lisp and how Lisp is really used, read "Practical Common Lisp" by Peter Seibel.

on Friday, March 25th, Kartik Agaram said

I don't follow why lisp is at odds against transparency - you don't use that word until the final para.

on Saturday, March 26th, the author said

Kartik (and everybody who may have come from this 2011 Ycombinator thread),

If I had to give a summary sentence to this post, it would be that there is a fundamental conflict between unfettered creativity and building structures collaboratively. Making your own rules and working within the constraints of the collective's rules is possible but always a darn difficult balancing act.

I'm talking about my recollection of my subjective impression of the Lisp community from 2005, but I felt that the community leaned heavily toward individual expression and what are essentially ground-up or one-off projects. The Ycombinator thread includes a pointer to this 2007 essay that says essentially the same thing: Lisp attracts clever individualists.

Pulling down off-the-shelf packages that peacefully play with each other is really important, but Lisp fan pages (like this 2006 accounting of how the author "became a member of the Lisp cult") focus on how easy it is to metaprogram up a new grammar whenever you need it (including the sort of hipster AI code-rewriting that I had in retrospect overstressed). I'm just not sold that you can grab two systems like that off the shelf and use them simultaneously to quickly solve a problem. This is where complexity comes from, and the chance of clashes rises in direct proportion to the cleverness of the designers of the two systems. C works well here because it's so hard to do clever metaprogramming in such a boring language. [I will restrict my C fanboy comments to an almost-nepotistic plug for a much more modern C textbook than you used in school to clear up some misconceptions expressed on Ycombinator, and the observation that C is punk rock.]

A few people on the Ycombinator thread pointed out that there really is a disconnect between the go-crazy rhetoric around Lisp and the reality of Common Lisp packages, which have to be C-like team players (don't be super-clever, don't make up a new grammar, just do one thing well) to succeed. So, Common Lisp authors who are writing simple, functional building blocks: talk louder---you're getting drowned out.

My use of the word transparency in the last paragraph of the essay is along the same lines as the individualist/team-player dichotomy. Here's an essay by Joel the Guru on Making wrong code look wrong, the gist of which is that the more clever your code is, the harder it's going to be to look at one line of code and say `a-ha, I know what went wrong here.' C is so boring that it's hard to not be transparent; Lisp code can of course be exactly as transparent, and much of it is, but (by my subjective read of the community) Lisp is sold via demonstration of all those other features that C lacks, that push the individual and the clever at the expense of simple and transparent building blocks.

on Friday, April 15th, the author said

If you'd like more, here is another essay from 2011 expressing the same thesis that Lisp's flexibility is its curse.

on Monday, December 1st, Kartik Agaram said

I wanted to resuscitate this thread (a second time) to show off my much-developed-since plucky-clever-individualist justification/rationalization of why the usual way to foster collaboration is self-defeating in the long run -- because groups end up hamstrung by a million accumulating constraints that they provided no way to refactor out after their usefulness has ended. For software 'settlers' to not sow the seeds of their own demise, they need to be more welcoming to nomadic outsider 'barbarians'[1].

http://akkartik.name/post/libraries2

http://akkartik.name/about

http://github.com/akkartik/mu

Comments much appreciated.

[1] http://www.ribbonfarm.com/2011/03/10/the-return-of-the-barbarian

Comment!
Yes, the comment box is tiny; write in a real text editor then just cut and paste here.
If you are a human, type the letter h in the first box.
h for human:
Name:
E-Mail:
Homepage: