briancarper.net (λ) (Tag: Arc)

Wish list

Tue, 17 Jun 2008 23:47:43 -0700

What's the Common Lisp version of Perlmonks or Ruby-forum? I have yet to find it.

comp.lang.lisp is largely crap. 50% of the traffic on that list is spam about shoes and fake watches. The other half is equally split between:

People debating tiny, silly semantic points of the Common Lisp Hyperspec.
People stuck in the 70's or 80's, talking about the good old days, ruminating about Lisp history.
Flame wars.
New people asking for help. Some get good honest advice and helpful answers, many are flamed and ridiculed into next week if they even hint that they dislike the parentheses.

The Common Lisp community (if you can call it that) is a bunch of really smart guys, but they all live isolated in hermit shacks up in the mountains and they spend their time doing magic tricks with Lisp that few people ever see, and if you wander too close they throw rocks at you.

What's the Common Lisp equivalent of perldoc or rdoc? We have the Hyperspec. It's an impressive document, but it's a bunch of painful HTML that looks like it was created in the early 90's, probably because it was. It reads like a dusty, dry, technical document probably because it is. What it's not, is friendly or easily readable.

Perl has CPAN, Ruby has rubygems, what does Lisp have? Either a hand-rolled system definition script, or if you're lucky an ASDF install file. ASDF is the semi-standard Lisp way of installing libraries, except that it doesn't quite work in Windows, it doesn't check dependencies or handle different versions of a package very well, and it doesn't work the same on all Lisp implementations. Many people in the so-called community think it's not very good.

The fellow running Lispcast makes another good point. Where can you download Lisp? It's not obvious.

You could say "OK Brian, good idea, now get to work!" The problem is that even if I had the time or willpower, I'm not the smartest guy in the world. I honestly don't think I could design and run and maintain a CPAN. And even if I did, would anyone use it? But I do know that there ARE plenty of smart, enthusiastic people using Lisp. Yet high-quality friendly code is largely not being produced.

Peter Christensen wrote about "langauge snobs" and the importance of community. One point made is that some really ugly, horrific languages have been extremely successful simply because they've been accessible and fun. An example given is the scripting language in Second Life, which has over 2.5 billion lines of code written in by tens of thousands of amateurs and has accurately modeled a realistic 3D environment with thousands of users at any given time. All in an ugly language some guy invented AND implemented in one week. The developers admit that the language is total crap, but it doesn't matter. 1) It has very good and accessible documentation, 2) it has a very newbie-friendly community, and 3) and it's easy to pick up, throw together some code and get immediate results. Three things Common Lisp lacks.

This is something I've said myself many times: an active, supportive, enthusiastic community is essential for the health of any programming language. Common Lisp simply doesn't have one and it's a shame.

I still secretly hope that Clojure or NewLisp or Arc turn out to be a huge success. They are the kinds of things Lisp needs today.

Lisp ramblings

Fri, 15 Feb 2008 00:09:06 -0800

Two posts in one, just because I can.

Rambling #1: One thing that makes a language like Ruby easy to read is that foo.bar always has the same meaning: object.method.

In Common Lisp you don't have that. One of CL's strengths is that everything looks the same, it's all s-expressions. However a cost of this is that you can't tell just by looking whether (foo bar) is:

A special operator foo, that does something with bar (maybe assigning it a value, maybe conditionally evaluating it, who knows).
A system-defined function call foo, where bar is evaluated and the result is passed in as an argument, and which you can't redefine because it's in the COMMON-LISP system package.
A user-defined function call foo, where bar is evaluated and the result is passed in as an argument, and which you can re-define if you want.
A method call foo, where bar is possibly an object used to dispatch the method call (or maybe not).
A macro foo, which can produce code that does practically anything, or nothing at all, with bar.
Other?

Along the same lines, even if you know for sure that (foo bar baz) is a method call, you can't tell by looking whether bar, or baz, or both, are objects which determine how the method call is dispatched. You have to look it up in documentation or inspect the method somehow. As far as I know. (EDIT: Slime has lots of tools for doing this kind of inspection., as was pointed out to me by Ivar.)

This is a good feature of Common Lisp, in terms of flexibility and power; multimethods are great, the consistency and lack of syntax and precedence is great in many ways. But it can be a bad thing in terms of easy readability. It's a bit of a tradeoff.

Ruby code like arr.reverse.sort.join(',') just flows right along. And it's highly predictable. I know reverse is a method call, and it's defined in whatever class arr is an instance of (or a mixin of that class, or a meta-class I guess), and it returns something that has a sort method. And I can redefine any of those things.

Common Lisp non-working pseudo-code: (join (sort (reverse arr)) ","). Not as much fun to read, and oops, in this case SORT is a system-defined standard function, so if I want to write this I'll have to go with MY-SORT or SORT2 to avoid collisions (which you see a lot of in Lisp examples and literature).

Rambling #2: Way back in 2006, I decided to learn Common Lisp because I'd heard such nice things about it. I ended up abandoning that project very quickly (only to try again late in 2007, and stick with it this time). One reason (among many many others) that I gave up was the fact that it took me a good hour or two even to figure out how/where to download and install Common Lisp.

