I've just read yet another "objective" dissection of lisp's faults. Here are my responses to the non-issues that turn up time and time again:

The syntax/parentheses.This is lisp's main strength. It's only a problem if you're expecting lisp to be like, well, something that isn't lisp. If you want syntax, pick a language that has it. But if you can cope without the overhead of memorising dozens of arbitrary rules to distract from writing code, and can manage your agoraphobia when confronted with total flexibility, keep learning. You may just figure out why, after almost fifty years, nobody's bothered to make a serious effort to hamstring the language with something it doesn't need. (I know there's at least one package that adds syntax, but how heavily is it actually used?)

Here it is again, in shorter form: with lisp, you're not wasting mental effort jumping through the hoops of something that produces an AST; you're directly manipulating the AST itself. Lisp source code is fundamentally different from C code, because you're working at a different level.

There are too many choices.Oh, you poor darling! Having to actually evaluate different options, and choose among them! Having the freedom to select the implementation whose tradeoffs suit you best!Gosh, that'd rule out Java, C and C++ as well, then.

It doesn't cater to beginners.This one bugs me even more than whimperings about the parentheses. Heavens to Betsy, how could we possibly allow the inequity of a language that doesn't have a short learning curve?! How grossly unfair, how incredibly mean, to revel in a full-strength language that doesn't hobble itself for sake of the inexperienced! Won't somebody think of the children?

Ferpitysake, people, grow up! If you want a language to learn programming with, it's not like yer menu's exactly sparse: python, perl (if you must), ruby, even shell are right there. Lisp is a language for grown-ups. It's like Unix: they both assume that you know what you're doing, that you want the power, and that you can handle it. If you want a language that stunts itself to protect you, Java and VB are right over there. No, it's not as easy to learn lisp as it is to learn, say, Python - but having climbed that hump, I can tell you that I'm very glad it's there. I'm not glad it's there because it keeps people out, but because it keeps the power in.

The standard hasn't changed for ages.It's not stagnant - it's mature. Just like the bolt-on syntax, nobody's found sufficient motivation to put in the time and effort to produce a new standard. Variants have come and gone (Dylan, Arc and Goo) but the politics-not-art that is Common Lisp is still the main branch because we still like working with it. As Paul Graham asked, what theory fits these data?

<my favourite feature> isn't part of the core language.Fine. Throw yer tantrum. Now take another look at the language: if you don't actually need network I/O (web libraries, whatever), you don't need to add the overhead to the runtime. But if you've actually bothered to learn the language, you'd have understood that once you've loaded the library, it is part of the language with which you're working. Batteries? We have entire power stations! And the funny thing is that when the need for a new library arises, that new library is often pretty quick in appearing.

The weirdest part about this is that often the same people who complain about library X not being present, also complain that they want a small core to the language. The source-code to the core can be covered by the average hand; is that small enough? All the rest of CL is the included set of batteries!

Now, understand that I'm not claiming the language is faultless. I'm just sick of hearing repeated complaints about things that aren't actually problems, from people who want lisp to be just like their favourite language, so that they don't have to go to all the work of learning something new.

Maybe lisp isn't for mere mortals. I've certainly met plenty of people who just can't handle non-trivial degrees of abstraction, so maybe it's simply that your brain needs to be *this* evolved to get onto the ride. If so, so what? You can pillory me for being arrogant, but I'm blessed with a mind that can handle a full-power language; should I be denied that tool just because some people aren't able to get their heads around it? If that's the case, we'd best close down the F1 Grand Prix, because Joe Sixpack will never be able to drive at Michael Schumacher's level.

Then again, maybe I should start trolling in the F# forums, complain loudly that it isn't lisp, and look surprised when it goes down badly...

Heh.I can hardly configure StumpWM without help, but i can read the code just fine and I understand it unless there's CLOS involved.OOP confuses me on multiple levels, but we come to a beautiful part of CL: I don't have to use it in my code if I don't want to.

On the other hand, even a beginner's guide to C programming leaves me going "WHY???"

I started on Logo at age 13, and I still know jack, but I can read lisp(CLOS aside).I can also read Python, but so can my mom. I actually found the location of a bug in the driver manager for Ubuntu Hardy, having never worked with Python! That said, all the sprinkles(how I refer to things like ;[{\|!@#$%^&*`~ all over) were... uncomfortable on some level.

In any case, I do't get why people think lisp is weird/hard/primitive. It's is what it is and it's whatever you want on top of that.

TheGZeus wrote:In any case, I do't get why people think lisp is weird/hard/primitive. It's is what it is and it's whatever you want on top of that.

I get why they think it's weird: it's different to the Algol family. What bugs me is the consistent whining that it's wrong because it's different to that family.

OOP confused the heck out of me for ages, too. I have my head around it now, but only use it lightly, and only where it makes sense to me. As you say, it's there to use if you want it, but you don't have to.

JamesF wrote:The syntax/parentheses.This is lisp's main strength. It's only a problem if you're expecting lisp to be like, well, something that isn't lisp. If you want syntax, pick a language that has it. But if you can cope without the overhead of memorising dozens of arbitrary rules to distract from writing code, and can manage your agoraphobia when confronted with total flexibility, keep learning. You may just figure out why, after almost fifty years, nobody's bothered to make a serious effort to hamstring the language with something it doesn't need. (I know there's at least one package that adds syntax, but how heavily is it actually used?)

The first thing to ask people complaining about parentheses should be: "How long have you used lisp?". It won't be much beyond a couple of toy examples. Lisp parentheses are certainly annoying at first for programmers coming from algol-like languages, much like C's braces are annoying for someone coming from a python or Visual Basic background. But it's easy to get over after some use. We don't see much whining about C braces, do we? Because people are used to them.

As you note, lisp's parentheses give rise to much power--since we're writing ASTs, it's pretty easy to write programs that write programs. Saving and reading objects is a breeze due to the uniformity. Customizing readers is possible. Now, what does C's braces buy us again? Not much beyond scoping.

JamesF wrote:There are too many choices.Oh, you poor darling! Having to actually evaluate different options, and choose among them! Having the freedom to select the implementation whose tradeoffs suit you best!Gosh, that'd rule out Java, C and C++ as well, then.

I don't think the problem here is the multiplicity of implementations, as much as the apparent incompleteness of them. Lisp, like smalltalk, leans heavily towards the "image" model. This is very different from the current established conventions in our C-based operating systems and applications. It certainly was for me--finding a lisp implementation that produces executables isn't very straightforward to someone exploring the language, and then they find their executable's 20 MBs in size because it's basically a complete lisp image dump. Not good.

I personally think lisp (and smalltalk) implementations need to be more flexible in their support for the traditional application model. Generating reasonably-sized executables should be as simple as possible. Working with native APIs (especially win32, given the prevalence of Windows) should be a breeze. At least until we get a lisp-based OS or a new lisp machine in which the lisp way is the native one .

When I was looking for a common lisp implementation in which I can develop and distribute reasonably-sized Windows/Linux executables, I took quite some time before discovering ECL. And it's not very straight-forward getting ECL to work in a C++ application either.

JamesF wrote:It doesn't cater to beginners.This one bugs me even more than whimperings about the parentheses. Heavens to Betsy, how could we possibly allow the inequity of a language that doesn't have a short learning curve?! How grossly unfair, how incredibly mean, to revel in a full-strength language that doesn't hobble itself for sake of the inexperienced! Won't somebody think of the children?

Ferpitysake, people, grow up! If you want a language to learn programming with, it's not like yer menu's exactly sparse: python, perl (if you must), ruby, even shell are right there. Lisp is a language for grown-ups. It's like Unix: they both assume that you know what you're doing, that you want the power, and that you can handle it. If you want a language that stunts itself to protect you, Java and VB are right over there. No, it's not as easy to learn lisp as it is to learn, say, Python - but having climbed that hump, I can tell you that I'm very glad it's there. I'm not glad it's there because it keeps people out, but because it keeps the power in.

I'm actually rather baffled by this--Lisp is by far easier to learn than most other languages. Sure, Common Lisp is huge, but you don't have to learn the whole of Common Lisp to write programs in it. The basic idea of Lisp can be explained to another programmer in 10 or 15 minutes tops. After that he can start playing with the language, and reading a book that explores the mind-blowing abastractions that can be (and have been!) built with this simple model (e.g. "Paradigms of AI programming" or "Practical Common Lisp"). And as far as tools go, SLIME is simply unparalleled in all static languages, and most other dynamic languages I've seen.

JamesF wrote:The standard hasn't changed for ages.It's not stagnant - it's mature. Just like the bolt-on syntax, nobody's found sufficient motivation to put in the time and effort to produce a new standard. Variants have come and gone (Dylan, Arc and Goo) but the politics-not-art that is Common Lisp is still the main branch because we still like working with it. As Paul Graham asked, what theory fits these data?

Meh, how frequently is the C or C++ standard changed? And how quickly do the compilers actually catch up? And how many compilers actually implement the standard correctly?

JamesF wrote:<my favourite feature> isn't part of the core language.Fine. Throw yer tantrum. Now take another look at the language: if you don't actually need network I/O (web libraries, whatever), you don't need to add the overhead to the runtime. But if you've actually bothered to learn the language, you'd have understood that once you've loaded the library, it is part of the language with which you're working. Batteries? We have entire power stations! And the funny thing is that when the need for a new library arises, that new library is often pretty quick in appearing.

I think Lisp needs some work in the batteries department. asdf-install is promising, but getting it to work under Windows is a wee bit baffling to the beginner.

JamesF wrote:Then again, maybe I should start trolling in the F# forums, complain loudly that it isn't lisp, and look surprised when it goes down badly...

I'm curious, why did you choose the F# forums as an example? After this rant it seemed more likely you'd be trolling some C, C++ or Java forums, no?

mhaggag wrote:I don't think the problem here is the multiplicity of implementations, as much as the apparent incompleteness of them. Lisp, like smalltalk, leans heavily towards the "image" model. This is very different from the current established conventions in our C-based operating systems and applications. It certainly was for me--finding a lisp implementation that produces executables isn't very straightforward to someone exploring the language, and then they find their executable's 20 MBs in size because it's basically a complete lisp image dump. Not good.

I personally think lisp (and smalltalk) implementations need to be more flexible in their support for the traditional application model. Generating reasonably-sized executables should be as simple as possible. Working with native APIs (especially win32, given the prevalence of Windows) should be a breeze. At least until we get a lisp-based OS or a new lisp machine in which the lisp way is the native one .

Actually, as far as I can tell, lisp and C have the same image model. It's just that all the heavily-used OSes are C-based these days, so the C image is already loaded. Try running a C programme on a Lisp machine, and I'm sure the shoe would be on the other foot.

Of course, explaining this doesn't remove the annoyance. I've gotten the hang of running lisp programmes via trampoline shell scripts, but it's still a pain. I'm sure it should be feasible to get lisp programmes running like C apps, but I know too little about things at that depth to have any useful answer. Then again, Java has the same problem (ever invoked a Java app from the command-line?) but I haven't heard much complaining about that. Maybe we should see how the Java community fends that one off, and embrace and extend the response they use

mhaggag wrote:I'm actually rather baffled by this--Lisp is by far easier to learn than most other languages. Sure, Common Lisp is huge, but you don't have to learn the whole of Common Lisp to write programs in it. The basic idea of Lisp can be explained to another programmer in 10 or 15 minutes tops. After that he can start playing with the language, and reading a book that explores the mind-blowing abastractions that can be (and have been!) built with this simple model (e.g. "Paradigms of AI programming" or "Practical Common Lisp"). And as far as tools go, SLIME is simply unparalleled in all static languages, and most other dynamic languages I've seen.

Again, I think the problem is mostly with people coming from other languages. That, and getting used to making abstractions in one direction while extrapolating them in another.

mhaggag wrote:Meh, how frequently is the C or C++ standard changed? And how quickly do the compilers actually catch up? And how many compilers actually implement the standard correctly?

Exactly. Do these people like constantly playing catch-up with ever-changing versions of a language? I suspect they're so used to it that they think in terms of evolving from, instead of evolving to.

mhaggag wrote:I think Lisp needs some work in the batteries department. asdf-install is promising, but getting it to work under Windows is a wee bit baffling to the beginner.

It does need more work, this is true, and I believe there's at least one effort currently underway to replace it with something even better. The one thing that's stopping me from using asdf-install at the moment is the lack of full support for version constraints; I get just as many problems with dependencies that are too new as I do from the ones that are too old.

However, the situation isn't as dire as many people try to make out. The emergence of http://www.cl-user.net / http://www.common-lisp.net has helped this, as a good complement to Cliki.I do understand the complaint that wheels are constantly being reinvented, but it's actually a consequence of the power of the language itself, which is under-appreciated by the newcomer. I'm as guilty as everybody else of making a trivial effort to look for a library (if I even look at all) before giving up and just writing it myself. So the "problem," in effect, is that the language is too powerful for the good of its community. Or something.

mhaggag wrote:

JamesF wrote:Then again, maybe I should start trolling in the F# forums, complain loudly that it isn't lisp, and look surprised when it goes down badly...

I'm curious, why did you choose the F# forums as an example? After this rant it seemed more likely you'd be trolling some C, C++ or Java forums, no?

Because I lurk on comp.lang.lisp, where there's been a significant level of noise produced by an F# troll (Hi, Froggy!), although his activity has mercifully dropped away in recent times. Sorry 'bout the in-joke, but I couldn't help it. Otherwise, yes, you're right: it'd be a C forum

TheGZeus wrote:I actually found the location of a bug in the driver manager for Ubuntu Hardy, having never worked with Python! That said, all the sprinkles(how I refer to things like ;[{\|!@#$%^&*`~ all over) were... uncomfortable on some level.

The syntax: It's just unfamiliar to people, and they don't alreadyrealize that you're expected to use a text editor that automaticallyindents lines. I like mhaggag's point about the C curly braces beingforeign to Python programmers; it's very much the same thing.

Doesn't cater to beginners: In what way is it harder for beginnersthan Python or Ruby? It's easier for beginners than C or Java, in myopinion, because of its interactive nature: you can just start typingexpressions. And these days there are many good textbooks, such as"Practical Common Lisp". Common Lisp isn't nearly as hard to learnas most people think.

The standard hasn't changed for ages: Well, I don't think that havingstandards gratuitously change is what anyone wants! For the mostpart, Lisp has been able to absorb (and improve on) good programminglanguage ideas as they arise, from little ones like "case" to big oneslike object-oriented programming. All this can happen without changesin the standard, since Lisp is so extensible. However, there areimportant features that Lisp does need that can't be added that way,such as thread and Unicode support.

Missing features: You can add features to Lisp that you can't add to,say, Java, such as new iteration forms. The complaint that you may bedealing with here is that Lisp libraries, even when they exist (andquite a lot do), and not as easy to find as they should be, and someare incomplete and poorly-documented. There is room for improvementhere.

Common Lisp would not look so large if the standard were written interms of a core language plus a set of standard libraries. Considerthat even things like "assoc" would be considered a standard libraryfunction! We originally wanted to write the Common Lisp standard thisway, but, in a nutshell, it was more work than we had the capacity todo at the time.

Yes, generating smaller executables would be a good thing. If youwant that for Windows, plus close support for Windows API's, take alook at Corman Common Lisp. On Linux systems, the Common ForeignFunction Interface (cffi) has gotten quite good, making it easy tocall out to C/C++ modules (e.g. encryption primitives).

How many compilers actually implement the C++ standard correctly?When I was at Object Design, we ported ObjectStore (ourobject-oriented database system, written in C++) to a very, very widerange of machines. Every single one, without exception, had bugs inits C++ compiler. We always had to work with the vendor to get thosebugs fixed. A close friend of mine who is still maintainingObjectStore recently told me that as far as he can tell, the lastperson at IBM who knows how to write C++ compilers must have quit.

JamesF's point about how we sometimes don't even bother to look forlibraries because it's so easy to just write it yourself is somethingI was just discussing with my co-workers not long ago! Especiallysince you often don't need all the generality of a comprehensivelibrary. That's a problem for getting good libraries written, in aparadoxical sort of way.

dlweinreb wrote:However, there areimportant features that Lisp does need that can't be added that way,such as thread and Unicode support.

Yes. Yes. Yes.

IMO, Common Lisp needs a touch-up. Nothing major, but it does need to be brought forward into the 21st century. Unicode, threads, and sockets should all be part of the "standard" that is implemented across multiple implementations. Yes, each implementation can do it themselves, and many have, but they have all done it differently, leading to a complete mess when trying to write real programs that might work across multiple implementations. We're rapidly heading toward the same problem that Scheme has in spades, where there isn't enough standardized and hence you get balkanization. Anybody writing "real" programs ends up having to commit to a particular implementation to get it done. And then all the work that happens toward libraries ends up getting spread across multiple implementations.

We have seen this happen before in other markets, and it's not good. Unix, and again, Scheme come to mind. We basically need a Common Lisp reformation where we go back and update the spec for modern times and rally around it. The alternative is that one particular implementation (SBCL, perhaps) ends up with dominant "market share" and most everybody ensures that their libraries work for it. This is basically what Linux did to Unix.

The single implementation languages such as Python and Ruby (or at least dominant implementation languages, since even Python and Ruby have Jython and JRuby, for instance), have an advantage with respect to these issues because they have a strong decision maker (Guido or Matz) taking input but then giving strong direction (like it or not, Python 3000 will be what Guido wants it to be, an Ruby 1.9 will be whatever Matz wants it to be). If you want to write a library for either, you write it to the dominant implementation and everybody benefits. On the flip side, if you want a feature that isn't there, you're screwed unless Guido or Matz decides they want to implement it.

To hammer this home, let me give you some insight into a decision that I recently had to make. I really love Lisp. If I didn't, I wouldn't have started this forum. I'm working on a project that is going to be doing a lot of Internet access. I had to pick my choice of programming language. I prototyped some stuff both in Lisp and in Ruby. I'm going to end up doing it in Ruby. With Lisp, I was fighting the libraries and sockets and streams and such. With Ruby, it all just worked pretty seamlessly. Do I like Ruby better than Lisp as a language? No. It's good (far better than Perl, IMO), but it's not Lisp. Could I have solved the Lisp problems? Yea, probably, but Lisp is 50 years old and it still has these basic issues? I don't want to start off every project working around basic infrastructure problems. Yea, Lisp can be great for coding efficiency, but that argument is seriously blunted if every Lisp project starts off re-solving problems that should have been solved 10 years ago. Put another way, I'd like to begin every Lisp project working on the actual problem at hand rather than grumbling about Lisp deficiencies.

findinglisp wrote:With Lisp, I was fighting the libraries and sockets and streams and such.

Can you be more specific about these problems, and about how standardization might have helped?

Certain libraries, particularly when using networking and threading, but even things like streams in some cases, are written to particular APIs. If you happen to be using a different implementation, then you're stuck working through the code and changing it, switching CL implementations, or rewriting things from scratch. Ideally, you'd just plug stuff together and things would be written to use the common infrastructure. To give you some examples, some network protocols really require you to deal with things like binary data mixed with strings, or with strings in different encodings (UTF-8 and such). There are libraries like Edi's great Flexistreams, which try to provide you a nice flexible stream interface across a range of Lisps. However, other libraries are not necessarily Flexistream-aware and won't necessarily return one when you'd want to have one, forcing you to wrap various other streams in Flexistreams, etc.

Then, try using various libraries in a multi-threaded context. Various Lisps use green threads. Others use native threading (e.g. SBCL). Still others have no threading at all. Are the libraries thread-safe? Without knowing, you really have to start introducing chunky locking. That sort of defeats any threading you might be trying to do.

If you had all this stuff standardized, then people would be working with a common model. There would be an official way to deal with Unicode and binary streams. You would still have issues as to whether a given library was thread-safe or not, but as with Java it would be a common part of the documentation and if things were thread-safe, there would be standard ways to make them so. As with any programming language, there would still be subtle bugs in the threading libraries, because threading is hard to get right, but the "rules" would at least be out on the table and everybody could then abide by them.

As I said, without standardization, all this is still solvable. But why would you want to when you could be working on your application?