Skip to main content

On Paul Graham and Joel Spolsky

I've often enjoyed reading the works of Paul Graham and Joel Spolsky, but there's always been something that bothered me about them, especially Paul Graham. Paul Graham writes his arguments like a mathematical proof. Each step in the process seems reasonable, and by the time you reach the end, you don't feel like there's any room to disagree. However, I just don't think life is so black and white.

My buddy Alex Jacobson finally explained it to me. They are good "story tellers". Apparently, this is even part of the culture in New York, where Joel is from. Hence, it's enjoyable to listen to their arguments. However, there's a problem with good story tellers. Their tales are often so enjoyable that it's easy to be lulled into a false sense of security and overlook the exaggerations and mis-truths. Like listening to a good talk-show host, it's easy to forget to be objective.

For instance, it's somewhat frustrating to listen to Paul Graham's constant preaching about Lisp in comparison to any other programming language. Now, I like Lisp. I think it's fantastic. However, I think Paul Graham's arguments in favor of Lisp can occasionally be closed minded. For instance, in Beating the Averages, he portrays languages as lying along a single continuum of sophistication:
As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to.
That's a seductive argument. It's so seductive, that it's easy to overlook the assumption that a continuum even makes sense. There are tons of features that Lisp doesn't have that are useful for writing applications. In fact, I like to think there's a master set of language features and each programming language simply picks some subset of that master set. Lisp has macros. Cool. However, Haskell has a really neat type system and lazy evaluation. Where does Haskell lie on the continuum in comparison to Lisp? I will remind you that Haskell too has a macro system (template Haskell). Liskell is a programming language that uses Lisp syntax on top of Haskell in order to enjoy all the benefits of both. Does that mean Liskell is the highest on the power continuum? Maybe, but it's far more likely that there simply is no continuum.

Anyway, I'm not advocating that we stop reading Paul Graham, Joel Spolsky, etc. I'm just advocating that we maintain the use of our own brains. Not everything they say is gospel.

Happy Hacking!

Comments

monkey said…
It's not a continuum, it's a lattice. But there's still a top and a bottom. The Ur language -- which has not yet been invented -- is at the top, Blub somewhere in the middle and Lisp and Haskell are probably cousins, both somewhere above Blub. Or maybe that's just a good story. ;-)

-Peter
Erik said…
Well, I'd say it is a continuum, but it isn't two dimensional. Somewhat like monkey's statement about a lattice, it's more of an n-dimensional continuum where we can't agree on n and given any particular dimension, we don't always agree on which direction is "better". With that in mind, the Blub programmer would be those that sit in the dimensions they know and refuse to even consider the validity of others.
Anonymous said…
A better point, is that some features in a language can not exist at the same time. Implementing certain features makes it impossible to implement other features.

Cheers
He's not saying there's is a continuum, he's saying that from that developers point of view there is, based on his/hers ideas of what a language should do for them.
That you organize reality according to your own percieved needs, and that this skews your view of how good/bad any given language really is.
Anonymous said…
I totally agree, listen to the arguments of others, as they often contain a grain of truth, or a different way of looking at things.
Don't accept them wholesale though.
Steve said…
monkey: Of course it isn't a lattice. You really think that Ur will be the absolute supremum language, better for all tasks than any other? This presumes not only that all tasks are equivalent, but also that all programmers are equivalent too.

Go read Brook's "Mythical Man Month" to dispensse these illusions!
monkey said…
Steve: don't you think one of the dimensions on which languages differ is their flexibility. I'd expect that the Ur language would be the Ur language in part because it would be able to range over the widest variety of tasks and be adapted for use by the widest variety of programmers. And don't worry, I've read The Mythical Man Month several times. I'm curious what part of it you think suggests that an Ur language is impossible. (I'm not claiming the Ur language would be a silver bullet, if that's what you're thinking--just better than existing languages.)
Leon said…
It is possible to present a logical argument that starts with bad premises. It's easy to skip the step of checking premises if the one making the argument takes them for granted and hand-waves over them as the argument begins.

If someone were to begin an argument by stating, "given that all programming languages can be arranged in a two-dimensional space in order of worth", you can stop and ask yourself if you agree. Using the inductive approach, I'm guessing most programmers would know from experience that this can't be true. C is a great choice for a kernal, but it's a bad choice for CGI.

