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.

Saturday, October 17, 2009

LispForum membership is over 700 

Wow. I have been swamped with other things lately and didn't notice that LispForum membership has grown to over 700 people. That's very cool. We also passed one year of life back in June 2009. Ah, well, I sometimes forget my wedding anniversary, too. Unfortunately, my wife doesn't hack Lisp or she probably would have reminded me.


Holy needless asdf-install, Batman! 

Okay, so I decided to do a bit of hacking tonight that involved installing cffi. Before I started, for the first time in a long time, I actually upgraded SBCL and blew away my ~/.sbcl directory. Then I typed it:

(require 'asdf-install)
(asdf-install:install 'cffi)

Those commands managed to pull down 21 different packages! In itself, that might be the right thing to do for something that has a lot of dependencies, but after looking in ~/.sbcl/systems I found that I had:

alexandria.asd
babel.asd
babel-streams.asd
babel-tests.asd
cffi.asd
cffi-examples.asd
cffi-grovel.asd
cffi-tests.asd
cffi-uffi-compat.asd
iterate.asd
lift.asd
lift-documentation.asd
lift-test.asd
metabang-bind.asd
metabang-bind-test.asd
rt.asd
stefil.asd
swank.asd
trivial-features.asd
trivial-features-tests.asd
trivial-gray-streams.asd

So, that included five different unit test packages, plus the three different unit test frameworks (Lift, RT, and Stefil) dedicated to running them. I also got Swank thrown in. Honestly, I was waiting for the free set of Ginsu knives. ("But wait, there's more...!")

Here's the thing, people. When I install a package, I don't want your unit tests. Or the unit test framework necessary to run them. That's all just cruft that takes time, space, energy, etc. I mean, I'm glad that people are using unit tests and all, but as a user of your package, I shouldn't have to care about unit tests. Presumably, when developing/releasing your package, you ran your tests. That's all good. But if they passed for you, they'll also pass for me. Unless I'm going to start hacking your package, they're just a nuisance for me. If I am going to start hacking your package, I'm probably going to pull the source directly from git or darcs or CVS or Subversion, not asdf-install. At a minimum, can we all agree to remove dependencies on Lift, RT, and Stefil.

If I really want to run your tests, and I have installed them using asdf-install, I'm perfectly willing to install those other packages using a separate asdf-install command.

As for Swank, while I love it, again, if I want it in my environment, I'll install it separately, thank you very much.

Summary: Please keep your package dependencies to a minimum. If you really need to have a package that pulls in a huge set of dependencies to create a full environment (e.g. Swank and such), please separate your core library functionality from the top-level environment package and allow those of us with minimal tastes to simply install your core library functionality by itself.


Friday, December 12, 2008

LispForum members tops 450 

Nice! I went away on a business trip the early part of this week and came back to find that we're over 450 members on LispForum. 451 to be exact. I have been really happy with the discussions happening there. Lots of good info being exchanged and none of the attitude of comp.lang.lisp.


Thursday, October 09, 2008

SBCL dominates usage at LispForum 

We have been running a poll for the past couple of weeks over at LispForum asking people to tell us which Common Lisp implementations they use most. I don't think it would surprise anybody that SBCL is leading the poll, but it might surprise people as to the magnitude. Currently, with something like 97 votes in, SBCL has 53% of the votes. The next most popular implementation is CLISP with about 18%. This is followed by a tie between ClozureCL (OpenMCL) and Lispworks.

My takeaways here are the following:

  1. First, this poll has limited sample size. 97 respondents, all of whom are LispForum participants isn't necessarily representative of anything. LispForum has a lot of newbies (and indeed was created to help foster that), so it could be that all the old, crufty smug Lisp weenies hanging out on comp.lang.lisp have a completely different usage profile. Still, it's more data than I have seen anywhere else. Perhaps some of those c.l.lisp residents will register on LispForum and vote.
  2. My biggest takeaway is that SBCL has really moved beyond CMUCL. My hunch is that having a system that is relatively easy to build and is released on a regular monthly tempo is simply a superior value proposition. William Newman nailed it when he forked SBCL from CMUCL and created a healthy, vibrant community around it. I don't dare say that CMUCL is "dead," but clearly SBCL has taken that ball and run with it. CMUCL has only 1% usage in the poll.
  3. CLISP seems to be a common "backup implementation" for environments where SBCL doesn't run well. For instance, my own personal preference is SBCL on Linux and CLISP on Windows, at least for the time being. I'm also using ECL for a project I'm working on right now, primarily because it has a small memory footprint and low performance requirements.
  4. Lispworks is certainly leading the commercial implementations. The low price for a high-quality implementation is probably the big draw there. IMO, if I wasn't using any open source version of CL, I'd probably be using Lispworks.

LispForum hits 350 

Well, we hit over 350 registered users on LispForum just the other day. Thanks to everybody for their interest and participation. Lots of good topics being discussed.


Monday, September 22, 2008

PHP vs. Lisp: Unfortunately, it's true... 

I just found this today while browsing Reddit: Practicality: PHP vs. Lisp?

This is exactly the psychology that goes through the head of everybody who hears about Lisp and decides to check it out. Summary: Lisp is awesome, except for the multitude of trivially annoying things that make it much less so, to the point that everybody just throws in the towel and uses PHP or Ruby or whatever.

I hate reading articles like this because I know that it's basically all true. I also know that within 24 hours, the comments section of that blog post will be filled by Lisp apologists who keep suggesting workarounds and fixes. These are the same people who went nuclear a couple of years ago when Reddit got rewritten in Python, and it's all the same old arguments.

If Brian Carper's blog post annoys you, stop apologizing and start innovating. Languages exist in a market place and right now Lisp marketing itself quite poorly. Yes, I know that "marketing" is rejected by techie types who think that it should never matter, but as a marketing guy who markets to techies, I'll tell you that it absolutely does. And those who reject marketing will flat-out lose to those who understand it.

As a "customer" of a particular language, nobody wants to hear how their particular issue is unimportant in the grand scheme of things. Nobody wants to hear that such and such a problem was "solved" 20 years ago with this particular hack or workaround that only Lisp gurus know about. Nobody wants to hear that it's a simple job to port that particular library over to that particular implementation. People have a ton of free language options these days, and if Lisp isn't going to compete in terms of ease of use and productivity, then people will choose languages that will.

Note that theoretical ease-of-use doesn't count. Everybody will probably admit that Lisp macros are all-that-and-a-bag-of-chips, and building DSLs is way more productive than writing boilerplate code, and nevermind CLOS and closures, etc. Those are GREAT things that Lisp brings to the party, but they are completely useless if a newbie can't crank out a web page in 30 minutes like he can with PHP.

If you step back for a second and really try to listen to the arguments against Lisp, you'll find that there are two classes of gripes: fundamental dislikes and competitive disadvantage. Things like griping about the parenthesis are a fundamental dislike. Some people don't like parenthesis. Fine. Lisp is not for you. Parenthesis and sexprs are pretty fundamental to Lisp. They're part of its DNA. If you don't like them, then you don't like Lisp itself. There's no issue with that. Just use something like Java. Most Lisp programmers hate Java syntax, too. If you're really enlightened, take a look at Dylan. In short, as a guy who likes Lisp, I'll defend Lisp's parenthesis until I die.

The other type of gripes are about competitive disadvantage. These are issues that are not fundamental to the language itself, it's just that the Lisp community hasn't done much to solve them. Things such as having a reasonable set of standard libraries to do programming in today's Internet-connected world have nothing to do with the fundamentals of Lisp. Library documentation and tutorials would help. Having a decent system for the installation of libraries that doesn't depend on little-known and sometimes unmaintained web servers would also help. Everything in this category is hard to defend, and Lispers should universally be ashamed of it. Imagine saying to a "customer" something like, "Yes, I know that everything is undocumented and the installation infrastructure is unreliable, but you know, that's a feature." Rubbish!

In short, while somebody, somewhere, will always be griping about Lisp, the Lisp community, all of us, could go a long way toward making all those gripes fall into the "I hate parenthesis" category rather than the "There aren't any libraries and what libraries do exist don't have any documentation." There is a lot of work to do. Let's get coding...


Saturday, August 16, 2008

Lisp Quiz #1: Minesweeper 

A couple of folks were discussing the need for a Lisp equivalent to Ruby's Ruby Quiz the other day on LispForum. Ruby Quiz was a great way to learn Ruby. It presented a series of programming tasks that were somewhere between a simple exercise at the back of a textbook and a full ICFP Programming Contest challenge. The goal was to give budding Rubyists a meaty problem on which to test their skills, while not serving up something so difficult that it would take weeks to accomplish.

Well, I'm pleased to say that yesterday we took the plunge with the first quiz. The challenge is to write a simple algorithm (AI?) for playing Minesweeper. The game engine is delivered as part of the challenge, so there is no need to actually worry about the mechanics of Minesweeper. Just focus on creating an algorithm that will work its way through the minefield without choosing a mine.

The 48-hour No-Spoiler Period expires at ~5:00 PM PDT tomorrow. Check out LispForum to post your solution or discuss others.


Monday, July 14, 2008

Two weeks of LispForum 

Well, it has been just a bit over 2 weeks since LispForum went live. We've had over 160 people register and some good discussions break out on everything from Lisp web programming to GUI toolkits for Lisp to what everybody is working on that involves Lisp.

If you haven't checked out LispForum yet, drop in and see us. You'll find a small but growing community of Lispers sharing ideas and having fun.


Friday, June 27, 2008

LispForum, open for business 

The other day, I realized that there wasn't a great place to discuss Lisp that was using a post-Y2K sort of interface. Sure, comp.lang.lisp has been around forever, and through Google Groups it has an HTTP interface, but when you post to Usenet you become an instant spam magnet. And new users think an all text-mode interface with no markup is just so 1985. And yes, there's always #lisp on Freenode.net IRC, which is great for realtime, but bad for searching for coherent answers.

So, I created Lisp Forum: www.lispforum.com

The content is a bit sparse right now. That's where you come in. Please register, hang out, and participate. My goal is to make this a friendly place with a bit less Smug Lisp Weenie-ness than comp.lang.lisp, suitable for both newcomers and old pros.


Forth Timelessness, a Redux 

The other day, I discussed languages which I thought were timeless. Among them, I listed Lisp, C, and Forth. After writing that posting, I spent some time playing with Forth again. Today, while browsing Reddit, I stumbled on this interview with Charles Moore, the creator of Forth.

Forth is one of those languages, like Lisp, that I'd recommend that everybody study at least for a time. Even if you don't walk away believing it's the Language to End All Languages, you'll be better off for the experience. In fact, Forth shares a lot of fundamental attributes with Lisp while at the same time appearing almost completely different to a programmer writing code.

Some of the shared attributes include:

  1. Forth and Lisp both erupt from a very small nucleus of fundamental constructs. As Alan Kay has described Lisp as being "Maxwell's equations of sofware," similar statements would also apply to Forth. Both Forth and Lisp are fundamentally simple as a result. Sure, the libraries could be huge, but learning the actual language itself, the core rules, requires no more than a few minutes for each language. With both languages, there is a set of advanced rules (things like macros for Lisp or compiling words for Forth), but the basics are trivial.
  2. Forth and Lisp are duals of each other when it comes to their syntax. In both cases, the programmer is essentially handing the system a direct representation of the parse tree. The parsers for each language are trivial. Lisp uses prefix notation, whereas Forth uses postfix: "(+ 1 2)" vs. "1 2 +" for example. The use of prefix notation semi-requires delimiters to be inserted, giving us Lisp's beloved/hated parenthesis. With Forth, all computation revolves around the stack. Because the operation always occurs after the parameters are pushed, you don't need the delimiters. Words simply consume whatever parameters from the stack that they want to. One implication of this, however, is that you can do things like "(+ 1 2 3 4)" in Lisp. In Forth, this ends up being either "1 2 + 3 + 4 +" or "4 3 1 2 + + +".
  3. Forth and Lisp are both extensible. When you create a new function or macro in Lisp, you're extending the language itself. Your new function or macro is a peer with everything else in the language, not a red-headed stepchild. Similarly, with Forth, a word is a word is a word. You can create Forth words that interact with the compiler and do all sorts of crazy stuff. Most Forth systems also include an assembler so you can create high-performance, primitive Forth words as well.
  4. Forth and Lisp are both interactive. They both use a REPL. Forth doesn't call it that, but that's what it is. The benefits of this are similar in both. You tend to code a little, then test a little, then code a little, then test a little. In the interview with Moore linked above, you can see where he talks about the speed at which things got developed as a result of the interactivity of his Forth system.
  5. Forth and Lisp both include a compiler. I guess this really isn't a fundamental attribute of Lisp itself (you could be fully interpreted), but most Lisp systems do have a compiler. In some cases, that compiler can be pretty simple and primitive. In other cases, it could be very sophisticated (CMUCL/SBCL). With Forth, the compiler for threaded code is both fundamental and at the same time trivial. More sophisticated Forth systems can create more complex compilers (subroutine threading, superoperations, etc.), but those are not required.

All that said, Forth and Lisp are also very different:

  1. Typically, Forth operates at the machine level, with very direct exposed representations for objects. Forth programmers think in terms of machine words, bits and bytes. In some parts of a given program, a given bit pattern will represent a character or pointer or whatever, but from Forth's point of view they're all just bit patterns in a machine word. In contrast, Lisp programmers operate a higher levels of representation with first-class status for things like symbols, numbers, characters, etc.
  2. As a result of this "level difference," Forth programs are more memory efficient than Lisp programs, but they're also more dependent on the underlying machine fundamentals. For instance, if you changed the word size of the machine, a Lisp programmer probably wouldn't be aware of it. A Forth programmer might have to scramble to rewrite a good portion of the code. But very useful Forth programs are measured in KB of size, not MB.
  3. A big difference that typifies the issue of operating at the machine level vs. higher levels of abstraction is that Forth doesn't include any GC capabilities. All memory management must be done manually by the programmer.
  4. Forth isn't very tolerant of program bugs. Because you're operating at the machine level, when things go wrong, you might end up with a crashed machine. The Forth response to that is to just push the reset button and reload the system. Because the compiler is so fast, you'll be back to where you were before the crash in no-time. In contrast, Lisp makes a lot of effort to land the programmer in an interactive debugging shell when it detects an error condition.

Note that people have proposed systems which bridge between the two worlds. Factor is basically a Forth stack machine and syntax, augmented with high-level, Lisp-like data types and a GC. The result is a system which delivers Forth-like syntax with a Lisp-like debugging and development environment. Depending on your point of view, you'll either think this is the best of both worlds or the worst.

For me personally, I like both Forth and Lisp, but I'd use them in completely separate domains. If I was working on a deeply embedded project, where I'd want to be close to the machine architecture and where I had only a few KB into which to implement the program, I'd choose Forth. If I was writing a large application that would be running on a server with GBs of memory, I'd choose Lisp. Each works well within its target domain and the advantages of each are nearly the same: a small, extensible language with an iterative, interactive development environment.

As for systems like Factor, for me it's a "tweener" that doesn't fit my needs. By getting away from the machine details, adding high-level data types, GC, etc., Factor necessarily pushes itself out of the embedded world. You simply won't have microcontrollers running Factor. And if I'm going to be running on a system with an underlying operating system, a large graphical display, and GB of memory, I'd rather do my development in Lisp. While I like Forth, I find that Lisp's sexpr notation more closely matches my thinking model. With Forth's implicit stack, I have to be thinking all the time about what data values are at what positions on the stack. I'd choose to deal with that for an embedded design to get all the other attributes of Forth in that environment, but with fewer constraints, I'd choose Lisp over a "Forth with high-level data types and GC" like Factor.

Now, that's just me. For you, Factor may be the ticket. Slava Pestov is not an idiot (and you can quote me on that, Slava). As Factor's creator, he has obviously built a system that works well for him. Other people who seem to have far better programming skills than I do are working with Factor, too. The development environment they have put together seems to have borrowed a lot of ideas from Lisp machines, and I could see the Factor environment being really productive.

Whatever you choose, realize that all of these languages have some things they share. And fundamentally, both Lisp and Forth are timeless.


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