4 ms·

PHP reached a wide audience by appealing to shared hosting providers, but that path to popularity is no longer available. To answer your reasons: - Yes, it's

• gruseom 18y ago
  But generally you choose a Lisp not to use libraries but to create a program that's in a class by itself. Boy, am I glad to see that somebody else figured this out. The lack of libraries which is the objection du jour against Lisp is actually connected to its strengths. First, there's less of a need for many libraries because it's so easy to write your own things. Second, Lisp's value goes up (and libraries' goes down) the more you get into problems that aren't well understood. But then a lot of problems get more open-ended, when you're working in a medium that encourages exploration.
  • jodrellblank 18y ago
    First, there's less of a need for many libraries because it's so easy to write your own things. If it's so easy, why aren't there good libraries for it? Nobody has done it because it's too easy? Eh? It's ridiculous and counter to the point of programming in general to suggest people ought to keep reinventing something because it's easy to do so. Even worse, if it is easy, then it's merely a distraction not a challenge - causing you to lose where you were in your program while you think about reinventing an easy wheel. Not that I believe it for a minute - implementing a good library to do something complex isn't easy - I just don't think "I want a script to process email, I could use Python and start with 'import email, pop' or I could go with Lisp and reimplement a POP client and an SMTP/MIME email parser it'll only take a minute".
    • gruseom 18y ago
      You've missed my point and attacked a generalization I was careful not to make. I said "less of a need for many libraries". The m is not silent. 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.