Mikael (above) suggests that the premise included the context of a developer. I think I could go along with the assertion that given a particular developer and particular task, there is a single best programming language. You've just got to have the context well defined.

Remember, check your premises and don't drop context.
> Well, I'd say it is a continuum, but it isn't two dimensional.

Great comment, Erik.
James said…
My biggest problem with Joel on Software (and Paul too), is that the stories are so well written that people start making bad software engineering decisions based on them.

Twice in the last month I've heard that something isn't worth trying because "abstractions leak." Ridiculous! Yes, that's true, but that gospel has gotten out of hand to the point where people reject trying to automate/genericize things because "it can't hit every case."

Sometimes I think the binary world view of Spolsky/Graham is like patterns: Good for average programmers, but has no place in great software projects.
musesum said…
Eric & Monkey, How does one parse a n-dimensional lattice? Perhaps a L-System is more efficient? Some problem domains are broad and shallow (such as dbms) and others are narrow and deep (such as theorem provers). Since Lisp involves a parse tree, does that mean that it easily maps to all domain specific structure?

Even if a language easily maps to a domain. So what? Each business chooses its degrees of freedom. For Viaweb, the DoF was in generating new features built by the same programmers. Another business may choose its DoF to be the same features grasped by new programmers.

James, why not have a great software project built by average programmers? Just build in a feedback loop.

It seems that each language has optimized semantics and syntax along a particular domain. To map to a range of applications the language invokes framework. It seems to me that choosing the right language involves expressing the solution with the smallest set of symbols that can be manipulated by the greatest number of people in the smallest amount of time. A three body optimization problem - which may be why programming is still an art.

-Warren
SR said…
Liskell is a programming language that uses Lisp syntax on top of Haskell in order to enjoy all the benefits of both.
I thought this was a joke at first -- Haskell's syntax is already better than Lisp's!

What Lisp has over Haskell is its macros and its "the whole code all the time" nature as opposed to a edit-compile-run cycle. I don't see why anyone would want Lisp's syntax.
bogomipz said…
sr, symbol expressions is what makes Lisp be Lisp. It's responsible for the code-is-data-is-code property of the language, which again is what makes macros possible. This is also the reason why Lisp has been able to adapt itself to new programming paradigms over the past 50 years. Like Alan Kay, who coined the term "object oriented programming", once said; "Lisp isn't a language, it's a building material."
Gregory said…
The syntax for a programming language like Haskell expresses something useful. That particular form of expression is sacrificed in the case of Lisp to gain the code-is-data-is-code property. However valuable that property is, a sacrifice of expression is still made. Liskell chooses to make the syntactic sacrifice to get the code-is-data-is-code property while still maintaining the semantics of Haskell. But for those who do not need the code-is-data-is-code property, they likely benefit from the expressiveness of the Haskell syntax.
Brandon Corfman said…
Insightful post ... I've noticed that Joel's well-known tale on "the mistakes of the big rewrite" has even influenced the direction of Python 3000. The amount of assumptions he makes are staggering, yet his ideas are propagated without much question due to his sheer popularity and ability to weave a tale. Sigh ...
schmichael said…
@Brandon: The idea of evolutionary change instead of revolutionary change is very popular in the open source software world, probably before Joel wrote about avoiding big rewrites. Gnome, the Linux kernel, and Python are all great examples of large projects that purposefully avoid large rewrites.

I doubt Joel had much influence.
Anonymous said…
Both Joel and Paul have built their careers on the human weakness that most people would rather the told what to do than to figure it out for themselves. Because of this, neither Joel nor Paul have to be right, they just have to be compelling.

This is especially true for less capable programmers. When you encounter someone in the thrall of Joel or Paul (or most any other pundit), you have prima facie evidence of mediocre talent.
> Liskell is a programming language that uses Lisp syntax on top of Haskell in order to enjoy all the benefits of both.
I thought this was a joke at first -- Haskell's syntax is already better than Lisp's!

> What Lisp has over Haskell is its macros

I like Haskell's syntax too. At that point, my argument was tailored to Paul Graham who thinks Lisp syntax is better than Haskell's. My point is that if you think Lisp's syntax is better, and Liskell has Lisp syntax + all the other cool things Haskell has, then by Paul's own argument, Liskell should be better.
> This is especially true for less capable programmers. When you encounter someone in the thrall of Joel or Paul (or most any other pundit), you have prima facie evidence of mediocre talent.

