The library situation (warning: mini-rant)

[Exolon]

Hey,

I decided to jump in and play with the libraries available in the CL community (i.e. ASDF-installable) to try to stop my procrastination in using CL. So I upgraded to the latest SBCL build for OS X and started looking for GUI libraries; something I personally expect from a programming language/setup before I feel it's practically usable, even though I don't write much GUI software.

Doing so was a bit of a nightmare, at least as a Lisp-newbie. It took maybe 4 hours of effort spread over two days before I found one that would nearly build (lispbuilder-sdl) and was able to coax into working with a couple of hacks. Right after that I tried to asdf-install lispbuilder-sdl-ttf (for playing with fonts) and had to modify its Makefile for OS X and specify a library location in absolute terms.
Before those, I tried and failed to install quite a few libraries - cells, cello, mcclim, poly-pen and a few others.

The ones that didn't turn up a 404 or other basic error with asdf-install required hacking to get them to build, so not one of them worked out of the box. This is pretty discouraging - how do you distribute programs when the users would have to modify Makefiles and asd files etc just to even get your code to build?

Am I just unlucky, and some servers are down (a lot of stuff on cliki gave 404s via asdf-install, and the web-cvs interfaces on common-lisp.net are broken), or is this just a result of half-baked libraries/installation scripts (understandable since not many package maintainers have Macs), or is there something more fundamentally wrong with CL?

[dmitry_vk]

