1. 6

Imagine adding object orientation to the C and Scheme programming languages. Making Scheme object-oriented is a sophomore homework assignment. On the other hand, adding object orientation to C requires the programming chops of Bjarne Stroustrup.

Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.

The Lisp Curse kicks in. Every second or third serious Lisp hacker will roll his own implementation of lazy evaluation, functional purity, arrows, pattern matching, type inferencing, and the rest. Most of these projects will be lone-wolf operations. Thus, they will have eighty percent of the features that most people need (a different eighty percent in each case). They will be poorly documented. They will not be portable across Lisp systems. Some will show great promise before being abandoned while the project maintainer goes off to pay his bills.

  1.  

  2. 2

    Excellent essay!

    I’ve got a comment and a question..

    Comment. See also: PHP vs. insert your favorite web-app-appropriate language here.

    Question. Does this pattern mean that no financial incentives exist that are strong enough to overcome this individual-hacker independence? Can the power of Lisp not be harnessed, by a group, for profit? Why not?

    Edit: Perhaps the answer is here:

    The Lisp Curse does not contradict the maxim of Stanislav Datskovskiy: Employers much prefer that workers be fungible, rather than maximally productive.

    The author attributes this to the “venality” and “close-mindedness” of managers, but I wouldn’t be so quick to dismiss it. The expected productivity of an employee, after all, is his productivity × his reliability… and this is exacerbated by dependence of a team on any given employee’s work, etc. Selecting for fungibility preferentially to maximal productivity seems to me to be nothing more than perfectly rational optimization on a manager’s part.

    (Of course this is different from employees whose main value is to be sources of ideas, etc., such as in research labs and so forth, or for designers (especially design team leads), etc.—but that’s hardly the median case, and anyway is irrelevant to the subject of programming languages.)

    1. 3

      I don’t know how much of a case this is with Lisp, but a lot of Forth programmers say that while Forth makes for excellent productivity for a capable single programmer, it’s often quite impossible for any other Forth programmer to work on the first one’s program. The programs end up idiosyncratic private languages that are impenetrable without deep study. So it’s less about workers not being maximally fungible but possibly not being able to hire any new productive workers at all for an existing system.

      Maybe the whole programming system should be set up in something like this with a new kind of module system. The inside of a module is full of maximally productive weird hyper-expressive language shenanigans, and then somehow there’s a mutually comprehensible interface layer between the modules so that the software can be assembled from these interacting fiefdoms. That’s sort of how Unix and Unix programs worked, with the interface layer being plaintext streams. I’m not quite sure what this should ideally look like. The current libraries and APIs approach isn’t good enough, you’d want to be able to exchange structures, idioms and sublanguages, not just provide a black box with buttons to push. Also you would want to avoid boxing single components in a large system into suboptimal architectures by imposing too many constraints from the surrounding area, this part gets really hard.

      Maybe Alan Kay is on to something with the whole “cells receiving chemical signals and deciding what to do, not circuits receiving electrical impulses and reacting with lockstep determinism” metaphor he’s been trying to push for the last 40 years. (Also sorta related, Functional in the small, OO in the large.)

      1. 1

        Maybe Alan Kay is on to something with the whole “cells receiving chemical signals and deciding what to do, not circuits receiving electrical impulses and reacting with lockstep determinism” metaphor he’s been trying to push for the last 40 years.

        Do you have any links/references about this? It sounds really interesting, and I’ve not heard of it before!

        1. 1

          There’s a bit of it in the Programming and Scaling talk that was linked here a while ago.

          Some emails about the origin of OO, more on messaging.

        2. 1

          By the way, “Functional in the small, OO in the large” is a big part of how Swift works. (Well, how I write Swift, anyway. Non-functional (heh) approaches are certainly also available.)

        3. 3

          Does this pattern mean that no financial incentives exist that are strong enough to overcome this individual-hacker independence?

          Paul Graham:

          So you could say that using Lisp was an experiment. Our hypothesis was that if we wrote our software in Lisp, we’d be able to get features done faster than our competitors, and also to do things in our software that they couldn’t do. And because Lisp was so high-level, we wouldn’t need a big development team, so our costs would be lower. If this were so, we could offer a better product for less money, and still make a profit. We would end up getting all the users, and our competitors would get none, and eventually go out of business. That was what we hoped would happen, anyway.

          What were the results of this experiment? Somewhat surprisingly, it worked. We eventually had many competitors, on the order of twenty to thirty of them, but none of their software could compete with ours. We had a wysiwyg online store builder that ran on the server and yet felt like a desktop application. Our competitors had cgi scripts. And we were always far ahead of them in features. Sometimes, in desperation, competitors would try to introduce features that we didn’t have. But with Lisp our development cycle was so fast that we could sometimes duplicate a new feature within a day or two of a competitor announcing it in a press release. By the time journalists covering the press release got round to calling us, we would have the new feature too.

          It must have seemed to our competitors that we had some kind of secret weapon– that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.

          1. 2

            Yes, I’ve read that essay too, but—why only that example? Where are the others? If Lisp is so good, why isn’t everyone using it? Surely the fact that Paul Graham, of all people, used it, to make money, and now sings its praises, ought to spur a whole host of people to check it out, discover it, put it to use, and profit thereby? Why isn’t it way, way, way more popular?

            1. 1

              It seems like when people try to use it, they find the ecosystem nasty. The very visible classic example of people buying pg’s Lisp evangelism, actually building a thing in Lisp and getting burned was the original Reddit. Another report of a reasonably capable newcomer trying to grab onto Common Lisp and bouncing off was Steve Yegge. It seems like you really need people building a common ground of solid libraries nowadays, and can’t really build solid stuff in an ecosystem where everybody has their own 80 % solution and the venerated standard solution was informed by 1980s computing practices.

            2. 2

              I have issues with that essay. Paul Graham never seems to acknowledge the selection bias that using Lisp imposes. It’s entirely possible that the reason ViaWeb did well isn’t because it was written in Lisp, but because it attracted the sort of people who learn Lisp. It’s entirely possible that if he’d attracted those same programmers, but somehow managed to get them to use Perl, he’d have been just as productive.

              Lisp was not (and still is not) a “mainstream” programming language. That means you have to go out of your way to learn Lisp. The sorts of programmers who go out of their way to learn obscure programming languages and libraries are more likely to be more productive (or, in Silicon Valley terms, “passionate”) programmers who would be able to bring that additional productivity to bear no matter what language they were using.

              1. 1

                Selection bias seems like it could explain a lot of this puzzle.

                The question is, do we find the same effect for other, comparably obscure / non-mainstream languages?

          Recent Comments