I remember going to a terminal and searching the Portage tree for packages matching the name "common lisp". Zero results. OK, how about just "lisp". One result I got back was clisp, which at that time, based on the name, I assumed was "just another name for the Common Lisp interpreter". However a search of the Gentoo forums revealed that a lot of people were using SBCL, or CMUCL, or many others. And those things were "Common Lisp" too? How confusing.

Little did I know that there is no THE Common Lisp. There are a bunch of implementations of the Common Lisp standard (or varying parts of the standard). To a newbie, this is somewhat confusing. Which one should you pick? What the heck is the difference? If it's a standard, does it even matter which you pick? So before you can even start writing code, you get to treat yourself to a history lesson to learn why there are all these different implementations, and then go on a fact-finding mission to try to find an implementation that's right for you.

It wouldn't matter, if the standard was complete enough that it covered all of what you'd want to do. But the standard is old, and arguably out-of-date. And it doesn't cover things like threads, sockets, POSIX utilities, etc. that you're really likely to use. And if something isn't in the standard, you can bet good money that every implementation does that thing in its own way, or not at all. A lot of sufficiently complex code in Common Lisp will demand that you go to great lengths to get it to run on different implementations, judging by some of the library code I've read.

Consider CL-FAD. A function DELETE-DIRECTORY-AND-FILES is used to (you guessed it) recursively delete a directory and its files. Here are the guts of that function:

(cond ((directory-pathname-p file)
      #+:lispworks (lw:delete-directory file)
      #+:cmu (multiple-value-bind (ok err-number)
                 (unix:unix-rmdir (namestring (truename file)))
               (unless ok
                 (error "Error number ~A when trying to delete ~A"
                        err-number file)))
      #+:scl (multiple-value-bind (ok errno)
                 (unix:unix-rmdir (ext:unix-namestring (truename file)))
               (unless ok
                 (error "~@<Error deleting ~S: ~A~@:>"
                        file (unix:get-unix-error-msg errno))))
      #+:sbcl (sb-posix:rmdir file)
      #+:clisp (ext:delete-dir file)
      #+:openmcl (ccl:delete-directory file)
      #+:cormanlisp (win32:delete-directory file)
      #+:ecl (si:rmdir file)
      #+(or :abcl :digitool) (delete-file file))
     (t (delete-file file)))

What's going on there? All those #+ and #- lines are kind of like the Common Lisp equivalent of C preprocessor macros. #+ and #- hide (or include) a line of code from the view of the compiler, depending on which implementation you're using. Ugh.

So in this case, you have what is a pretty simple function (1-5 lines of code, in each implementation), but you get to have the fun of writing it TEN TIMES, all woven together like spaghetti. There are many other such compatibility layers.

Kudos to people who go to the effort of writing portable code like this, but I don't see why it should be necessary. This strikes me as a senseless and wasteful duplication of effort. Not just on the part of the people writing code to run on all these implementations, but also on the part of the people working on the implementations themselves. Why not join forces and make one big mature official Common Lisp for everyone to use? What benefit is there to having so many implementations? Does the benefit outweigh the amount of work someone has to do to write portable code to share with the community? Maybe there's a good reason for it that I'm not aware of. But it seems to me like it defeats the purpose of having a standard in the first place.