Nice ;)
Brandon Corfman said…
@schmichael, Guido actually refers to Joel's "Big Rewrite" article inside the Python 3000 link I posted. (Scroll down to the bottom of the page.) He agrees with Joel's viewpoint and uses it as weight for his argument to make an evolutionary upgrade to Python.

Guido can do whatever he wants -- and I'm sure he didn't want Python 3000 to become another Perl 6 -- but the work on PyPy, IronPython & Jython indicates that you CAN do the big rewrite and have it be a success. I don't know what else you can call it.

Joel's generalizations aren't correct, and it's time we stopped propagating them.
> Guido can do whatever he wants -- and I'm sure he didn't want Python 3000 to become another Perl 6 -- but the work on PyPy, IronPython & Jython indicates that you CAN do the big rewrite and have it be a success. I don't know what else you can call it.
>
> Joel's generalizations aren't correct, and it's time we stopped propagating them.

Great point.
Bob Van Zant said…
Of this pair of authors I only regularly read Joel Spolsky. I agree with many of the things he says and disagree with some of the others. The things he says (and that any author says) are just inputs into a reader's thinking. Use these inputs as you would any other inputs.

In particular the commenter that wrote about a programmer who said we can't do something because its a leaky abstraction: This isn't a problem with Spolsky's writing it's a problem with the programmer that misread Joel's essay. The essay is important for those that haven't already realized what Joel was writing about. Abstractions "leak", its part of the reason that less-experienced engineers often make silly mistakes. Having this awareness makes you a better engineer.

The idea is to get awareness from Joel's writings. Take them and use them how you see fit.

I think a comparison can be made here to the saying "guns don't kill people, people kill people." "Spolsky doesn't breed silly engineers, silly engineers misunderstand engineering topics."

If you really want to read some misguided writings scan through most any of the comments to a slashdot posting :-).
Kartik said…
We can hold multiple models of the world in our heads, even contradictory ones. Are languages arranged in lattice or continuum or something else? I don't know, but I don't have to make an immediate choice. I just leave them around so I can call on them when they seem relevant. I read Joel and PG because they often provide valuable models that are new to me and also internally consistent enough to be intellectually pleasing and easy to remember.

A lot of the classic tips on what constitutes good writing -- make definitive statements, using short sentences, etc. -- boil down to this: say what you have to say without covering your ass or waffling. Assume you're writing for grown-ups who can decide for themselves how to use your model. PG and Joel write for grownups. All good writing is abstraction.

---

The key idea in blub is not how languages are arranged relative to each other. The key idea is this: it is an invalid argument to say that you don't need feature x in some language because you've never felt the need for it in the past.

Blub lies not in the language, but the attitude of its users.
> The key idea in blub is not how languages are arranged relative to each other. The key idea is this: it is an invalid argument to say that you don't need feature x in some language because you've never felt the need for it in the past.

I wish Paul Graham were as open minded as this idea sounds. If so, he might be curious about other language features such as lazy evaluation long enough to take a break from preaching about Lisp ;)
> Spolsky doesn't breed silly engineers, silly engineers misunderstand engineering topics.

I agree. The danger, though, is that a) they're good writers b) they've been successful. Hence, they're much less likely to be read objectively.

Perhaps you're right. There's nothing you can do to make a fool less foolish.
Kartik Agaram said…
> I wish Paul Graham were as open minded as this idea sounds. If so, he might be curious about other language features such as lazy evaluation long enough to take a break from preaching about Lisp ;)

:) Can you imagine reading a PG essay and coming across the sentence "I find x interesting"? It'll never happen. And yet it can't be that he is interested in nothing. He's just focussing on the things that he's sure he's thought more than you about, and relentlessly pruning out everything else. He's not a blogger, he's trying to 'flow timeless' or 'just give you the diffs'.

In the reasons for his popularity lie the seeds of his readers' dissatisfaction, it seems :)

---

re Preaching: I don't think PG ever had an agenda about lisp. As evidence, he hasn't mentioned it in an essay in a long time. He just wrote about what he knew until he tapped out the interesting.
> Can you imagine reading a PG essay and coming across the sentence "I find x interesting"? It'll never happen. And yet it can't be that he is interested in nothing.

I seriously question whether Paul Graham ever takes a truly open minded look at other languages. I shouldn't criticize him too hard for this, though, since most programmers are like that.

Thanks for your comments :)