The main reason is, probably, some bitrot and lack of maintenance. With GUI, I had similar experience on Linux (except that some libraries actually seemed to work).
But other libraries worked quite fine (maybe because I used Gentoo Linux's package repository, in which lisp-overlay is quite well maintained).

[qbg]

Perhaps it is more of an issue with OS X; McCLIM builds for me under Linux, same with most of the ASDF-Install libraries I have, though sometimes in building I get an error and choosing the retry installation restart works.

Additionally, for distributing software to end users, if you are sending them a lisp image, it doesn't really matter how you got it to build.

[Paul Donnelly]

I decided to jump in and play with the libraries available in the CL community (i.e. ASDF-installable) to try to stop my procrastination in using CL. So I upgraded to the latest SBCL build for OS X and started looking for GUI libraries; something I personally expect from a programming language/setup before I feel it's practically usable, even though I don't write much GUI software.

Then why do you need GUI libraries?

Doing so was a bit of a nightmare, at least as a Lisp-newbie. It took maybe 4 hours of effort spread over two days before I found one that would nearly build (lispbuilder-sdl) and was able to coax into working with a couple of hacks. Right after that I tried to asdf-install lispbuilder-sdl-ttf (for playing with fonts) and had to modify its Makefile for OS X and specify a library location in absolute terms.
Before those, I tried and failed to install quite a few libraries - cells, cello, mcclim, poly-pen and a few others.

SDL isn't really a GUI library, is it?

I don't generally mess with asdf-install. Nor have I had much trouble getting things to run. But that's possibly a result of good OS choices on my part. I hear LTK is a good mature library, but I haven't done any any Lisp GUI programming beyond a little fooling with McCLIM.

The ones that didn't turn up a 404 or other basic error with asdf-install required hacking to get them to build, so not one of them worked out of the box. This is pretty discouraging - how do you distribute programs when the users would have to modify Makefiles and asd files etc just to even get your code to build?

Distribute working library versions? Yes, this is an inconvenience for developers, but I don't see what it has to do with distribution.

Am I just unlucky, and some servers are down (a lot of stuff on cliki gave 404s via asdf-install, and the web-cvs interfaces on common-lisp.net are broken), or is this just a result of half-baked libraries/installation scripts (understandable since not many package maintainers have Macs),

A little of both. Half-baked (as you put it) libraries and installers seem to be endemic to small communities of programmers—you end up with crucial fixes floating around in patches spread by word of mouth rather than incorporated into the main project. Considering a lot of these projects are one-man efforts, or are even between developers, I can't complain too much. Until the proportion of Lispers who want to write libraries for public consumption (as opposed to Lispers who are focused on non-public projects) rises, I don't think we can expect much different.

or is there something more fundamentally wrong with CL?

Now, what kind of question is that?

[anta40]

The same situation applys for me.

I must admit while CL is a mysteriously fascinating language, but when it comes to library, CL is probably several steps behind other languages, like Python or Perl. It's easier to find cross platform libraries (I use Linux and Windows) for those two languages than for CL.

I think this nature is due to CL is "a specification", not "an implementation".

CMIIW

[JamesF]

Exolon,

The library situation is being increasingly acknowledged as somewhere between "painful" and "abysmal." People like Edi Weitz have made fantastic contributions, but there are still some significant barriers to entry for all but the determined.
I'm mostly keeping my head down until I have something concrete to contribute myself, but the reassuring news is that there are a couple of efforts underway to fix it. This doesn't change the frustrations you've had so far, of course.

OTOH, I can honestly say that most of the libraries I've used have compiled well enough, though I'm using Linux rather than MacOS. That sounds a little defensive until you consider that I'll say the same of Perl.

I'm a little confused about one thing, though: why the importance of GUI libraries? I'm genuinely curious, though possibly showing my bias towards using the browser for such things. Me, I use Hunchentoot, CL-WHO and Postmodern - you may want to try those, before leaping into GUI work. Alternatively, look at Lispworks, which I gather has a well-polished GUI API.

It's definitely not a fundamental issue with the language. If it's an endemic issue with anything, it's probably the DIY culture that's still pretty strong: people are generally expected to be inclined to hacking stuff into a working state, which is not quite as tenable a position as it used to be.

Are you trying to accomplish something in particular, or "just" learn the language? I ask because we could be able to save you some time and frustration by pointing you to some known-good libraries.


I disagree with anta40; it's not because it's a spec with multiple implementations, it's just that either people haven't gotten around to writing some of the libraries that are taken for granted in other language, or they've been written (probably several times) and not shared. One of the hazards of a language this powerful is that its users often find that it's easier to re-invent a wheel than go shopping for one. The other part of this problem is that it's hard work to write a polished library - nobody wants to share (or use) a library that's half-written and undocumented, and the motivation for maintaining it generally goes away when the job is complete.
There's also the note that not all libraries actually _need_ writing - it's often possible to "virtually" implement a library by writing a wrapper layer over a library that does something similar, which is only obvious after you've already gotten the hang of the language.

[anta40]

I disagree with anta40; it's not because it's a spec with multiple implementations, it's just that either people haven't gotten around to writing some of the libraries that are taken for granted in other language, or they've been written (probably several times) and not shared.

Thanks for your input.

The other part of this problem is that it's hard work to write a polished library - nobody wants to share (or use) a library that's half-written and undocumented, and the motivation for maintaining it generally goes away when the job is complete.

I just recently learn CL. And I think I can describe the situation like this :
this library works on this CL on this OS, and that library works on that CL on that OS.
So if i want to write multiplatform code, then I need to write some kind of wrapper, which is at the moment i'm not capable of.

Probably the (temporal) solution would be stick to one OS for a moment and forget the multiplatform issue for a while.
Not a big problem for me, I'm still happy with CL

[lnostdal]

I think this nature is due to CL is "a specification", not "an implementation".

Yeah, I'm sure people working on Lisp software and libraries are thinking the same thing; they are really worried about "what 'The Spec' might think".

Nah. There is no problem like that; there are no road-blocks. The real problem, question and solution is this; "what am I doing, or what can I do?".

If you're unhappy with the GUI-stuff that's out there then do something about it instead of expecting others to do it for you. It's that simple; that's the reality, even if this means actually having to learn Lisp first to do it. It's not harder to do in Lisp than in other languages; you can write from scratch and you have things like CFFI which is great, or you can patch or fork something already out there. It's basically what you're doing already -- as Java or Python or whatever type-developers, right? You're the reason Python has PyGtk+, no?

..or, well, maybe; how much are you guys willing to pay for an ASDF-installable set of bindings to something portable like, say, Gtk+? .. no, but, really; can you compete with what people are paying for web-UIs?

[JamesF]

I just recently learn CL. And I think I can describe the situation like this :
this library works on this CL on this OS, and that library works on that CL on that OS.
So if i want to write multiplatform code, then I need to write some kind of wrapper, which at the moment i'm not capable of.

That sounds right: making the code portable across implementations and OSes is even more work.

One thing to note: you normally don't need a wrapper to get things to work across platforms; the #+ and #- operators are very useful for telling the compiler to "use this bit of code for Lispworks and SBCL, that bit for Clisp, and this other bit for everything else". This will be useful for understanding the way some code is written, and could be useful in the future if you decide to try making something portable yourself.

Probably the (temporal) solution would be stick to one OS for a moment and forget the multiplatform issue for a while.

That sounds like a good plan while you get the hang of it.

[Unne]

But other libraries worked quite fine (maybe because I used Gentoo Linux's package repository, in which lisp-overlay is quite well maintained).

Yes, I have had much more luck using various Linux package managers than ASDF. ASDF is pretty bad. I second the recommendation of Gentoo, it's a good distro for managing Common Lisp.

The library situation is being increasingly acknowledged as somewhere between "painful" and "abysmal." People like Edi Weitz have made fantastic contributions, but there are still some significant barriers to entry for all but the determined.

Yes, that about sums it up.