Lisp is a Chameleon

It's true, though, that the point is a counterintuitive one (especially given current fashions). Perhaps it deserves a better explanation. Or perhaps not, but it's something I've been thinking about for a while, and I'm going to take this as an excuse to write about it.

When a problem is well-defined, complex, and clearly tangential to your project (not part of its core), the value of a library goes up. We use such libraries in Lisp for things like SHA1 and regexes. These are not the kind of libraries I was talking about. Notice, too, that contrary to your claim, such libraries exist. And are good.

When, however, a problem is not so well-defined, not so complex, or belongs to your core domain, the value of a library goes down. This is the space I was talking about, where the cost-benefit breakdown is not so obvious. There's cost involved in using a library too: the cost of learning it, calling it, and depending on it, not to mention the loss of fine-grained control. You have to compare that to the value the library provides, and compare both of those to the cost of writing your own thing. This is where my point comes in: that cost is not the same in every environment. It's lower, for example, in Lisp. This is one of the reasons why libraries are less central to Lisp culture.

Not surprisingly, people who believe that programming mostly consists of writing glue code that calls libraries have trouble conceiving of that. Although this belief is common right now, it seems to me oddly reminiscent of the "programming will mostly consist of stringing together black-box components" meme that crashed and burned years ago. In any case, the way it's wielded nowadays as an objection against Lisp is merely a prejudice. These people "know" that Lisp can't be good because it doesn't match what they "know" about programming. It reminds me of the joke, "I can see it works in practice, but does it work in theory?"

I'll give you an example of the second kind of library. When I started working in Lisp, I looked around for the unit-test framework that people were using (the Lisp equivalent of JUnit). I didn't find one. I found a half dozen half-baked candidates, none of which made very much sense to me. This puzzled me for a long time. Were Lisp programmers really that backward? Everybody has a JUnit. I finally decided to write my own test scaffolding, and in doing so I understood the answer to my puzzle: it was just so easy, I didn't need a library. I just wrote code to test my code. Naturally I did this in a way that was designed to work well with the particular system I was building - no need to force it to conform to a pre-existing framework. I would never dream of writing such a thing in (say) C#, yet in Lisp it is so natural that not doing it is what's weird.

From this and other experiences, I came to the conclusion that when working in Lisp, it's often easy enough to just write what you need. It's not reinventing the wheel, exactly. It's more like: if I just need a couple of spokes, why go to the trouble of buying a whole wheel? I'll just whip up a couple of spokes and move on. This obviously works better in cases where it's possible to fragment the problem that way (as opposed to cases like an SMTP parser where you need the whole thing in order to get any of the value).

Different programming languages and environments are not created equal; each has its strengths and weaknesses which give rise to its particular culture. The lessons of one don't always translate directly to the next, which is a good reason to not leap to judgment.