Maybe time to define a new common lisp? Like common lisp was once created out of many incompatible lisps, maybe we could persuade people to work together for a more compatible world?

I agree, we need to do something about portability. As far as the way to actually get it done, I still like the proposed CL-RFI (request for implementation) process. It allows for public review and a central repository of changes, and it can move quickly because it doesn't actually place obligations on implementors.

What do you mean by "the lisp model," though? Did you have something else in mind?

What portability issue do you see with cl-xmpp? (Or with CXML for that matter, since you are referring to XML?)

As far a cl-xmpp is concerned, I don't see any read time conditionals that could not have been avoided by simply depending on trivial-sockets. No need to write RFIs for that -- it's already there!

And CXML is pretty portable, too. There is a DEFINLINE macro that's not entirely portable, and it is somewhat easier to use if unicode support is present. But that's it.

(You are right about SSL thought. The only version of CL-SSL I could findis not the prettiest code base around for my taste.)

What is the "Lisp model" and how does it differ from programming in, say, Common Lisp? Supplementary question: what does the lack of useful libraries for certain application spaces (though don't let that stop you from replying to David Lichteblau's comment, too) say, other than that libraries are lacking?

Final question -- why are you "embarrassed"? As far as I can tell, you haven't done anything to attempt to avert the situation you claim to be embarrased about; is that the problem?

Whoops. That last comment was from me, and was definitely _not_ meant to be anonymous.

What I mean by the Lisp model is multiple implementations of a static spec.

Portability is not just an issue across existing platforms, but also future platforms and implementations, and that's an issue where something like trivial-sockets doesn't have as much to offer. By writing read-time conditionalized libraries now we're incurring a debt for future maintenance. These are the same sorts of problems that Lisp had before standardization, and we're solving them in inferior ways, again.

Currently Lisp has an ANSI standard that is unlikely to change, and multiple implementations that are incompatible in the ways they perform what are, for a very large segment of programmers, tasks that are critical for their everyday work. Standardization is a tradeoff, but right now it feels like we're getting shafted in multiple directions.

It's not hard to write a hash table, but the reason I like to write Common Lisp and not Scheme is because Lisp removes the difficulty almost completely by building hash tables into the language. Networking, file handling, threading, FFI... these feel like similar situations.

I totally agree.

Talking about trivalsocket, I can't even send udp packets using lispworks pro (paid $1300 for it) without writing a FFI interface which is so easy to do with a lesser language. Currently there is no portable way to use udp across all the implementations.

Lisp is so great in all other aspects, but programming is not always about solving a cool and hard problem.

Sometime the programmer just wants to put together some api's and get the task done. Perl and Java excel in these areas.

Patches for trivial-sockets are very welcome.

cl-xmpp-devel (at) common-lisp (dot) net.

Thanks,
Erik.

I see this problem as mostly a matter of deployment. Even with asdf, it's difficult to acquire and install libraries. If you use Debian, there are some very nice packages, but if you don't...

There should be something like CPAN. It should have stuff like trivial-sockets and cxml. It should work with all Lisp impls on all platforms.

That's easier said than done, but do other people agree that this is at least a worthwhile goal?

CVS cl-xmpp now uses trivial-sockets. SASL and TLS support is in the pipeline and should be working and stable within a day or two. Expect new release over the weekend.

I emailed Peter Seibel, writer of Practical Common Lisp http://www.gigamonkeys.com/book/ to request his comment about this post, and post his reponse here (with his approval).

> I would like to see your comment on this, because your book is my introduction to this world. It's a great book, but I do think there are tough questions for application developers who want to use Lisp and I wonder whether the free Lisp community can meet the challenges ahead (cf. competing with Perl/Python/Ruby for mindshare and library development).

Well, it is certainly true that other languages, particularly ones with a single dominant implementation controlled by a single developer or development team (such as Perl, Python, and Ruby), have advantages over Common Lisp in the level of "standardization" of certain kinds of APIs. But the reason for that is that there are multiple Common Lisp implementations. (Which is, I think, what John was talking about when he refered to "the Lisp model".) If you picked any one Common Lisp implementation and compared it to any of those other languages then Lisp would do better in the comparison, particularly if you were allowed to pick a commercial Lisp such as Allegro. Unfortunately at the moment none of the free or open source Lisps have what I think of as the total package: runs on Windows, Linux, and OS X; has threads; and has a license that allows for essentially arbitrary use. CLISP runs on all three platforms but doesn't have threads and has a license that restricts it's use in developing non GPL'd software. SBCL runs on Linux and OS X and has threads on Linux and a business friendly BSD license but now Windows support and now threads on OS X. Likewise CMUCL. And OpenMCL is a great Lisp with native threads and a BSDish license but it only runs on OS X and Linux on the PowerPC.

However some of this could change in hurry if people get interested. Certainly over the past couple of years there have been a lot of Lisp libraries coming out which is evidence of more people picking up the language. So I wouldn't be surprised if some clever hacker get excited about Lisp and decides that he's going to make SBCL run on Windows. (There actually is a Windows port of CMUCL in the works but it's not clear how much progress the author has been making lately.) And with Apple switching to x86 things will probably shake out in interesting ways--the OpenMCL guys are committed to making the transition to x86 and I wouldn't be surprised if that meant that OpenMCL would also end up running on Linux x86 and then, who knows, maybe it'll be a good candidate to be ported to Windows.

Also, you should note that a lot of the things John mentioned could be made more easily portable today. There are portable XML parsers available which, if they're not sufficiently featureful at the moment, could be enhanced. And most implementations provide access to sockets; the only real problem from a standardization point of view is that no one has done the work to write, test, document, and publish a portability library that's sufficiently high quality that people just start using it rather than the implementation-specific API in whatever Lisp they care about. (It is also the case that there are some Lispers who don't care that much about portability--they have an implementation that they Like and they're happy to use it's implementation-specific features directly.)

Anyway, to sum it up: I think using Lisp now is a bit of an adventure. Some stuff that is easy in other languages *is* harder in Lisp that it seems like it ought to be in 2005. But the good news is that those things could be fixed fairly easily by anyone with a bit of time and motivation. And on the other hand, the stuff that's easy in Lisp and hard in other languages will *never* be fixed in those other languages unless they turn into Lisp. ;-)

-Peter

--
Peter Seibel