Books of Note

Practical Common
LispThe best intro to start your journey. Excellent coverage of CLOS.

ANSI Common
LispAnother great starting point with a different focus.

Paradigms of Artificial Intelligence
ProgrammingA superb set of Lisp examples. Not just for the AI crowd.

Tuesday, November 29, 2005

A sad indictment 

The author, who shall rename nameless because he didn't make it easy for me to find his name, of The Blog That Goes Ping has some thoughts on Practical Common Lisp (via Zach Beane). He sums up with a nice indictment of Common Lisp's freeze-dried-since-1994 state:

Fun Fact about Common Lisp: standard Common Lisp has no networking libraries at all, but it does have a built in function to print integers as Roman numerals — using either the new style (14=XIV) or the old-style (14=XIIII) Roman numerals. Huh.

The biggest problem is that he's right. Doh!


Comments:


OK, So how do we get this fixed ? Common Lisp 2006 ? Would Franz, LispWorks etc. play in a new standards game ? I certainly think it would save their market. The Reddit guys mentioned the lack of community and the lack of environment as inhibitors. An entry level environment like Lispclipse would be good.
 


There exists many libraries to address perceived holes in the standard so I personally am not convinced it's worth doing.

There is no real lack of community or environments. See http://common-lisp.net and #lisp on freenode.net, http://cliki.net/ or the Usenet group comp.lang.lisp for the most visible parts of the community. There are many others: http://www.international-lisp-conference.org/,
http://www.lisp.org and many local user groups.
 


Every implementation comes with network interface code, and there are compatibility libraries. Are there any actual programs in the wild that people have tried to port across implementations that couldn't be done because of networking?

The real sad indictment is that while you can format numbers as roman numerals, there's no roman numeral read-base setting.
 


BTW, Standard C++ doesn't have any networking libraries either. And there are no such things in the world as Standard Perl or Standard Python.
 


It's a clever observation, but not a tremendous problem in practice. The flexibility of Common Lisp makes packages like trivial-sockets possible. Trivial-sockets provides a common interface to the various networking systems in various Lisp implementations. So while the standard doesn't specify how networking should be done, a third-party library can abstract away the differences between implementations and provide a de facto networking standard that behaves just as if it were part of the language.
 


The previous poster already hinted at it, but I can't resist:

Fun Fact about C: standard C has no networking libraries at all, but it does have a built in function to print integers as [obscure printf formatting directive here]. Huh.

Or, for the C++ users:
Fun fact about C++: standard C++ has no networking libraries at all, but it does have protected abstract virtual base pure virtual private destructors. Huh.
(Shamelessly stolen from Tom Cargil's C++ Journal quote)

And so on, you get the idea.
Maybe like the fun fact was indeed nothing more than just that.
 


I wrote a long and rambling post before realizing that everything I wanted to say could be summed up in a sentence or two. "Some users new to Common Lisp are overly concerned about inter-implementation portability. Some users new to Common Lisp are confused as to why there are so many competing implementations, and would much rather be given a single implementation that does at least as much as other popular scripting languages, out of the box."

I think the fairly large number of "which implementation is best" questions on c.l.l are enough justification on the second half of my theory, and my own experience, and that of every other lisp programmer I've worked with justifies the first. After all, some is an existential qualifier.

Anyway, I don't think the second is going to be fixed unless some super genius makes a product that puts every existing CL implementation to complete and total shame. And I'm pretty sure I don't want it to be fixed.

The first problem could be fixed if there was a really really good matrix of features and disadvantages of various Common Lisp implementations, so that users wouldn't have to worry if they were making the right choice of initial implementations. I think that this is a major cause of obsession over portability.
 


The nice thing about languages with one implementation (Perl, Ruby, etc.) and popular languages (C, Java) is that there is usually one standard well known way to accomplish a given task (like networking). That means there will be more documentation (dead tree versions even), and it will be better supported and less likely to change in the future.
And a question for those who think C networking isn't standardized. Have you ever programmed on a system that didn't have a libc "sys/socket.h"? Did those systems even have a working lisp compiler?
 


trivial socket doesn't support udp

nuff said

seriously, some trivial things can be easily done in a lesser lang but not with lisp

i'm not a basher, just pointing out the facts
 


> And a question for those who think C networking isn't standardized.
> Have you ever programmed on a system that didn't have a libc "sys/socket.h"?

Of course - Win32.

> Did those systems even have a working lisp compiler?

Yes, they do.
 


newlisp is quite useful!
 

Post a Comment


Links to this post:

Create a Link

This page is powered by Blogger. Isn't yours?