Rant: lisp is not C. Get over it.

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.

Are you sure you're not thinking of perl? :)

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

Too many choices: You mean, choices of implementations? You can
pick one more easily if you use my survey paper, at http://common-lisp.net/~dlw/LispSurvey.html.

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

The standard hasn't changed for ages: Well, I don't think that having
standards gratuitously change is what anyone wants! For the most
part, Lisp has been able to absorb (and improve on) good programming
language ideas as they arise, from little ones like "case" to big ones
like object-oriented programming. All this can happen without changes
in the standard, since Lisp is so extensible. However, there are
important 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 be
dealing with here is that Lisp libraries, even when they exist (and
quite a lot do), and not as easy to find as they should be, and some
are incomplete and poorly-documented. There is room for improvement
here.

Common Lisp would not look so large if the standard were written in
terms of a core language plus a set of standard libraries. Consider
that even things like "assoc" would be considered a standard library
function! We originally wanted to write the Common Lisp standard this
way, but, in a nutshell, it was more work than we had the capacity to
do at the time.

Yes, generating smaller executables would be a good thing. If you
want that for Windows, plus close support for Windows API's, take a
look at Corman Common Lisp. On Linux systems, the Common Foreign
Function Interface (cffi) has gotten quite good, making it easy to
call 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 (our
object-oriented database system, written in C++) to a very, very wide
range of machines. Every single one, without exception, had bugs in
its C++ compiler. We always had to work with the vendor to get those
bugs fixed. A close friend of mine who is still maintaining
ObjectStore recently told me that as far as he can tell, the last
person 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 for
libraries because it's so easy to just write it yourself is something
I was just discussing with my co-workers not long ago! Especially
since you often don't need all the generality of a comprehensive
library. That's a problem for getting good libraries written, in a
paradoxical sort of way.

dlweinreb wrote:However, there are
important 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?

death wrote:

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?

I guess I should have been more specific about what I wanted to know. I wanted to know about the details of your particular case, i.e. what implementation you chose to use, what libraries you had trouble with, what that trouble was, how far did you go before you decided to use Ruby, why didn't you have that trouble using Ruby, etc.

I wanted to know why you think standardization, with all its costs and constraints, is the way to solve the problems you faced. That assuming, of course, that you are aware of these costs and constraints, and I am not just talking about the costs of setting up a committee of interested Lisp users and vendors to propose, argue for and against, and ultimately compromise on a non-innovative set of modifications to the current standard. I am also talking about the costs to the users and implementers, who are supposed to integrate these modifications with their current code and knowledge-base. Do you think standardization is a viable idea at all? Who will pay for this effort? Everyone maintaining Lisp code, given that enough are willing to pay for it - but are they? is it worth paying for? Keep in mind that your answer is only part of the equation.

You see, I very much doubt that standardization is the answer to your problems. If you gave concrete details about your problem situation, maybe we could re-examine it and come up with more realistic and less costly solutions (hopefully not involving switching to a different language - Ruby or NewCL).

death wrote:I guess I should have been more specific about what I wanted to know. I wanted to know about the details of your particular case, i.e. what implementation you chose to use, what libraries you had trouble with, what that trouble was, how far did you go before you decided to use Ruby, why didn't you have that trouble using Ruby, etc.

It's a long story, but I'll give you a few details. I was using SBCL. The trouble was with various libraries related to web programming, both server side and client side. My application was going to have to interface with other external web sites and then serve up web pages itself. I was looking at using CL-PPCRE, Closure HTML/XML, Drakma, and something else to interface with the web server. Generally speaking, these are very good libraries. I went as far a prototyping parts of the application. None of the issues I encountered were fatal in any way. I could have worked around them. It's just that the Ruby version came together fairly effortlessly (ignoring issues of learning the language itself), whereas the Lisp version was always bumping into one thing or another.

I wanted to know why you think standardization, with all its costs and constraints, is the way to solve the problems you faced. That assuming, of course, that you are aware of these costs and constraints, and I am not just talking about the costs of setting up a committee of interested Lisp users and vendors to propose, argue for and against, and ultimately compromise on a non-innovative set of modifications to the current standard. I am also talking about the costs to the users and implementers, who are supposed to integrate these modifications with their current code and knowledge-base. Do you think standardization is a viable idea at all? Who will pay for this effort? Everyone maintaining Lisp code, given that enough are willing to pay for it - but are they? is it worth paying for? Keep in mind that your answer is only part of the equation.

There are many types of "standardization," some light weight, some heavyweight. I do not think that heavyweight standardization (going back to ISO to update the CL spec, for instance) is the right way to do things. It's far too slow and expensive, as you rightly point out. I'd much rather see a couple of implementations get together and hammer out the issues and get it done. You don't need perfect agreement, only critical mass. Market share can make up that critical mass, too. Essentially, you just need to separate the world of implementations into "those that are leading" and "those that are following." If the "weight" of the leaders is sufficient, then people writing libraries and such will naturally gravitate that direction.

For example, I see the Common Lisp document repository as being a big step in the right direction. CLRFI is another option, but the process is broken, IMO.

You see, I very much doubt that standardization is the answer to your problems. If you gave concrete details about your problem situation, maybe we could re-examine it and come up with more realistic and less costly solutions (hopefully not involving switching to a different language - Ruby or NewCL).

Again, don't confuse my call for "standardization" as meaning heavyweight standardization. I'm not after that.

But make no mistake, I have no desire to revisit my decision toward Ruby or work around things on the Lisp side. Instead of diagnosing my individual situation, let's just get on with correcting Lisp deficiencies. Lisp is a great language. It just needs to stop apologizing for its deficiencies and start competing in the market. If it doesn't, anybody wanting to write an application is just going to choose something else (Ruby, Python, whatever). I posted about this a bit about these same sorts of issues almost 3 years ago when Reddit made the switch from CL to Python:
http://www.findinglisp.com/blog/2005/12 ... hosis.html