On the other hand if I want to write some Perl, I do an emerge perl (substituting your package manager of choice) and then I have Perl. The same exact Perl (barring version differences, and slight differences between Perls on different OSes) that every other Perler in the world has. If I write a Perl script, any other person with Perl could reasonably expect to be able to run it. Same with PHP, Python, Ruby, and many other languages. (People are working on separate interpreters for Ruby, e.g. JRuby but from what I know, they're going to great lengths to make it run EXACTLY like the "official" Ruby, even down to copying bugs to maintain compatibility.)

I know now that there are things like Lisp in a Box that give you an easily-installable Common Lisp environment. Which is really nice for learning purposes. I wish I'd have found it back in 2006 (if it existed at that time). But it only delays the mess you're going to have to handle someday if you want to write portable code, or if you want to use anything other than CLISP or Allegro.

I have an urge to start porting some of my favorite Ruby gems to Common Lisp. But I am not going to install 10 CL implementations just so I can re-write my code 10 times to get it working on all the Lisps in the world. Very likely my code would be ruthlessly SBCL-specific.

(This is one reason I'm kind of hoping Arc takes off. Hopefully there would only be one Arc implementation.)

Arc

Sat, 09 Feb 2008 03:30:02 -0800

There's apparently some excitement over Arc which is a new Lisp being designed from scratch by Paul Graham.

There are a lot of varied opinions in the Lisp world about this, I guess. Many people are saying Arc is no different than a hundred other failed attempts to make a new Lisp over the past 5 decades. On comp.lang.lisp Arc has been thoroughly derided (though it seems like almost everything is thoroughly derided on that list).

On the other hand, here we have something new in the Lisp world (everyone likes something new), and it has a big name behind it (everyone likes a smart and charismatic leader). I think those two things alone give it a shot. If there's anything PHP or Java or any number of other horrendous languages can teach us, it's that whether it deserves it on technical grounds or not, a big enough community can make anything a success. For some reason I can't help but think of the mobs of people begging drobbins to fork Gentoo. Hmm. Maybe if I forked my blog I'd double the amount of people reading it. (Oh right. Charismatic leader. Darnit. :( )

In all seriousness, I don't know enough to judge Arc or any of the other Lisp spinoffs (e.g. Clojure looks neat). I barely know Common Lisp to begin with. I've never tried Arc and don't necessarily plan to any time soon, due to lack of time if nothing else. But I do know that there are plenty of things about CL that I dislike, and can't help but think mostly everyone else also dislikes. Yet these things stay the same, for decades and decades.

(For example pathnames. If Common Lisp pathnames weren't so broken, it wouldn't have taken a whole chapter of PCL to write a wrapper that makes them usable. Yeah there are good historical reasons for the way pathnames are done in CL. But I don't care. I live in the present. If I'm transported back to 1980, I'll want to have 1980's style pathname libraries. And maybe in 1980, a function called ENOUGH-NAMESTRING meant something to someone? But what I need today is 2008 style pathnames. There are other things in CL that are just as crusty and awkward, and "historical reasons" are always touted as the excuse. These kinds of things kill me. Even if I fix them in my own code, chances are I'm going to have to read someone else's code where these things aren't fixed, and so it crusts up the whole community. Arc has a chance to fix all those things. Whether it'll take advantage or not is yet to be seen.)

I really do think that a large part of what determines the success or failure of a language is the amount of people using it. There's no doubt that if more people were using Common Lisp, all Common Lisp users would benefit. Even if most people are dumb newbies, dumb newbies eventually turn into worthwhile contributors if they stick around long enough. And even dumb newbies have a good idea now and then. It only takes one good idea. The community can take that one good idea, ignore all the other stuff, and everyone benefits. And even if a person has no good breakthrough ideas, there's a lot of grunt-work that needs to be done to keep a language healthy. Little libraries that aren't hard to write but still make everyone's life easier once they're written. Documentation. Community support, helping others with troubleshooting, introducing new people into the fold. These things are important. I'd love to see a Lisp with a community like Ruby'.s

Paul Graham's site says:

The Arc community is very newbie-friendly, because all the users are newbies to some extent.

And that is very refreshing, and maybe it's enough to get a critical mass going. But who knows.

Whether Arc dies a horrible death or is the next big thing, it's kind of exciting to be present at the birth of a language. I tend not to find out about things until they're already big enough to get everyone's attention. It's fun to watch Arc being born.

On Lisp (review)

Sat, 24 Nov 2007 22:09:32 -0800

Paul Graham's On Lisp is available in PDF form (and Postscript) for free download, so I thought I'd give it a read. It's an older book (early 90's) and you can tell. It has a lot of good knowledge if you can make it past some of the things that obscure the more relevant parts.

A lot of the code given in the book favors efficiency over simplicity and readability, which is probably a product of the book being 15 years old and written by someone who's clearly been programming for a lot longer than that. It's something I notice a lot in older books. Of course there was a good reason for it: you had to worry about efficiency if you wanted your program to finish before next year.

Given today's computers and the kind of programming I tend to do personally, I don't care about efficiency beyond making my code "fast enough". Very rarely does this ever mean manipulating my code to make it tail-recursive so my compiler can optimize away some of my function calls, which Graham devotes a lot of effort to in the book. Someone once said something about "premature optimization" which I'm sure everyone is familiar with and may apply here.

(But I have a ton of respect for people who programmed computers back when every clock cycle and every byte of RAM was precious. I'm not sure how I could've ever managed in that kind of world. Sometimes it seems like you had to be a genius to get anything done back then. Maybe necessity was the mother of invention though.)

Common Lisp was apparently just being standardized or being heavily revised when this book was written, judging by much of what Graham writes. A lot of stuff I read in Practical Common Lisp that Seibel glossed over as being "something the old-school Lispers used to do" is in full-effect in Graham's book, and a lot of what Graham mentions as "new" is probably very solidly standard nowadays. Graham uses lambdas for EVERYTHING: data storage, algorithm optimization, sometimes even just to introduce a new lexical scope. And our primitive friends the CAR and CDR and their many cousins make plenty guest appearances in this book, to the detriment of my poor brain.

Graham also glosses over a lot of the code in his book and leaves it to speak for itself, making this probably a book intended for far more advanced Lispers than I. For an intro to Lisp I still highly recommend Seibel's book; his code and prose are so transparent and easy to understand that it's a joy to read. Graham's book reads more like a math textbook.

If you can get past all of those things, there's clearly a lot to learn from the book. It's really amazing some of the things you can pull off in Lisp, and Graham gives a great demonstration. Many of the design principles that Graham lists as goals for his new language Arc are explained really well in this book, so it's worth a read if you're interested in that. It's funny that a book about Lisp often blurs into a book about programming language design, probably because as Graham says, when you write Lisp you often build the language up to your program at the same time you build your program down to the language.