Just took a look at QuickLisp and that's a big improvement over the last time I looked at Common Lisp. On the other hand, there's a couple of points to make.
1) While quick lisp does have an amazing array of packages, there's still some simple, yet glaring deficiencies. For instance, there's no package to talk over a serial port. If I go to Google, the top link is a stack overflow post with some code on how to do that on Windows. The next few posts links are either people being told to use the FFI or raw writing to /dev/stty with the unix command line being used to set the tty parameters.
Comparatively, the first link Google returns for python is for PySerial, which will handle all the serial port settings on its own.
I was originally going to use this as an example of contrasting documentation, since I assumed that both languages would at least have a serial library.
2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while python mostly just offers smtplib. On the other hand, the documentation for smtplib (http://docs.python.org/library/smtplib.html) is readily available, while cl-smtp is limited to the (admittedly clear) README file.
---
I happen to love the lisp aesthetic (though I'll admit to preferring scheme over CL). Still, the main thrust of the article is that Lisp is cursed with a disorganized array of unsupported, poorly documented, incomplete solutions. QuickLisp has only solved the disorganized part of that. If there's a bug in smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd have the same luck with cl-smtp, but what about smtp4cl?
I don't believe that it's a curse and I do think that it can be solved. However, this is a cultural problem in the lisp community and ignoring it. To put it differently, if we'd had this discussion four years ago, someone would have brought up asdf and said that that solved all the problems. However, we now have QuickLisp because asdf wasn't solving all the problems. It's great and things are better than they were, but we're not done yet.
ASDF and Quicklisp are two different things. Quicklisp uses ASDF.
ASDF hasn't solved many problems. It was basically another system definition tool (with a different license). We had them before. What ASDF provided was that open source / free software used a common system definition.
Quicklisp OTOH provides a service. It uses ASDF. I provides library management and a collection of libraries.
The process over that to improve these libraries, make them better documented / more portable / rated / ... is something that happens over time.
Quicklisp does not solve all problems. It does not aim to. But it solves some.
I agree with you completely. QuickLisp does a damn fine job of solving some major problems. Honestly, looking through QuickLisp while writing up my post has made me consider moving from scheme back to CL for the first time in a long time.
My comment about asdf mostly comes from my experiences back in 2005 when I repeatedly heard that Common Lisp had NO problems and that asdf was so superior to CPAN or rubygems that there was no need to implement a new package system. In the same way, I often heard that we didn't have an issue with insufficient libraries, since UFFI (or was it CFFI?) has solved all of that. I wouldn't have been surprised if those same commentators would today declare that QuickLisp has solved everything.
However, those conversation that I had back in 2005 were not with you and I apologize for putting words in your mouth.
1.) You named one deficiency. You Googled it and although there were answers, you didn't like the answers that you received. Please enumerate the other deficiencies so I can laugh at how incredibly lame your perceived problems are.
2.) The docs for smtplib are longer than the code for cl-smtp. You'd get going quicker by reading the code and examples (tests) included in cl-smtp. Docs are wrong as soon as someone forgets to update them anyway.
---
We have had this discussion for much longer than four years. The problem is people whine about not having documentation, but refuse to put in the effort to go document libraries themselves. Same with serial ports.
How long does it take to write a few CFFI wrappers and put them on Github? If you want it so badly, do it yourself. Of course, you'd rather just use Python, which is fine, Python is fine... Norvig likes it too. You probably already know Python. Python is safe, Python is your friend. The reality is that you are justifying your perfectly reasonable desire to stay in your comfort zone with python by saying 'blah library doesn't exist'. Creating 'blah library' sounds like a perfectly reasonable place to start learning the language to me.
1) While quick lisp does have an amazing array of packages, there's still some simple, yet glaring deficiencies. For instance, there's no package to talk over a serial port. If I go to Google, the top link is a stack overflow post with some code on how to do that on Windows. The next few posts links are either people being told to use the FFI or raw writing to /dev/stty with the unix command line being used to set the tty parameters.
Comparatively, the first link Google returns for python is for PySerial, which will handle all the serial port settings on its own.
I was originally going to use this as an example of contrasting documentation, since I assumed that both languages would at least have a serial library.
2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while python mostly just offers smtplib. On the other hand, the documentation for smtplib (http://docs.python.org/library/smtplib.html) is readily available, while cl-smtp is limited to the (admittedly clear) README file.
---
I happen to love the lisp aesthetic (though I'll admit to preferring scheme over CL). Still, the main thrust of the article is that Lisp is cursed with a disorganized array of unsupported, poorly documented, incomplete solutions. QuickLisp has only solved the disorganized part of that. If there's a bug in smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd have the same luck with cl-smtp, but what about smtp4cl?
I don't believe that it's a curse and I do think that it can be solved. However, this is a cultural problem in the lisp community and ignoring it. To put it differently, if we'd had this discussion four years ago, someone would have brought up asdf and said that that solved all the problems. However, we now have QuickLisp because asdf wasn't solving all the problems. It's great and things are better than they were, but we're not done yet.