Since that time, not much has been done. In that posting, I did promise to do some work on the networking side of things. A couple weeks after that, I completed a survey of the various CL network implementations (http://www.findinglisp.com/papers/socke ... -0-2-5.pdf), and it's safe to say that they're pretty much a hodge-podge of stuff. I have actually had it on my to-do list to complete a rich Lisp sockets API definition for almost 3 years. I simply haven't got there yet. Part of the problem is that sockets are actually bound up with other areas that need work (notably threading and Unicode support), and the job has always seemed large enough that I have procrastinated on it.

So, in summary, I like Lisp. But Lisp, and Lisp advocates, need to stop apologizing for the language and just get on with it. As soon as Lisp becomes easier to use than Ruby and Python, it will rule the world. Of that, I have no doubt. Until then, anybody looking to implement an application will end up taking the path of least resistance, and depending on the application, that might be something other than Lisp.

findinglisp wrote:So, in summary, I like Lisp. But Lisp, and Lisp advocates, need to stop apologizing for the language and just get on with it. As soon as Lisp becomes easier to use than Ruby and Python, it will rule the world. Of that, I have no doubt. Until then, anybody looking to implement an application will end up taking the path of least resistance, and depending on the application, that might be something other than Lisp.

I have just started using lispbuilder-sdl (and CLISP) to create an application for a friend, and there was very little resistance (working code, good documentation, quick mailing list help). Well done CL Gardeners .

findinglisp wrote: There are many types of "standardization," some light weight, some heavyweight. I do not think that heavyweight standardization (going back to ISO to update the CL spec, for instance) is the right way to do things. It's far too slow and expensive, as you rightly point out. I'd much rather see a couple of implementations get together and hammer out the issues and get it done. You don't need perfect agreement, only critical mass. Market share can make up that critical mass, too. Essentially, you just need to separate the world of implementations into "those that are leading" and "those that are following." If the "weight" of the leaders is sufficient, then people writing libraries and such will naturally gravitate that direction.
...
But make no mistake, I have no desire to revisit my decision toward Ruby or work around things on the Lisp side. Instead of diagnosing my individual situation, let's just get on with correcting Lisp deficiencies. Lisp is a great language. It just needs to stop apologizing for its deficiencies and start competing in the market.
...
So, in summary, I like Lisp. But Lisp, and Lisp advocates, need to stop apologizing for the language and just get on with it. As soon as Lisp becomes easier to use than Ruby and Python, it will rule the world. Of that, I have no doubt. Until then, anybody looking to implement an application will end up taking the path of least resistance, and depending on the application, that might be something other than Lisp.

OK, I'll bite. It'd be only fair, since I started this discussion

I've been clambering up a bunch of learning curves for the last couple of years, and am about to bring a couple of (initially basic) web-stores online. In the process, a couple of libraries have evolved, one lower-level, one more site-specific. It shouldn't be too painful to hammer them into something generally useful, which can be used as the start of a lisp version of PHP: here, download this tarball, unzip it and set up the ASDF symlinks, and you're good to go. It'll be a nice big bundle of Hunchentoot, CL-WHO, Postmodern, CLSQL and all their dependencies, because that's what I'm currently using. I'm actually migrating from CLSQL to Postmodern, but I can see the benefits of having both available (as well as the drawback of the potential confusion). Added to that will be my own library of low-level utilities to simplify things like database access, which should do a reasonably useful job of shortening the learning curve. Not a complete solution, but a start.

I've been mulling over this batteries-included thing for a few days, and thinking in particular on the comments about standardisation. I see a potential solution, albeit not a trivial or quickly-completed one. You're right in that lightweight standardisation is the way to go: figure out which libraries do play nice together, and hope like hell we have critical mass. Failing that, figure out where we're short of critical mass, and see what needs doing to get us there. I haven't sufficient cluefulness to help out with networking or threading libraries, but now that I've accumulated a few clues, should be able to help around the edges.

A certain degree of fascism may be needed among the leaders, taking the stance of "here's the standard set of implementations and libraries. Use the others as you will, but these are what we're using as common ground." I'm guessing that SBCL, ACL and Lispworks will be the main implementations, plus whatever's working best on Windows (not meaning to be dismissive of the implementations, I just don't use Windows so don't know). I expect it'll be Common Lisp all over again, being politics rather than art, but like CL, might just work well enough to concentrate the efforts. Ideally, we'll wind up with a set of libraries and implementations that can be mixed and matched at will, which is what Perl, Python and Ruby have as a major advantage.

It'll be a month or two before I stand any chance of refactoring my libraries to the point that I'm willing to let anybody else see the code, but I'm keen to release it to save anybody else having to climb up the same curves (except by choice). I'm also keen to try coming up with a generalised solution for using CL scripts at the command-line, but rather suspect that it's just not a scripting language.

Now I'll throw in my own main grievance: it's wonderful to have all these libraries available for download, it really is. But it'd be so much nicer to know which version we're downloading, especially when you're trying to maintain consistency. I have to maintain my own repositories just to know which versions I'm dealing with. "It's the latest" isn't quite as helpful as it might be, and doesn't tell me whether it's later than the "latest" version I downloaded three months ago. I may be missing something, but I'm pretty sure I also can't define an ASDF config file that tells ASDF-install to pull and load dependencies whose versions either match specific values, or fall within a certain range. That's my next project after lisp-php, right?

JamesF wrote: I've been mulling over this batteries-included thing for a few days, and thinking in particular on the comments about standardisation. I see a potential solution, albeit not a trivial or quickly-completed one. You're right in that lightweight standardisation is the way to go: figure out which libraries do play nice together, and hope like hell we have critical mass. Failing that, figure out where we're short of critical mass, and see what needs doing to get us there. I haven't sufficient cluefulness to help out with networking or threading libraries, but now that I've accumulated a few clues, should be able to help around the edges.

Bingo. But I don't think it's simply a matter of wrapping up what already works. In some cases, what works is a big kludge. Some thought should go into streamlining what's already there, with a thought given to "how things ought to be." But yes, that would be a huge start.

A certain degree of fascism may be needed among the leaders, taking the stance of "here's the standard set of implementations and libraries. Use the others as you will, but these are what we're using as common ground." I'm guessing that SBCL, ACL and Lispworks will be the main implementations, plus whatever's working best on Windows (not meaning to be dismissive of the implementations, I just don't use Windows so don't know). I expect it'll be Common Lisp all over again, being politics rather than art, but like CL, might just work well enough to concentrate the efforts. Ideally, we'll wind up with a set of libraries and implementations that can be mixed and matched at will, which is what Perl, Python and Ruby have as a major advantage.

Indeed. That's one reason I set up the poll on who is using which implementation. From the (admittedly very unscientific and not statistically significant) results there, it looks like if you just got SBCL and CLISP to go in the same direction, you'd have a huge momentum. No disrespect to ACL or LispWorks, but I just don't think they have the overall market share any more with respect to the general Lisp population. I'm sure they have some good market share for "serious" applications, whatever that really means. That's not to disrespect those particular implementations. I have never used them personally, but everybody that has says they're well constructed and supported. For the purpose of this exercise, however, the issue is mostly about driving usage and critical mass. Also, commercial vendors tend to have a lot of baggage when it comes to making strategic decisions about APIs and stuff. They have customers and financial concerns that limit their ability to move fast. This is one case where I think the open source guys can run with it and get it done.

Now I'll throw in my own main grievance: it's wonderful to have all these libraries available for download, it really is. But it'd be so much nicer to know which version we're downloading, especially when you're trying to maintain consistency. I have to maintain my own repositories just to know which versions I'm dealing with. "It's the latest" isn't quite as helpful as it might be, and doesn't tell me whether it's later than the "latest" version I downloaded three months ago. I may be missing something, but I'm pretty sure I also can't define an ASDF config file that tells ASDF-install to pull and load dependencies whose versions either match specific values, or fall within a certain range. That's my next project after lisp-php, right?

Yea, I would agree. IMO, we need something similar to Ruby Gems or CPAN.

Also, just to be specific, I'm not actually looking for a Lisp version of PHP, specifically. I do think that web applications are an important class of applications in this day and age, and Lisp definitely needs to address them, but PHP is so web-centric that it really isn't useful for much else. I just think that Lisp overall needs a "batteries included" philosophy, where some of those batteries are definitely related to web programming.

By the way, I'd like to respectfully point out that using a sarcastic tone to answer questions from beginners is not such a good idea. One of the reasons people are repelled from using Lisp is that they get the feeling that the community is hostile and unhelpful. I think that's only rarely true (except, perhaps, on the #lisp IRC channel, which I've been told about), but it only takes one insulting piece of mail or post to really turn someone off. We just have to try to be patient. And the general "answers to the usual questions by Lisp beginners" ought to just be written up in one place, so that we can just give people a URL instead of going through the litany over and over...

dlweinreb wrote:By the way, I'd like to respectfully point out that using a sarcastic tone to answer questions from beginners is not such a good idea. One of the reasons people are repelled from using Lisp is that they get the feeling that the community is hostile and unhelpful.

Fair call, and entirely true.
It was a venting of frustration with the seemingly endless stream of people who try something different, and get upset when it's not the same as what they already know. Like tourists who complain about every last thing that's not done the way it is "back home."

Your point is taken, however, and I shall stay positive and constructive until and unless somebody's proven themselves an idiot and/or a troll... at which point I'll probably just ignore them. As fun as a good flamewar can be, I haven't the time to spare these days.

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

It is easier for beginners lucky enough to have a working CL development environment dropped into their lap.

Newbies are able to install the free implementation of Python or Ruby in Windows in a couple of clicks. The same newbies try to install a free CL implementation in Windows and spend the next day trying to get Emacs working with Slime and SBCL/CLISP.

I have to modify my .emacs file to run SLIME?
An .emacs file? What is that?
OK I've defined one, but Emacs won't load it, why?
It goes in the Emacs home directory? Whats that?
I have one already its called 'My Documents', why can't emacs look there?
Oh, I have to create a new $EMACS_HOME environmental variable as well?
A new directory off of C:\ with no spaces in the folder name?
Why can't Emacs do all of this on installation. What is this, 1993?

... etc etc.

And then another day or two trying to get ASDF-INSTALL working because newbies are told that most libraries are packaged for ASDF, not knowing that actually getting ASDF-INSTALL to work in Windows is an exercise in futility. And then finally give up.

For Common Lisp, the normal beginner discovery/evaluation process of download, install, 'Hello World', compile to executable and run is a major accomplishment in itself.

Cusp is an IDE for programming in lisp (Common Lisp flavor). It comes prepackaged with SBCL and a set of tested libraries. Its package contains everything for it to work and Cusp doesn't have any external dependencies (other than Eclipse). Cusp contains all the basic features you expect from modern IDE and some more: code formatting and coloring, folding, outline, auto-completion proposals, hover quick-help, argument tips, jump to definition, project wizard, integrated testing, library management, code context sensitive help, debugger.
from:
http://www.sergeykolos.com/cusp/intro/

http://bitfauna.com/projects/cusp/index.html

Cusp says it has an easy to setup cross platform SBCL, REPL, most of the popular libraries and it works within a popular editor, Eclipse.

M

Balooga wrote:Newbies are able to install the free implementation of Python or Ruby in Windows in a couple of clicks. The same newbies try to install a free CL implementation in Windows and spend the next day trying to get Emacs working with Slime and SBCL/CLISP.

Apologies for promoting my own project, but this is exactly why I created ABLE. It's just as simple as the Python or Ruby process: download, unzip and double-click to have a working Common Lisp environment with a compiler, editor and a handful of libraries.

Balooga wrote:And then another day or two trying to get ASDF-INSTALL working because newbies are told that most libraries are packaged for ASDF, not knowing that actually getting ASDF-INSTALL to work in Windows is an exercise in futility. And then finally give up.

Or just bypass ASDF-INSTALL and simply unzip any library you want into a directory and start using it

Balooga wrote:Newbies are able to install the free implementation of Python or Ruby in Windows in a couple of clicks. The same newbies try to install a free CL implementation in Windows and spend the next day trying to get Emacs working with Slime and SBCL/CLISP.

I have to modify my .emacs file to run SLIME?
An .emacs file? What is that?
OK I've defined one, but Emacs won't load it, why?
It goes in the Emacs home directory? Whats that?
I have one already its called 'My Documents', why can't emacs look there?
Oh, I have to create a new $EMACS_HOME environmental variable as well?
A new directory off of C:\ with no spaces in the folder name?
Why can't Emacs do all of this on installation. What is this, 1993?

... etc etc.

You have a point. Managing to get a free implementation up and running by hand in Windows is almost a nightmare. I tried to do it this weekend and SLIME wouldn't work very well. It is impossible to compile anything easily since you need a working mingw or cygwin environment. The only easy way to get CL in Windows is downloading an evaluation copy of Lispworks (maybe Allegro or Corman). Well, I never tried lispbox, maybe it is a third option, but it gives you a bad feeling since there is a 2005 at the bottom of the page, and lispbox uses clisp version 2.37...

On the other hand, making it work in Ubuntu is just a matter of

sudo apt-get install emacs slime sbcl

and you will already have asdf and asdf-install. You can also get them manually if you want

sudo apt-get install asdf asdf-install

There is Weitz's lisp starter pack. But recommending this might give people the feeling that they can't create entirely open source applications - it may depend on the "commercial" Lispworks to function properly, and the free version is limited. This is not a good thing because it will make "GPL fans and commercial licenses haters" to just give up.
I'll this ABLE editor soon. It shouldn't be hard to make an application that works right after installing it. I am saying this because I installed Bunnyslayer for Windows under Wine and it worked... just like that!

I think the problem is that most people simply don't care. They code in whatever someone pays them to code in and probably do it rather poorly. It stands to reason that your average programmer is, well average, then you have your below-average programmers... If you are a fan of lisp, do you find other mind-numbingly wonderful things in your life that other people just don't get when you try to explain it to them? Lisp is part of a secret world of excellence that may never catch on. At the end of my street is a discreetly hidden path that leads to a secret beach that only a select few people seem to know about. Let lisp be your secret beach and let the other folks be happy with C# and Java.

Hi,

As a complete newcomer to Lisp, and having been programming in C,C++, and PHP I thought I'd share a few thoughts with you about my scant experience so far learning Lisp. I'm not an IT professional nor have ever been employed in the industry, and only have a basic 2yr computer-studies qualification (eurrgh COBOL), so perhaps I'm a slightly atypical Lisp learner.

I'd heard a few things about Lisp like 'if you want to be a better programmer...' and saw a review a year or two ago, in Linux Format of "Practical Common Lisp", rating it highly and recommending it for newcomers and so on impulse I bought it.

I began with Lisp In A Box + Emacs. For me, Emacs is horrible and too confusing, I may as well state that I refuse to ever try using it. I can vaguely remember also, having some trouble getting LispInABox running on Debian Etch too. So I gave up on Lisp pretty quickly and sent a post to a local LUG asking if anybody was interested in buying the book. They weren't.

FFWD to a couple of days ago and I'm perusing the 'net and end up reading http://yosefk.com/c++fqa just for fun. After an initial small feeling of hostility, I started to understand, leading me back to 'Practical Common Lisp' again.

This time I've stuck purely to Debian packages, CLISP was the first I found using Aptitude. I gave Emacs a quick spin and thought 'nah'. I installed SBCL too, just for a quick comparison but CLISP gets my vote because I can use the arrow keys for history and line editing easily - maybe SBCL can too but I'm trying to learn Lisp not configure software. At the moment I'm using Nedit for writing src files. I've used Nedit for a long time (Gedit would be fine but I try to avoid having GNOME on my system (KDE the same)) but unfortunately it does not have a syntax pattern for LISP (I found one for scheme online). From what I've read, perhaps a better editor might be needed?

This time I'm feeling more confident that I can learn Lisp. From having read more online material, I'm also starting to form a few ideas as to what I might actually want to code in it, or at least the possibilities, which is a pretty important target to have when learning a new language, I think (even though now, I'm barely even taking baby steps).

At this point, I've not learned much, but the desire is there. Because of wanting to learn, the parenthesis is not bothering me and to be honest, I can't see what the big deal is anway if(!(thing=malloc(sizeof(thing_t)*count))){. The hyphens I need to get used to. I'm finding it difficult to identify in Lisp code, what is what, it's all just words to me and keep getting this nagging feeling it's not a real language but just a database or something (I know it *is* a programming language). It does bother me that the (shared) server hosting my website does not have any Lisp system on it (but I could always ask, they might oblige), and as mentioned earlier in this thread, the problem with executables etc, but again, these things are not really applicable to me at this stage......

jwm-art wrote:This time I've stuck purely to Debian packages, CLISP was the first I found using Aptitude. I gave Emacs a quick spin and thought 'nah'. I installed SBCL too, just for a quick comparison but CLISP gets my vote because I can use the arrow keys for history and line editing easily - maybe SBCL can too but I'm trying to learn Lisp not configure software.

You'll have an easier time if you're using an environment that integrates with your Lisp to give you a better REPL and debugger access than those.

jwm-art wrote:At the moment I'm using Nedit for writing src files. I've used Nedit for a long time (Gedit would be fine but I try to avoid having GNOME on my system (KDE the same)) but unfortunately it does not have a syntax pattern for LISP (I found one for scheme online). From what I've read, perhaps a better editor might be needed?

Yeah, a better editor will make your life much easier. It will let you load code into your Lisp without doing whatever dance you're doing now (cut/paste? save/load?), provide a full-featured REPL, debugger access, and everything else a Lisper expects. I don't see any point in syntax highlighting, but some people like it, and any decent editor that provides it will do Lisp too. Try Emacs with SLIME.

Emacs+slime seems to be best, currently to me. Dunno how you're confused with it. Note that C-x puts you in another mode (other things have another meaning then.) Also you might want to remove the toolbar with the icons because sometimes it steals focus and then you can't do anything ><. You probably also want a good ~/.emacs file. (But i guess that is for that subforum.)

There is Able, but it doesn't have enough easy keyboard shortcuts and doesn't have a debugger. (And you can't have multiple buffers on a screen.) As a plus, it is cross platform. I am working on a little lisp editor, also based on ltk, by building upon but mostly scavenging from Able, but i can't promise that will lead anywhere. Also trying an idea there, making it customizable by putting together functions, thinking "Not only code is data, nested (higher order)functions are too."

jwm-art wrote: This time I've stuck purely to Debian packages, CLISP was the first I found using Aptitude. I gave Emacs a quick spin and thought 'nah'. I installed SBCL too, just for a quick comparison but CLISP gets my vote because I can use the arrow keys for history and line editing easily - maybe SBCL can too but I'm trying to learn Lisp not configure software. At the moment I'm using Nedit for writing src files. I've used Nedit for a long time (Gedit would be fine but I try to avoid having GNOME on my system (KDE the same)) but unfortunately it does not have a syntax pattern for LISP (I found one for scheme online). From what I've read, perhaps a better editor might be needed?

A couple things:

CLISP has history because it uses the GNU Readline library. This is actually a source of problem because it actually forced CLISP to change its license to GPL because Readline is a full GPL library (not LGPL). As a result, if you develop anything on CLISP that you ever want to release, make sure you understand the CLISP licensing fully. That said, CLISP is a good implementation and I use it on Windows when I want to program something there. I wish its license was a little more clear. SBCL carries an MIT license and thus cannot link with Readline. There are other Lisp-based solutions for that if you really care, but for your needs right now, I'd just stick with CLISP if it's more convenient for you.

As for editors, you can surely use anything you want. I'll tell you that while Emacs can be intimidating, it's very, very powerful. Using something like Nedit is fine, but it's sort of like using a hand saw (Nedit) rather than a chain saw (Emacs). If you really want to be a power Lisp programmer, you'll at least want to use vi with the Limp plugin ( http://mikael.jansson.be/hacking/limp/docs/ ). Once you finally internalize Emacs, you'll never reach for anything else, particularly as a Lisp programmer since Emacs is programmable in its own version of Lisp. But again, don't let editors become a barrier between you and learning Lisp. Paul Graham, a prominent Lisp hacker, uses vi and cuts/pastes code from the editor to the REPL for testing. You can do the same thing in other editors, too (gedit, Kate, etc.).

There are other editors available as well, if you don't want to learn how to use Emacs, at least for now. Here are some alternatives.

- Eclipse with Cusp plugin
- Able
- Lispworks (commercial Lisp which comes is a fancy editor - you may want to install LW-addons as well).
- Allegro

jwm-art wrote:For me, Emacs is horrible and too confusing, I may as well state that I refuse to ever try using it.

If it helps, I've made several honest efforts to come to terms with emacs, and have drawn the conclusion that it's just not for me. Personally, I'm very fond of Vim and Vilisp, but nedit will certainly do the job to start with.

The uniform syntax can be a bit disorienting, but stick with it - it will all make perfect sense before long.

Jasper wrote:There is Able, but it doesn't have enough easy keyboard shortcuts

Could I ask what you mean here as every feature provided by ABLE has an associated keyboard shortcut?

Jasper wrote:and doesn't have a debugger. (And you can't have multiple buffers on a screen.) As a plus, it is cross platform. I am working on a little lisp editor, also based on ltk, by building upon but mostly scavenging from Able, but i can't promise that will lead anywhere.

Interesting! When you have a debugger implemented would you consider contributing it back upstream to ABLE?

Hi,

Thanks for the replies and advice. At the moment I'm not doing much code editing so it's not a massive issue but it seems likely I will have to either learn something like Emacs or vi - which I'm not keen to. I thought Cusp sounded great until I discovered it was a plugin for the Eclipse IDE. I've attempted briefly to use Eclipse in the past out of curiosity but got nowhere with it. Cusp also depends on a newer version (of Eclipse) than Debian Lenny provides and I don't want to download the latest (too large/slow) and mess about configuring.

I have been using ABLE a little, and I like how easy it is to transfer code from a file to the repl. Perhaps a menu would be nice for those of us who are more point+clicky though, maybe. I will continue using it along with Clisp on its own for debugging. It's disappointing how limited the IDE choices are. Considering all the great stuff I've read about developing software with CL it seems ironic the one IDE which looked most feature-complete for a non-emacs user, is written in Java!

Incidently, (although I never use it) Anjuta can syntax-highlight CL if you use the Scintilla plugin (as opposed to GtkSourceView).
Cheers,
James.

findinglisp wrote:SBCL carries an MIT license and thus cannot link with Readline.

I wonder if anybody has considered using libedit/editline for SBCL, which is what the BSD people tend to use instead of libreadline.

I believe libedit is part of the NetBSD, FreeBSD etc. projects, and there are also projects based on them, presumably for easier use outside of NetBSD, FreeBSD etc.

e.g.
http://sourceforge.net/projects/libedit/
http://www.thrysoee.dk/editline/

Wodin wrote:

findinglisp wrote:SBCL carries an MIT license and thus cannot link with Readline.

I wonder if anybody has considered using libedit/editline for SBCL, which is what the BSD people tend to use instead of libreadline.

I believe libedit is part of the NetBSD, FreeBSD etc. projects, and there are also projects based on them, presumably for easier use outside of NetBSD, FreeBSD etc.

e.g.
http://sourceforge.net/projects/libedit/
http://www.thrysoee.dk/editline/

Yes, exactly. Those were created specifically to deliver readline-like editing infrastructure without the full GPL baggage of readline.

I have also developed a native CL readline replacement as well for another project that I'm working on. It's still rough, but I'll be packaging that up when I have time to tie up some loose ends and make it a bit more portable (works great in ECL right now, but I need to add some reader macros for the low-level stuff to make it work on other implementations).

Sorry, apparently I missed this bit on first reading.

jwm-art wrote:I installed SBCL too, just for a quick comparison but CLISP gets my vote because I can use the arrow keys for history and line editing easily - maybe SBCL can too but I'm trying to learn Lisp not configure software.

There's linedit for sbcl: http://common-lisp.net/project/linedit/
It also requires osicat and terminfo, but they're linked from the project page.

I've put a function in my .sbclrc so I can load it just by invoking (linedit), because I don't always want it loaded.

JamesF wrote:There's linedit for sbcl: http://common-lisp.net/project/linedit/
It also requires osicat and terminfo, but they're linked from the project page.

I've put a function in my .sbclrc so I can load it just by invoking (linedit), because I don't always want it loaded.

Ok, Thanks I'll give it a go.

@phil: As for the keyboard shortcuts, i guess i meant features i have in emacs and don't have in able, like C-k, C-y, M-y, and those behind C-x; C-x C-f etcetera. I have made some of those and the mechanism to change the state of the 'event reader'. Unfortunately i couldn't find a function in ltk to make a function activated by any event/keypress. Also made two text screens, but haven't figured out how to make a keypress switch between them. The customization works like this: each is simply a function with an argument to the widget to which the keys are bound. There is emacs-bindings, basic-copy-paste-bindings, etcetera. The START function takes a function that binds the keys as argument. The user just makes a function that combines the keys that he wants:

(defun text-bindings (text)
  (basic-copy-paste text)
  (emacs-like-copy-paste text))

(start :text-bindings #'text-bindings)

I am planning to do somewhat the same for the creation of widgets, will probably model that after emacs a bit. (Of course, all will have defaults.)

So i have mostly messed with that, i also made a visualizer of graphs that shows the all the links away from a vertex and some more. I tried to use *MACROEXPAND-HOOK* to get relations between functions, so this can be used to visualize some relationships between them. Haven't figured out how to prevent confusing variables with functions, though. (And of course you can enable/disable packages in the visualization.)

I tried to look at *debugger-hook* but couldn't get the example or my own attempts to work properly. I will probably try some more/look at some other documentation to figure it out. I'll try to make it such that it is a frame that can be put in other places/is usuable for Able. Since it is both ltk, it shouldn't be too hard.

PS sorry for late reply.

Reading this thread there's a lot in it I'd like to respond to, but I'm not known for brevity in any case, and if I tried to respond to all of it I'd wind up writing something way too long to read. But...

First off I agree with findinglisp that Lispers ought not to gloss over the problems with CL. CL is very inconvenient to use in some respects. I mean- I use CL on both winxp and on Debian Linux (well, my home machine is Ubuntu these days, but I use Debian on my server), and I have been using CL on my own (i.e. not as part of a class or something, which would push the date back about 5 years) since around 2000. And I still get annoyed with some things. Not all of the difficulties are necessary consequences of the language itself, but when someone starts playing with CL they're not likely to make that kind of fine distinction.

That said, after 10 years of dabbling, and a couple years of actually using CL for some of my work, where I could get away with it, I pretty much know what to do to get things working in the implementations I use, and can figure out what to do, with some work, in new implementations. I started using ECL quite a bit about 1.5 years ago, and I think it's better than sliced bread, but there was a bit of pain at the beginning- I think it would be awfully difficult for someone to pick up as a first CL. Of course there's an easy answer to that, and it's the same answer the doctor gaveme when I told him it hurt my arms when I lifted them above my head: "Well then, don't do that." .

I have to say that my opinion is that if you want to get started with CL, and if you want to have all the libraries, etc., (as opposed to just having a CL environment to learn to write CL in, in which case Lispworks Free edition on Windows is fine) you should be running some variant of Debian Linux, and using SBCL. But even then there are soe issues- my experience has been that using apt, or synaptic, or whatever package management tool to get sbcl and the libs you want is a losing proposition in the long run. And I'm not happy with any of the other means of managing libraries that I've tried (asdf-install, and the like), though I'll admit that I gave up on them a while ago, so maybe they are better now. At any rate, I manage my CL installations by hand. It's a bit of a pain, in the short term, but I find it tends to bite less in the long run.

I also keep archived copies for every library of every version I've ever had installed- if I were really bright I would actually keep my lisp libs directory under version control. A lot of the more important lisp libs are pretty much run from cvs or another verrsion control system, so you can't discount the possibility that someone 5 dependencies back is going to hose your entire tool chain with an ill-advised commit, if you choose to keep up-to-date. I just set up a new Ubuntu machine, and got all the newest versions of the libs I use- it took me most of a day to do it, one package at a time, and I will have to rewrite some of my code to realign it with the libs (hunchentoot in particular), but in the end that's not something I should make too big a deal of- it's the kind of thing I only do once every year or so.

But I can see how people just trying CL out might get a bit frustrated with all of that- and all I can say to them is: just get a base CL system and learn CL first. Worry about the libraries later. Historically speaking "Hello World" was printed to the console, not to a web page, and CL is ancient compared to Perl and Python and Ruby. My first "CL" (not standard-compliant, by any stretch) was poplog. There weren't really any libs available for it (and it was a pretty difficult environment in many respects), but that left you free to learn CL (or in poplog's case, to learn Cltl1 .) If you're just starting out in CL you should really concentrate on learning CL and not on learning to install CL libraries. A lot of people wind up giving up on CL before they've ever really programmed in it.

I've been intermittently playing with some code that spiders (a select part of) the web and does some document clustering, for a year or so now. There's also some frontend code involved- basically a web interface to it, and- well, now is not the time to explain it, but it sounds pretty similar to what findinglisp is talking about, in terms of the sorts of services you need. But it also has a lot of custom algorithmic stuff. Once I had all the libs in place, on SBCL under Debian, I didn't find using CL to be an impediment- in fact, I found it to be quite the opposite.

I would have had a hard time writing the algorithmic stuff in Ruby. This is partially because everything I know about Ruby I know from reading the Japanese docs (which are confusing- for instance I'm under the impression that Ruby is called Ruby because one day Matz was sitting around talking about birthstones with a co-worker when Godzilla burst into the room with an enormous Ruby held in his teeth- bear in mind that this was translated from Matz's English into Japanese, and then back into English by moi, so it might not be an entirely accurate account.) But basically this is where CL is strong- if _all_ you want to do is pull down some web pages and then present them to the user, then Ruby is probably easier. But if you want to pull down some web pages, process them intensively, and then present them to the user- well, for me, at least CL is actually a lot easier to use than Ruby, though that might be because I'm a lot more familiar with CL.At any rate, once I had all the libs installed I didn't run into the kinds of problems you seem to have run into.

Like I said earlier I started dabbling in CL about 10 years ago, maybe a little less. At that time there really weren't a lot of libraries available. When I look at how far CL has come in the last 10 years (no thanks to me, I might add- I have patched a couple of critical flaws in important libs, but that's about 20 lines of code, in all) I think CL is on the right track. I don't think CL is going to take over the world anytime soon (or ever, really), but I also think it's suitable for real work in the real world these days. Not everyone has to eat artisanal bread with good handmade cheese and brandy distilled from the tears of an angel for those things to have value. By the same token, it is not so much that CL has become less popular over the years, as much as it is that its appeal has become more selective . It would be nice if it were easier to get paid to write CL, but... if you really want to promote CL then get yourself into a position of real power in some organization and then stake your career on CL. That's how languages get popular, I think, if they lack a wealthy sponsor.

Also, I think CL would benefit from not raising people's expectations so high... Paul Graham, bless him, is really guilty here. When you read something like "Beating the Averages".. well, you could be forgiven for thinking that if you just start programming in Lisp a Unicorn will shit under your pillow every night for a fortnight, and gnomes will come polish your... monitor. I'd like to see a law passed requiring everyone who cites "Beating the Averages" to have read and understood a pretty good portion of "On Lisp" first. Because programming, even, and maybe especially, in CL is not all unicorn shit and gnome blowjobs. CL has facilities that can make you a better programmer, IMHO, but being a decent CL programmer is pretty hard, actually. Thinking about code that writes code that writes code ad infinitum is not for the faint of heart.

duncan wrote:Also, I think CL would benefit from not raising people's expectations so high... Paul Graham, bless him, is really guilty here. When you read something like "Beating the Averages".. well, you could be forgiven for thinking that if you just start programming in Lisp a Unicorn will shit under your pillow every night for a fortnight, and gnomes will come polish your... monitor. I'd like to see a law passed that requiring everyone who cites "Beating the Averages" to have read and understood a pretty good portion of "On Lisp" first. Because programming, even, and maybe especially, in CL is not all unicorn shit and gnome blowjobs.

I don't know about that. For every outspoken Lisp advocate, I think there are many more Lispers who hesitate to speak up for fear of overselling it. There's a lot of underselling to go with PG's "pedestal" approach. There's always the fear that when a person finds unicorn shit on their pillow, they won't be as appreciative of the fact that it's from a unicorn as you or I might be. Or at least this is why I think there are more Lispers than Lisp advocates (there are also people who are naturally moderate in their appreciation for Lisp). I've hesitated to advocate Lisp in the past, afraid of people being turned off by its flaws, so I reason that others might be doing the same. I'd rather trust people to, once they have some experience, see why Lisp deserves the hype.

Not that we should make baseless assertions. IMO, Common Lisp is so great because of everything that goes into it. That doesn't mean that any given thing is going to impress a user of another language. Its value is best appreciated as a whole, and making extravagant claims about some particular thing just sets up an adversarial situation. Better to tell it like it is: lots of minor things that really pay off cumulatively, along with major things (like macros) that you might need rarely, but pay big when you do need them. Talk it up as a general lifestyle improvement and get people to try it long enough for the moment to happen. When you approach it as a debate with talking points and proving things, you're just inviting an argument.

Of course, you'll look pretty smug, and probably rub some people the wrong way. That's a hazard. But that doesn't mean that there isn't a place for outspoken, self-assured advocacy, as much as there's a place for being open about CL's flaws.

Paul Donnelly wrote:Of course, you'll look pretty smug, and probably rub some people the wrong way. That's a hazard. But that doesn't mean that there isn't a place for outspoken, self-assured advocacy, as much as there's a place for being open about CL's flaws.

So very true. I work in a Java house, currently as a support monkey (long story), and I have to be careful not to get punched when, say, somebody starts raving about how cool it is that they now have generics...

Paul Donnelly wrote: I don't know about that. For every outspoken Lisp advocate, I think there are many more Lispers who hesitate to speak up for fear of overselling it.

OK, but let's think about that for a second. Who gets heard? I mean- no disrespect to Graham, cause I love him to death, but... he's loud. Every time he farts digg has an article called "Paul Graham farted". I've never seen an article called "Many Lispers Hesitate."

Paul Donnelly wrote: I've hesitated to advocate Lisp in the past, afraid of people being turned off by its flaws, so I reason that others might be doing the same. I'd rather trust people to, once they have some experience, see why Lisp deserves the hype.

I've made some people learn lisp. Mostly buddies of mine who make a living doing VB. My success rate is around 20-40% (the range is large because the sample is small.) My methods involve physical coercion in some cases. You haven't lived until you've had a small German fellow in a headlock screaming "OK- let establishes a lexical binding. Now let me go..." I hate VB. But I love personal evangelism. The problem is that not all VB programmers want to be real programmers, even when threatened with my dreaded headlock. I mean- they get paid 35k a year to suck at VB, so why bother...

Paul Donnelly wrote:Of course, you'll look pretty smug, and probably rub some people the wrong way. That's a hazard. But that doesn't mean that there isn't a place for outspoken, self-assured advocacy, as much as there's a place for being open about CL's flaws.

I stopped worrying about looking smug a while ago. The funny thing is.. it's not like I claim to be some kind of genius. I mean- I studied under some geniuses, so I know what they look like. But the internet definition of smug seems to be "claims to know just a little bit about something." I know a lot less about programming than I should, given that I've been doing it for 15 years. But I guess I'm still smug when I give someone some advice. Anyway, call me smug- I dare you.

That said, maybe the best way to market CL would be to make it exclusive. Like: "Well, I'm not sure you could really learn CL. CL is hard. You're not really bright enough to program in CL Stick with Ruby"

duncan wrote:Reading this thread there's a lot in it I'd like to respond to, but I'm not known for brevity in any case, and if I tried to respond to all of it I'd wind up writing something way too long to read. But...

Wow. That was the short version?

duncan wrote:

Paul Donnelly wrote: I don't know about that. For every outspoken Lisp advocate, I think there are many more Lispers who hesitate to speak up for fear of overselling it.

OK, but let's think about that for a second. Who gets heard?

Nobody. Yeah, some people hear Paul Graham if they hang out on the right kind of web site. So non-Lispers are either hearing the occasional praise from some super-hacker they've never met, or nothing at all. Where's the common man in the Common Lisp world? Keeping his head down, or nonexistent, one assumes.

Good for you with the headlocks.

Paul Donnelly wrote: Nobody. Yeah, some people hear Paul Graham if they hang out on the right kind of web site. So non-Lispers are either hearing the occasional praise from some super-hacker they've never met, or nothing at all. Where's the common man in the Common Lisp world? Keeping his head down, or nonexistent, one assumes.

Sorry to take so long to respond to you- it has been a hectic week. Well- you know I wonder how many people worldwide actually program a fair bit in CL. It's hard to know, but I'm pretty sure it's a small number. On the other hand, I think a _lot_ of people have read Graham's take on things. "Beating the Averages" still pops up everywhere. And while I think that "Beating the Averages" is a fine piece of writing, if a bit dated, a lot of people seem to get the wrong idea from it. The thing is that Graham was already a "super-hacker" when he sat down to write ViaWeb (he was also operating in an environment where you _had_ to be a pretty decent programmer to write a non-toy webapp, and where you really had to do a lot of the heavy lifting yourself. In a lot of ways it was a perfect time to be using CL, because there weren't really a lot of reasonable web application frameworks out there at the time so most people were hand-rolling almost everything.)

Anyway, that aside, what I'm getting at is that I think a lot of people miss a couple of things that are implicit in "Beating the Averages." CL has some real advantages as a programming language, but it's not magic. It takes a real investment of time to learn to use CL at a level where it pays the kinds of dividends Graham is talking about. I know I don't get as much from it as I could- I've been programming in CL intermittently for years, but I'm no Paul Graham .

Beyond that, the problem of the "little webapp" is one that's been pretty convincingly solved at this point. I mean, if you want to write a digg or a reddit or some other app that's just enough not like them to be fresh but play in the same space, CL is likely a bad choice unless you're already a pretty good CL programmer who has already worked out how to do that kind of thing in CL without much muss or fuss. Because, honestly, you can knock out a first draft of a site like that in a weekend in rails, or whatever, and how successful it becomes is going to have a lot more to do with things like how influential the early adopters you manage to get are, and whether or not you design the interface so that people don't hate it, and.. well, luck. I mean- CL is actually a perfectly reasonable choice for that kind of thing, but so is *gasp* -choke- PHP.

I loathe PHP, btw. But actually I got paid a princely sum to learn it (or its basics, at least), by someone who had promised more than they could deliver, spent a month messing around, and then called me asking me to write a site from scratch in time for a client meeting the next day. This was on a Thursday night, so I had him reschedule the meeting to Monday and spent the weekend in a caffeine fueled haze at double my hourly rate. Interestingly, this was not the first time this guy had paid me to learn a programming language, or at least to do my first real programming in one. A year or so earlier he had asked me to write a subsection of a site for well-known college, and I had written it using mod_python, having never programmed in Python before, beyond a few exercises from the O'Reilly book on the subject.

That might seem like a digression (well, I suppose it is, really), but I do have a point or two waiting in the wings, I promise. The first is that I could pick up Python or PHP and write a web application in it, at fairly frightening hourly rates (more on that in a sec, god help us) without anyone feeling like I was stealing from the company, or the client, or whatever. In fact the Python app I wrote for him was used for 6 or 7 years, and had a _lot_ of page-views over that time period, but I was only asked to revise it once- they wanted to downgrade their python version (because of the old RH stupidity about Python versions they wanted me to remove a call to a function in the string library that had been added to Python 1.6 but was missing from 1.5.) The only real overhead of using python was looking up some API stuff- I mean, I knew C and Java and Perl and.. well, anyway, Python wasn't much of a challenge.

Now there were two really significant factors involved here. One is that if I had tried to do this in CL, without knowing any CL, I would have been stealing from the company, and rather obviously so- I wouldn;t have gotten things done on time or on budget. Or maybe I would have, actually- I was always good at that. But I wouldn't have been writing code that used the things about CL that make it a good language. Because you can't pick that up in a weekend.

The other factor is that this is all ancient history. I think I wrote the python app in 2000, and the PHP app in 2002. In 2000 there still weren't _that many_ people who could actually deliver working web applications reliably. People were starting to get it, but I had already been doing it for a few years, so I was pretty fast at it, and I was a known quantity to the people hiring me (if I said it would be done on time for the client meeting on Monday, it probably would be done.) If I spent a few extra hours picking up a new language, no biggie to anyone. I never asked what the guy who was pimping me out in these cases was making (well, I never pressed him on the subject ), but I guarantee you that it was a lot more than I was making. That wouldn't fly now, of course, since there are a lot of 13 year olds who can do that kind of stuff in Rails easily enough (thank god they can't be trusted to deliver anything or everyone in the web industry would be working for comic-book money.)

So my point(s) (at last.) First off CL isn't going to help anyone beat the averages in a domain where the programming problems are not particularly significant. In fact CL might be a real drawback to someone not already used to its arcane ways. I mean- if you can write a first working draft of a site in a weekend in Blub, but it takes you two weeks to figure out how to make it work in CL... basically, when the average is within a certain epsilon of the optimal, in terms of how useful a language is to you, you can't beat the averages by using a better language. In fact, you can't beat the averages by being a better programmer, in that case. It just stops mattering. Anyone with a pulse can get a reddit clone up.

Second, the advantages of making the jump from Blub to CL are not like the advantages of going from C to Python or Ruby for things better written in Python than in C. I mean- I started out as a C programmer, and C is pretty much indispensable for certain kinds of systems programming, but it was a great weight off my shoulders when I started programming in garbage-collected languages. Right at the end of the time I was doing c++ I started to figure out how to do a style of c++ programming that requires very little manual memory management, but even so... c++ is a lot of work for what I consider to be a disproportionately small return (that said, c++ is actually a pretty damned interesting and powerful language in the hands of the three Jedi c++ programmers who survived the Java wars.)

So when you go from C to Java, it is a bit like magic.. you get to stop worrying about memory, to some extent. Or- well, at least you get to stop worrying about manually freeing it... it's not that hard to leak memory in Java, actually. And then when you go from Java to Python you get released from all that B+D stupid static typing nonsense (I'll leave smarter static typing alone here.. another day). So up until this point it really is kind of like magic. Without having to learn much you've multiplied your productivity by a lot.

But if you go from Python to Ruby or from Ruby to Smalltalk... well, it's not magic anymore. The low-hanging fruit is already gone (to mix a metaphor). You're still climbing Blub mountain, but it's no longer free. The sunny meadows wherein you frolicked so recently, celebrating your releas from "malloc" and "int x;" have given way to a more difficult landscape. Until this point you've been able to just walk up Blub mountain, and spread your picnic wherever you choose, but now you are going to have to do a bit of climbing. But the thing is- you know how to walk, because you've been doing it forever. So there's a qualitative change here.

But you don't have to climb too much to get at least some of the benefits of Ruby and Smalltalk. This is at least partially because other climbers have done a lot of the work for you. But then you look up at CL and.. it is actually a pretty daunting climb. You're going to need the pitons and the ropes for this one. There's no obvious place, on the way up, to lay out your picnic blanket and have a snack. In fact, you're going to have to learn a lot about climbing, while climbing. That's the nature of the more rarefied reaches of Blub mountain (whether or not CL is the summit of Blub mountain is left as an exercise for the climber.)

So, to drop the metaphor for a second, people get annoyed because 1) Paul Graham told them they would be rich if they started programming Lisp, and 2) Lisp is hard, so they can't be immediately rich, as they would certainly have been if they had just used Ruby in the first place.

This isn't Paul Graham's fault, because what people _ought_ to take away from "Beating the Averages" is this: If you are a really good CL programmer, with years of experience, including all those hard bits that involve math, algorithms (but I repeat myself), etc., and you can get in on something just at the point that it's deemed new and important, but at the point that it's still really hard.. well, you too can make ~20 million from CL, just by being a good programmer. Or you can make money by just being a really godly programmer- call that the ITA model, if you will.

In short, CL offers very few advantages for easy programming tasks, (unless you already know it well, in which case it's actually kind of nice for trivial stuff), and it offers very few advantages for people determined to make a lot of money from easy programming tasks. Unfortunately a lot of people who fit that description get really enthusiastic about CL just because Graham is a good painter, with words (I have no opinion on his canvases) and go rushing up Mt Blub (you knew it was coming back) in a T-shirt and jeans. Unfortunately, people who fail to climb Mt. Blub in a T-shirt don't die of exposure up there- they just get bitter about the whole thing and troll c.l.l for a while. Now I have nothing against trolling c.l.l, but...

Anyway, another problem with this whole thing is that it's basically impossible to bitch about any aspect of CL without being mistaken for one of these crippled former "climbers"/entrepreneurs. I mean- CL has a boatload of issues (though they actually fill an amazingly small boat when you consider that CL was designed by committee more than 20 years ago) but none of them are fatal. So basically, even if you love CL you can't vent about its broken bits without someone giving you a lecture about the ANSI process.. Well, I'm guilty here- I've given some lectures on that subject myself, and will again. Call that a meta-defect of CL .

I've never expected CL to become a dominant language again. I take a Fitzgeraldian view of programming languages. I guess I think about CL in the same way that many Jews have tended to think about Judaism. I'm not all that interested in gaining converts (CL is not for everyone), but I can see the value in educating those who are drawn to the faith. Not that I am very knowledgeable myself- I am so lacking in understanding that I might benefit from explaining some things.

One thing I've considered is thoroughly annotating the sources of important libraries. Actually, more than annotating.. doing something like literate programming after the fact. I mean- it's easy to say to someone who asks about what code they should read: "read cl-ppcre." But it's hard to get a toe-hold in even a small (but rather complex for its size) library like that. It's doubly hard if you are still learning the language.

I've been a critic of undergraduate CS education since- well, actually I started bitching on the first day and I haven't stopped since. I've been asked to do better by people who wanted to score some rhetorical points. It occurs to me that undergraduate education would be a lot better if it involved more exposure to real code. So I've been looking at things like cl-ppcre to see if they could be written up in this fashion. I don't know where I would post such a thing- maybe here if it were not too large.

Anyway- I know that this post is long and digressive. It took me hours to write it. I suppose that given a few more hours I could make it half the length and four times as persuasive. I hope you can follow the thread of logic that I meant to wind through the whole thing.

Paul Donnelly wrote:Good for you with the headlocks.

That was actually based on a true story, wherein I put a small German VB programmer in a headlock.But I embellished it a bit. It wasn't over him misunderstanding "let." It was more about him misunderstanding the nature of the stack, and trolling me in IRL. That's really the wonderful thing about spreading the word in person. You can troll back, and be sure your headlock has met your mark. Of course this was a buddy of mine, and had we not been talking about programming I would have been putting him in a headlock for other reasons. I don't recommend just going around putting every German you see in a headlock- less than half would be about right, in my experience.

This is all good stuff you've written, and I agree with almost all of it (one thing I wouldn't say is that Lisp is hard per se. Learning to take advantage of everything Lisp offers is very hard though).

duncan wrote:It occurs to me that undergraduate education would be a lot better if it involved more exposure to real code. So I've been looking at things like cl-ppcre to see if they could be written up in this fashion. I don't know where I would post such a thing- maybe here if it were not too large.

Yes, I think that's very true. You don't learn to write prose or poetry without reading it. Undergrad programs seem to focus largely on writing code, either together in class or for assignments, meaning students are mostly exposed to their own shaky code. An annotated "Lisp Reader" with problem sets related to working on the programs therein would be very cool. Ditto for other languages, of course. PAIP is pretty close to that, but it's not beginner-level.

duncan wrote:Anyway- I know that this post is long and digressive. It took me hours to write it. I suppose that given a few more hours I could make it half the length and four times as persuasive. I hope you can follow the thread of logic that I meant to wind through the whole thing.

As long as you forgive me for not responding at similar length.

The analogy with mountain climbing captures pretty well how I feel at the moment about CL. In fact, I've taken to picnicking on the meadows again, first on bash scripts and now PHP...

jwm-art wrote:The analogy with mountain climbing captures pretty well how I feel at the moment about CL. In fact, I've taken to picnicking on the meadows again, first on bash scripts and now PHP...

Hmm- well, look. PHP will give you VD, in the long run. I mean- if people give you money to do PHP that's all well and good, but you shouldn't take it seriously. A pimp can't stand those broken reference semantics. Anyway, the meadows are reserved for people who do Python or Ruby or some-such . Climbing Blub hill begins with the first step, IMHO. [EDIT: but being good at bash is sort of perversely useful so...]

Duncan, thank you for this most insightful post. It answers several questions I had (e.g., "I don't feel CL has a tangible advantage over my Ruby in day-to-day work. Why's that?")

But I'll continue to study CL. I vagually recognize some value in it, though I can't put my finger on it yet.

duncan wrote:"Beating the Averages" still pops up everywhere.

While I believe the central message of the essay is still relevant and certainly entertaining, the story no longer holds up as a reason to use Lisp without providing suitable context. My hope is that someday we'll have a new essay along similar lines but discussing the use of Lisp in an entirely different problem domain. I still believe that CL occupies something of a niche where high levels of abstraction and decent runtime performance are available in one language (Haskell and OCaml come close but you have to be happy with the type system to get along with them). For my current work, I don't think I could find a more suitable language than Lisp so perhaps one day I should document my experiences, even if they don't end quite as profitably as Graham's

Well said, Duncan. I agree with you wholeheartedly about both the difference between CL and other languages like Ruby (smaller than the distance between C and Java) and the fact that you can't criticize CL without somebody thinking you're being an ingrate. In fact, I agree with almost everything you wrote. Well said.

Personally, the biggest thing that I take away from CL is an overall philosophy of Lisp, not a specific impression that CL is the One True Programming Language. Lisp is bigger than CL. CL made a lot of compromises at the time of standardization to keep already-running code running. It also broke a lot of new and interesting ground (CLOS and the MOP). It didn't get everything right (e.g. streams), IMO, but no programming language does. I think "new Lisps" like Clojure are great in terms of getting the Lisp innovation machine moving again, though I also see some warts there (lack of tail recursion because of JVM limitations). It had stalled in the early 1990s and never really restarted. IMO, Scheme never really delivered much beyond CL (the hygenic macro quest seems like folly now, IMO, but at least we know that through experience), though its foundational concepts of lexical scoping and tail recursion (optional in CL) were clearly influential to CL.