Complaints I’m Seeing About Common Lisp
Despite many the successful applications written in Common Lisp, many people complain about it. I’ve been looking around the web seeing what the predominant complaints are. I’ve come up with two lists of complaints: the ones that are about things inherent to Common Lisp that can’t be fixed within the context of Common Lisp, and the ones that could be addressed. With each one, I’ve added some commentary. My comments are not deep; some are downright superficial. And they certainly reflect my own point of view, with which people can quite validly disagree. Comments about future dialects of Lisp are interesting but not in the scope of this essay.
First, there are complaints about the language itself. Since the language is a standard, and it’s important to not break existing programs, there isn’t much that can be done about these.
- I don’t like the syntax, with all the parentheses. The advantage is the simplicity and uniformity of the syntax. You absolutely must have a text editor or IDE that can automatically indent, and keep your code indented properly. The biggest problem is simply that it’s unfamiliar.
- I don’t like the prefix notation and lack of infix operators. A deep part of the Lisp ethos is to avoid special distinctions between what the language provides, what shared libraries provide, or what you provide. They all have the same syntax, rather than some being privileged to have infix tokens. It’s nice to not have to remember precedence rules.
- There are too many ways to do similar things, such as association lists, property lists, and hash tables; more generally, it seems like a design-by-committee. Yes, that’s true, and it’s largely for back-compatibility.
- It has all these obscure named like car, cdr, and setq. That’s historical, too. But really, are these any worse than printf, strpbrk, long long, and so on? Besides, you can use first and rest instead of car and cdr if you find that clearer.
- Object-oriented programming is not well integrated, e.g. sequences aren’t objects so you can’t make your own. Yes, that’s true. OOP was added to Common Lisp late in the day.
- It’s just too big. Actually, the real problem is that the core of the language is not cleanly separated from the built-in libraries. The Common Lisp designers had originally intended to do this separation, but there wasn’t time enough.
- Lisp is all about lists and recursion. No, it’s not. Elementary Lisp texts often start with those things, but real Lisp programs have arrays, hash tables, powerful iteration, and so on.
- Lisp is case-insensitive, whereas I’m accustomed to case-sensitivity. Also historical.
- Lisp macros are bad because you have to understand exactly how every macro works in order to understand the code. That’s not true: in order to understand function A that uses macro B, of course you have to know what macro B means, but in order to use function C that calls function D, you have to know what function D does. Big deal. Indeed, it is possible to use macros inappropriately, but when used properly, they make programs far easier to understand. Macros can be used to construct simple domain-specific languages, focused on the concerns of the users of the program. They allow you to write code that’s closer to the actual intent, which means ease of both reading and writing code, fewer defects, and ease of maintenance.
Second, there are many abilities missing from Common Lisp. Some of these things are missing because of the changing software ecosystem (e.g. there was no WWW when Common Lisp was standardized), some were not well-codified or well-tested enough to make it into the spec. Many can be added by libraries. The most commonly mentioned are:
- Streams (user defined)
- Threads and locking
- Modern networking: e.g. sockets, TCP and HTTP client and server, URL’s, email, etc.
- Web Services (WSDL etc.)
- Relational database access
- Persistence (Lisp-friendly)
- Meta-object protocol for CLOS
- System definition facility
- Other general-purpose access to the operating system’s facilities
- XML
- Math
- Graphics
- GUI frameworks, platform-independent
- Text manipulation
- High-performance (asynchronous) I/O
- Access to printers
- Internationalization
- Unicode strings
- Generating HTML
- X Window System
- Foreign function interface
- Regular expressions
There are many libraries of code available for Common Lisp. But among the problems are:
- They don’t all run on all implementations of Common Lisp.
- Not all of them are being maintained, to fix bugs and stay up to date with the ecosystem.
- It’s hard to know which of them are being maintained.
- It’s not always obvious where to find them.
Third, there are issues about the Common Lisp implementations:
- Do they implement the whole standard correctly? Yes, at least the leading ones do.
- Are they fast? It varies between implementations. Some generate better code than others; and performance of libraries varies. But the leading implementations are actually quite fast.
- What platforms do they run on? It varies between implementations. See my survey paper.
- Is there a good way to deliver a packaged application? Some of the implementations have good facilities for this, particularly the commercial ones; others don’t.
Fourth, there are questions about tools:
- Are there profiling tools? Many of the implementations do have profiling tools.
- Are there good interactive development environments? The leading commercial vendors have good tools of their own. For the open-source implementations, there’s SLIME (which works within GNU Emacs), which is quite good. There has recently appeared an Eclipse plugin called Cusp. There aren’t yet IDE’s that can do refactoring, though. And there aren’t source-level debuggers that let you set breakpoint and single-step and so on. On the other hand, those are somewhat less important because you can enter a read-eval-print loop and make changes very quickly.
Fifth, there are political and process issues:
- There haven’t been revisions to the standard, there isn’t any process for producing sanctioned changes, there’s nothing like the Java Community Process, nor an accepted benevolent dictator. That’s true. On the other hand, there’s something to be said for stability. More important, because you can extend Lisp, you can evolve the language yourself, for your own purposes, without having to wait for a new round of standardization. See Guy Steele’s excellent paper about growing languages. Not everything can be done this way; if the implementation has no threads or no Unicode strings, it’s hard to compensate for that.
- Because Common Lisp is not that popular in industry, it’s hard to hire qualified Common Lisp programmers. On the other hand, it’s not that hard to learn Lisp. I’d recommend Peter Seibel’s Practical Common Lisp. My employer hires people all the time who have to learn Common Lisp, and it’s not a big problem.
Steady progress is being made on the second, third, and fourth category of problem. I think the second category, the problems with libraries, could be vastly improved. This would bring more people into the Common Lisp community, and the more users there are, the more effort can be put into improving the implementations and creating better tools.
December 25th, 2007 at 10:48 pm
I think adding support for threads and locking isn’t nearly as important as adding support for concurrency (in the sense that Erlang and Gambit Scheme have).
December 26th, 2007 at 3:27 am
I think all languages need to realize that there is a huge diversity in “competition”. 10 years ago languages like ruby and python were not _that_ widespread, but they gained a lot of popularity. Similar can be said about other languages, and it must be said that all languages more or less need to cater to their audience.
However, at another side, it would be interesting to do away with all the differences and reuse solutions and components (mixing together different languages with ease) – but until then, languages need to address to their competition as well.
What I often hear is that proponents of a language, in this case lisp, simply do away with complaints about syntax. I think this is way too quick to dismiss about complaints in syntax – there is such a huge diversity in “creativity” about syntax, that dismissing complaints too early will only hurt a given language. (But let’s say what happens within the next 5 years)
December 26th, 2007 at 5:55 am
For a Lisp dialect which addresses many of the above concerns, see
http://software-lab.de/ (and click on “Download”, before you are frightened
of the language – Download and documentation is in English).
No, it is not Common Lisp. But if you want to have fun with Lisp, this
might be a good place to start.
December 26th, 2007 at 1:33 pm
Let me start by wishing you a merry Christmas (or Hanukkah, or anything that suits you).
I really liked this post. It’s a wonderful synthesis and some of them are quite interesting to think about. Just like with every language, there are some things that look bad in prospect, but are lifesavers in practice (many of these complaints seem to come from people who don’t have much experience with LISP). One example is LISP’s syntax. I’ve hated it myself back when I was learning it. Only after a while did I manage to understand why S-expressions are so cool.
What’s interesting to note is the fact that most of the complaints that apply to nearly all LISP dialects are — as we know — not exactly valid. Syntax, lack of infix notation — these are all guarantees of consistency that look horribly outside LISP. But there are a couple of other points which are not really invalid.
The first things that spring into my mind is the amount of features Common LISP introduced for backwards compatibility. I don’t have too much experience in using LISP professionally (it’s not used too much in Europe, and certainly not in East/Central Europe where I come from), but I doubt backwards compatibility is as relevant today (2007, almost 2008 actually) as it was more than 20 years ago when the CL standard was written. “Too many ways to do the same thing” is the kind of complaint I often hear — and do somewhat agree to — from Scheme users, and it also makes the language confusing for those who are learning it.
I think this does make CL seem designed by commitee-ish. I’ve heard people calling for a re-design of CL, but frankly, I don’t see that being too helpful.
December 26th, 2007 at 1:47 pm
> And there aren’t source-level debuggers that let you set breakpoint and single-step and so on.
FYI, Lispworks will do this. (Maybe you were still talking about the open source implementations, but it wasn’t clear to me.)
December 26th, 2007 at 3:41 pm
> What I often hear is that proponents of a language, in this case lisp, simply do
> away with complaints about syntax. I think this is way too quick to dismiss
> about complaints in syntax – there is such a huge diversity in “creativity” about
> syntax, that dismissing complaints too early will only hurt a given language.
I can’t help coming back (I do apologize for spamming — I simply didn’t see the other comments, I promise I will not abuse coffee like this again). Dismissing complaints about the parenthesis is probably the thing I love LISP’s designers most. A few years ago, I had the choice of learning either LISP or Dylan — and I eventually settled for LISP. I have used and abused LISP’s homoiconicity to the point where anything homoiconic without S-expressions seems out of this world to me. Tcl is homoiconic as well, but it’s not as obvious as with LISP.
Another thing that is lovely about LISP’s syntax is the fact that it’s consistent. Okay, prolonged exposure to a consistent and clean syntax does give you bad habits (I have been able to learn both PHP and French, but without the reference I rarely get the syntax right). Still, it’s worth it. The average hacks I wrote in LISP make perfect sense to me years after I’ve written them. I struggle to keep my Perl scripts clean and I need to look over them for five minutes before resuming work the day after.
December 26th, 2007 at 8:20 pm
[...] Complaints I’m Seeing About Common Lisp « Dan Weinreb’s Weblog Since the language is a standard, and it’s important to not break existing programs, there isn’t much that can be done about these. (tags: dlweinreb.wordpress.com 2007 mes11 dia26 at_tecp lisp common_lisp crítica) [...]
December 27th, 2007 at 7:08 am
* My single biggest gripe about Common Lisp is lack of portably guaranteeable proper tail recursion. A whole world of simple semantic-based code generation is made extremely harder to make efficient and/or easy and integrate with the system. It’s doable (see arnesi), but at an incredible price (though admittedly much lower than for the equivalent functionality in non-Lisp languages).
* My second gripe is about the lack of a proper module system. Packages are not it. Systems are not it. Either allow to do enough stuff that by the time the limitations really bother you, it costs too much to backtrack. Worse is better… NOT! The PLT Scheme guys seem to be on the right general track in this regard.
* While Lisp unlike unextensible languages allows both of these issues and more to be addressed as layers on top of the language, such layers add non-negligible run-time inefficiency and make it hard for code written with such layer to interact with code written without it. Worse even, such layers are not compositional. Maybe that’s why people mostly don’t bother to use or write them.
* For revisions or additions to the standards, we had informal discussions in mailing lists and specifications on Cliki, and now there’s the more formal CDR process.
* While there are plenty of scattered Lisp libraries, attempts at building an easily usable CCLAN pendant to CPAN have failed so far, though I’ve heard of plans. This IMNSHO is not completely unrelated to the mess that is the lack of a proper module system.
December 27th, 2007 at 12:37 pm
Hi, Fare! Yes, it needs a better module system, although that isn’t one of the things I heard much about (which was the point of the essay). Indeed, I am dubious that the module problem can be solved as an extension. All I can say is that we (Alan Bawden and I) did try, but could not come up with anything better than packages, at the time. Hey, what do you expect from a couple of undergrads (even given that Bawden is much smarter than I am), especially with the state of software in 1977? I hope we can learn from module systems that have been developed since then.
I and some friends have been thinking about how to do a good CPAN-like system. We’ll talk about it when we have our act together.
December 27th, 2007 at 6:50 pm
[...] Weinreb posted common Complaints About Common Lisp. My personal complaint is in there — the lack of libraries that are well-documented and [...]
December 27th, 2007 at 7:02 pm
As for the problems you chose to address, I think you’re paying way too much attention to the superficial problems of the hordes of lusers who have not tried Lisp seriously, and not enough to the deep problems of those actual hackers who have. Maybe that’s intentional, but it should be made explicit. I think you’re giving too much importance to those superficial concerns.
I’m not blaming you for not coming up with a good module system in 1977. But I admit I’m a bit nonplussed that nothing was done in the 30 years since then (OK, you can say there was plenty of action on the Scheme side of Lisp – Once again, I think the PLT guys have something more than half-decent these days). The main complaint would be that while Common Lisp is as alive as it ever was, it still has got the same sclerosis that it always had.
For a CPAN-like system, I suppose you know about CCLAN (mostly failed), Cliki and asdf-install, the CLD, and the promised CLAPPA.
Other class of problems with Common Lisp: not possible to undeclare a variable as special, or to undefine a generic function. The need to slowly execute FASLs instead of just mapping the results (because of generally unpredictable (un)interning). More generally, the fact that symbols are a concrete flat scope global to the image, which makes it very difficult to reason at any scale different from the whole image, either for modules or distributed systems. There again, packages and importing are part of the problem – semantic symlinking of non-EQ (but maybe EQUAL) symbols would have been much better than this syntactic hardlinking of them.
I understand the historic context and its significance (thanks to Kent Pitman’s explanations). But explaining the process doesn’t make its result satisfactory (as shows the latest book you reviewed).
December 27th, 2007 at 8:11 pm
Great list (as well as the additions by Faré). I cannot say that I am a Lisp hacker, but I did use it extensively during my undergrad and graduate years. I have an immense respect (awe perhaps) with the language and try to talk about it as much as possible with my colleagues. However, the list above is a first for me as most negative reactions to Lisp originate not in peoples’ heads, but in their viscera.
-m
December 29th, 2007 at 9:06 pm
Faré: could you expand on your point about lack of tail-call optimisation hindering code generation? I’ve never seen recursion used as a major technique in code generation, usually automatically generated code is much better served by low-level mechanisms such as GO / TAGBODY, or other imperative constructs. All witty remarks about recursion being the functional GOTO, it just doesn’t spring to mind when I think about code generation.
December 30th, 2007 at 10:04 pm
Hi Dan! Great to read your blog and see that you’re actively using Lisp again these days.
To me, the biggest problems are the missing and inconsistent libraries. It adds an extra layer of uncertainty and effort to have to find a library, figure out how to load/configure/use it, and see if it’s up-to-date and works on a given lisp implementation.
Another very important issue is performance tuning (and unpredictability) and how it varies from implementation to implementation and from operation to operation. It takes trial and error to find out how to do file IO efficiently, what floating point and array declarations are needed to avoid boxing, etc. For example, there was recently a bunch email on an SBCL mailing list as to why some text processing (involving reading large files) was much slower in SBCL than in Python. The diagnosis and proposed solutions weren’t obvious or the sort of thing an application programmer would want to deal with (assuming they were capable).
December 31st, 2007 at 3:15 pm
I was particularly amused by the “you have to fully understand the macros” complaint, especially if you’ve ever spent any time with Aspect-Oriented Programming in Java.
With that said, I don’t think any of those complaints are particularly interesting (or particularly unique to Lisp, with the specific and obvious exception of parentheses). For me the big issue is the maturity and availability of utilities, tools, and libraries for building web applications. I would MUCH rather program my website in Lisp than in PHP, but it’s hard to beat the functionality you get in PHP out of the box.
December 31st, 2007 at 3:16 pm
I was particularly amused by the “you have to fully understand the macros” complaint, especially if you’ve ever spent any time with Aspect-Oriented Programming in Java.
With that said, I don’t think any of those complaints are particularly interesting (or particularly unique to Lisp, with the specific and obvious exception of parentheses). For me the big issue is the maturity and availability of utilities, tools, and libraries for building web applications. I would MUCH rather program my website in Lisp than in PHP, but it’s hard to beat the functionality you get in PHP out of the box.
January 2nd, 2008 at 2:38 am
hi Daniel again,
Ouch, very discouraging.
Xah
January 2nd, 2008 at 6:25 pm
Maciej Katafiasz asked Faré: could you expand on your point about lack of tail-call optimisation.
The `win’ for tail recursion isn’t the self-call case that can be trivially turned into a loop by the compiler, it is the callback case where a function takes multiple callbacks as arguments and invokes one in tail position. Without tail recursion, this will quickly overflow the stack unless you somehow force a limit on the number of pending chained callbacks. With tail recursion, there is no limit.
Oh. Hi, Dan, Faré, and Xah.
January 3rd, 2008 at 9:45 pm
Dan,
redshank mode provides some basic refactoring support as an add-on for SLIME: extracting expressions to variable and function bindings (taking care of free variables if possible), etc. This is work in progress.
January 9th, 2008 at 3:18 pm
I thought I read somewhere that ITA carefully inspects the assembly generated by their LISP compiler and allocates memory parsimoniously. *If that’s true*, then ITA doesn’t trust the compiler or GC enough to write “normal” LISP code. Instead, they are sorta’ side-stepping the compiler to write psuedo-C code. That’s why I would be wary of writing high-performance code in a high-level language.
If ITA writes LISP code this way, wouldn’t it make more sense to design a “C with parentheses” language? Compile to both C (for production) and LISP (for development and debugging).
January 10th, 2008 at 10:59 am
What you read about ITA would have been about the QPX program, which is ITA’s main product: the low-fare shopping and pricing program used by Orbix and many airlines and other parties. QPX is highly CPU-intensive, and some of the virtual memory in QPX is allocated manually. As I understand it, it is not exactly “normal” Lisp code. (I have never actually looked at the QPX sources, as I do not work on that product.) In fact, I believe that there are parts written in C or C++ (I don’t know) for dealing with very low level bit-manipulation stuff at high speed. You’d have to talk to a QPX expert to get the exactly correct story.
If the QPX guys do look at the generated assembly code, it would be to make sure that they are generating optimal code, rather than because they do not trust the compiler. I have talked to the QPX guys extensively about Lisp implementations. They are big fans of Steel Bank Common Lisp, which does in fact generate code that is quite good, at least by the standards of open source Common Lisp implementations. They would not be using it if they did not trust the compiler. At least one of the QPX guys is a serious open-source contributor to Steel Bank Common Lisp, and may well have made improvements in the code generator, which would be another reason to inspect the generated code.
I (and the majority of the Lisp developers at ITA, currently) am working on a completely different product, an airline reservation system. It is not CPU-intensive; rather it is an OLTP system. To us, the tightness of the generated code is of less interest. We write very normal Lisp code. We are currently using Clozure Common Lisp (formerly known as OpenMCL), which generates code that is not quite as fast, but has other advantages for us that we care about more, for the OLTP system.
Symbolics once designed and implemented a “C with parentheses” language. It was called “LIL” (Lisp Implementation Language), and was used to program the 68000-based Front End Processor of the 3600-series Lisp machines. (That was typical of Symbolics — invent a whole language just for one program!) It had C-like semantics: no GC, for example.
January 12th, 2008 at 12:59 pm
Name some of these “many [...] successful applications written in Common Lisp”, other than Emacs (your language’s primary IDE with the world’s worst text editor does not make a good case for you).
The syntax issue is not something that can be dismissed. It can and has been ignored, certainly, and by ignoring it, the language has been doomed to irrelevance. The vast majority of real, professional programmers know Lisp or Scheme, learned it in college, and have written programs in it. And we choose, overwhelmingly, every single time, not to use it, because it’s a hideous and unpleasant language.
It’s all about the syntax.
Logo was your only real chance to change that; it had Lisp’s semantics without the nightmarish syntax. And you Lispers ignored it and abandoned it. Since it has no support, there’s no libraries for doing useful work with it.
See here:
http://freshmeat.net/browse/160/
These are applications made by programmers in their own time, with whatever language they like. Lisp and Scheme are almost completely irrelevant on that list, a couple hundred entries.
January 12th, 2008 at 3:04 pm
For successful Lisp applications, see my survey paper and the sites to which it refers.
The syntax, which I consider elegant and highly superior, is largely a problem because people are unfamiliar with it. Emacs is the best text editor around and is highly popular. Of course, you are entitled to your opinions.
Few people learn Lisp as it is actually used in college. Most of them walk away thinking, well, Lisp is about lists (cons cells) and recursion. Then they get far more exposure to other languages, especially if they get jobs, where their employers make the decision about what language to use. Most employers will go with a language that is mainstream and popular, despite any particular merits or demerits, and there are many reasons that that’s a sensible way to make the decision.
There are plenty of other disincentives to use Lisp, as described in this blog post. It is not obvious which ones are the overriding ones. You have your opinion.
Actually, the language that I always felt was the best one to be considered a followon to Lisp that had conventional syntax was Dylan. Again, it never got traction, even though it’s a very technically good language.
I looked at the Freshmeat link that you provided. I see 91 Lisp projects plus 65 Common Lisp projects plus 149 Scheme, for a total of 305, not even counting Emacs Lisp. That’s more than Ada, APL, Basic, C#, Eiffel, Erlang, Forth, Fortran, Groovy, ML, Modula, Pascal, Prolog, Smalltalk, or Visual Basic. Sure, that’s way lower than the popular languages such as Java and C++; I would have been shocked had it been otherwise. Many of those have conventional syntax. The point is that a language being unpopular or out of style has a less to do with its actual merits, or its syntax, than you might expect.
January 25th, 2008 at 4:17 pm
[...] complain about Common Lisp. Dan Weinreb recently itemized and categorized the main complaints over on his web log. I agree with everything he said. In [...]
January 25th, 2008 at 5:49 pm
Are they fast? It varies between implementations. Some generate better code than others; and performance of libraries varies. But the leading implementations are actually quite fast.
Some of libraries are actually very slow, maybe because of the programmer’s mindset when using such a flexible and dynamic language as Common Lisp. See:
* Common Lisp has hashtables, which are incredibly easy to use. But they’re generic and can’t be specialized, so lots of people end up using inefficient hashtables. It would be nice to have a library that would allow me to declare the types of keys and elements, and maybe to also specify a *really* fixed number of elements (perfect hashing is not that hard);
* Type declarations and other optimizations are sometimes boring, and people take the advice of “not optimize early” to an extreme, and never optimize
* CLOS is very hard to implement efficiently, and there are tricks you can use in order to write efficient CLOS programs. But lots of people are somewhat fascinated by how easy it is to use and how flexible it can be, so they end up writing slow code (when it would be possible to write faster code that is almost as flexible and elegant)
But I could be wrong… I don’t know, really. This is just a wild guess, but those could be actual reasons for some libraries being slow.
January 25th, 2008 at 5:53 pm
Sorry about the last comment. It was more about libraries, and I quoted the part of your post about the implementation. I meant slow libraries.
But it’s also true that implementations don’t make it too easy to write efficient code. Few of them have block compilation; array access is almost always hard to make efficiently; CLOS implementations are not fast…
Of course, I’m not saying this is not implementors’ faults, I know they are doing their best. Implementing the Common Lisp standard and making it very fast seems to be very hard — but I do think it’s possible.
January 26th, 2008 at 4:16 am
Jeronimo: Which particular libraries do you have in mind? Slow compared to what?
I don’t find that using CLOS makes code slow. Do you have measurements to back this up?
January 27th, 2008 at 2:45 am
Hi Dan.
For example, I tried using Gary King’s red-black tree implementation to store double-float elements, with fixnum keys. That was much slower than just using hashtables (more than 10 times slower if I remember correctly). But a red-black tree isn’t supposed to be slow. (But it could be my compiler or something else that I did wrong)
I have been looking for a sparse matrix (tensor actually) representation library. I see that people usually choose hashtables for that, but CL hashtables are not specialized so there is an overhead. So I thought I’d use red-black trees, but it was even slower.
What I wanted was something roughly comparable (not necessarily as fast, but at most 2x slower) than a C++ std::map implementation. For example, this is one possible way to implement a 3-dimensional sparse tensor in C++:
std::map<unsigned int, std:map<unsigned int, std::map > >
std::map is implemented in g++ as red-black trees, which basically do binary search on the structure for most operations.
Anyway… I tried implementing something similar in Common Lisp:
cvector -> cvector -> cvector
where a cvector (compressed vector) is
(defstruct (cvector :type vector)
(values (make-array 0) :type simple-array)
(index (make-array 0 :element-type ‘fixnum) :type (simple-array fixnum (*)))
(max-capacity 0 :type fixnum)
(count 0 :type fixnum)))
I did generate the code for get, set and delete with macros that will add all kinds of type declaration. These macros will also simulate block compilation by using LABELS to create all functions that access the data structure. I optimized as much as I could.
Searching then is like doing three binary searches. But it’s 7 times slower than the C++ version.
(Insertion is horribly slow if the indices are inserted out of order, but I want this for mostly static sparsity structures, so that is not a problem.)
Anyway, I am now implementing AVL trees and see if switching from arrays to lists (used to represent the tree) will help.
The library is not ready yet, but here’s the link:
http://aleph0.info/spartns/
But my point is that this kind of thing (generating functions to access data structure) doesn’t seem to be natural for people working with Common Lisp. It’s easier to use CLOS, for example.
I’ll keep trying to work on some optimized libraries …
January 27th, 2008 at 3:02 am
There is also this old experiment that I did…
http://aleph0.info/clos/bench-clos.html
But unfortunately I can’t remember the versions of each implementation. But they were all faster using functions and structures than methods and classes.
Anyway — the benchmark is some months old and is just 120-second hack, so it could have problems…
January 27th, 2008 at 2:37 pm
I’m not much of an algorithms expert. However, I took a quick look at the Gary King package, called cl-containers. It looks very general and elegant. On the other hand, many Common Lisp implementations have carefully-optimized hash table implementations. It doesn’t surprise me at all that those would be faster than the red-black trees in cl-containers. In fact, I’ve never used balanced trees for implementing simple associations, in any language.
A lot of work went into the collections facility that was added to Java, and they seem to have found that a basic hash table implementation (HashMap) was the best way to implement a Map in nearly all circumstances. (Josh Bloch wrote this somewhere.)
I don’t see why generating functions to access data structures should not seem natural for people working with Common Lisp. It’s a perfectly normal and natural thing to do.
January 27th, 2008 at 6:22 pm
OK… So today I worked a bit more on the library, and it turns out that I finally got what I wanted.
- get and set individually are slow (there isn’t much that can be done here, I guess…)
- traversing the whole tensor depends on the representation: with hashtables, it is as slow as you can imagine. But with compressed vectors, it’s faster than hashtables an red-black trees. I mean, 10 times faster than the binary generated by g++.
I’ll update the library on the website and announce it soon.
May 22nd, 2008 at 11:59 pm
I’ve written Lisp code off and on for more than 20 years, including some big applications. And guess what? Lisp’s syntax is STILL awful, even AFTER you’re very used to it.
This is a lot harder to fix than people think, though. Lisp is homoiconic, and the obvious “fixes” to Lisp ruin that (making macros, languages built on languages, and other things fail to work). Logo’s syntax is easier to read, but it doesn’t really scale.
I’ve been working on how to retain all of Lisp’s nice properties, but with a friendlier syntax. If you’re interested, please visit:
http://www.dwheeler.com/readable
I’ve set up a low-volume mailing list to discuss various ideas.