Rant: lisp is not C. Get over it.

[death]

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).

[findinglisp]

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.

[Kohath]

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 .

[JamesF]

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?

[findinglisp]

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.

[dlweinreb]

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...

[JamesF]

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.

[Balooga]

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.

[methusala]

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

[phil]

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.

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