LispCast

I would like to make a distinction between two different kinds of "solved" problems in the software world.

The first, and least useful, kind of solution is the "existing software" solution. That is, for a given problem, one can find a software solution that will meet your needs. For instance, if you need a web server, you can always use Apache. That kind of solution falls into this category.

The other kind of solution is more important. A solution in this category carries with it an understanding of the problem sufficient enough to write software to solve it. It comes in the form of cultural artifacts: books, papers, and other communications. If you needed a web server, you could create one yourself with the ideas and abstractions from the solution. I don't think it exists (yet) for HTTP. If it does, I'd love to learn about it. It does exist for sorting.

Both kinds of solutions are necessary. But I would like to find more solutions of the second kind. And this is perhaps the ultimate goal of Computer Science.

When a student of carpentry wishes to learn to build a ladder, he might study an existing ladder. He may learn to make each part. And by so doing, he will learn powerful, reusable concepts. He will learn the function of a rung as structure and step. He will learn the value of precision in making a hole for each rung. He can then use those concepts to build a fine ladder.

In order to learn, he may also disassemble a ladder and rebuild it from those parts. He will have a good idea of how the pieces work together. And given good parts, he can build a fine ladder.

I wish to do this with software. I should be able to study an existing piece of software and learn its "parts". Then I can build a new one myself that suits my needs.

Or, having found a piece of software, I wish to decompose it to a certain level of abstraction. And using those abstractions, build my own software, roughly equivalent to the original.

These are two kinds of reuse: reusing the parts and reusing the ideas. I wish to do more of these by studying existing software. I feel that it would advance my art tremendously.

I am back from OOPSLA. I had a great time.

While I did enjoy some of the tutorials and talks, what I enjoyed most was spending time with other Lispers. It seemed that we had a lot in common. When we parted ways, I was sad. I look forward to seeing them again at ILC 2009 in Boston.

That being said, if you have never been to OOPSLA, I would recommend it. The jeers and jokes I get from my colleagues about liking Lisp are non-existent. Even people I talked to who had never used Lisp were either curious or had constructive reasons for not using it. That was refreshing.

And if the Lispers I met at OOPSLA were representative of the Lisp community in general, I would say that I can recommend ILC 2009. I've never been to one before, but I will try my best to make it next year. See you there.

With only a few breaks, Lisp50 went from 8 am to 9 pm Monday at OOPSLA. The main topic of discussion was the history of Lisp. It was a long day, but it ended very optimistically focusing on the future.

Richard Gabriel and Guy Steele went first. I missed the first part of the talk, but it was a reenactment of a talk they gave a couple of decades ago. Complete with narration read by Pascal Costanza. It was a very modern meta-talk. I got the feeling that if the talk was relevant after 20 years, Common Lisp has stagnated. But this is not news.

John L White shared his recollections for a while. It was hard to follow --- it wandered around. I got the feeling that it was more about him than about Lisp.

Herbert Stoyan recounted much of the history of Lisp. I was excited to hear it, though I think there is so much more to know than he could possibly recount in forty-five minutes. I wish I could know more detail. There was a mention by Richard Gabriel that John McCarthy was a horrid programmer.

Pascal Costanza gave an explanation and demonstration of ContextL. I had read a little about it, but I have never used it. It looks really interesting. While he was demonstrating it, I got a sense of the expressive power it gives you. I had ideas for using it in some of my projects. I might make a video of it.

Guy Steele interviewed John McCarthy over the phone. John McCarthy was sick and couldn't come. It was interesting to hear his opinions on programming languages. He focused mainly on code as data and readable syntax. He seemed to want to codify common sense.

Warren Teitelman talked about developing Interlisp. He created a lot of the debug and exception facilities we take for granted today. He also developed some facilities for making his programming sessions more productive. Specifically, he created automatic typo correction, among other things. What was revealing was how personal the motivations were. He developed what would make his life better. His spellchecker knew the kinds of errors his keyboard typically made: sticking keys and a clunky shift key. So CONDDDD was converted automatically to COND and 8cond was converted to (cond.

Fritz Kunze gave a talk. Main conclusion: programmers have Asperger's and Common Lisp is dead. I have no comments on either of those ideas.

Kent Pitman gave some good stories about how he came to be the main editor of the Common Lisp ANSI Specification. It was a combination of luck and seizing opportunities. Kent was nothing but modest. I enjoyed the talk.

William Clinger gave a great presentation on Scheme. He was eloquent and honest about the strengths and weaknesses of Scheme and its community. He was very sharp.

Rich Hickey presented his programming language, Clojure. This was the talk of the day. Clojure is a Lisp dialect that runs on the JVM. It's got a growing community, a lot of innovation, and a buzz of excitement. It looks fantastic from the presentation and I can't wait to try it out. On top of that, the older Lispers seemed excited. The torch was passed. The presentation was well-timed. The whole day seemed to lead to the idea that innovation was important, Common Lisp was a political compromise and not a technical ideal, and that something needs to be done. Then came Clojure.

The panel discussion was decent. There was a confirmation of the innovative coolness of Clojure and its potential for popularity. It was also expressed that Common Lisp needs a package management system. Kent Pitman reiterated that Common Lisp was never supposed to be the end---it was just a way to define a fixed-point to standardize on. But innovation has slowed significantly. Some advice on what the standards body should have done differently was given, but I don't remember it specifically.

My first day at OOPSLA was enjoyable. I attended a nice tutorial in the morning and worked the info booth the afternoon.

The tutorial was a hands-on object-oriented design activity.

Tomorrow, I'll be at Lisp50 all day. See you there.

I arrived in Nashville this afternoon. I'm here for OOPSLA 2008 and for Lisp50, the fiftieth anniversary of Lisp. I'll be working as a student volunteer, so I'll get to the convention center early tomorrow morning. I believe I will be working the OpenSpace portion of the conference.

If anyone reading is also at OOPSLA, or if you are in Nashville for any reason, it would be nice to get in touch and meet fellow lispers.

And I'll try to blog from the sessions I attend. There will be a few interesting talks at Lisp50 that I am looking forward to.

See you around.

I have finally gotten myself to work on the eighth episode of LispCast. Yes, it is on it's way. It's actually rendering right now. Then I have to upload it. Expect it soon.

As those who have seen the other videos know, I recorded them on a Linux box. I figured out why I had so much lethargy to overcome: the state of Linux screencasting is abysmal.

I used XVidCap because it was the only thing that worked. And by "work" I mean both sometimes it didn't crash and the video files I got from it were readable by the video editor. Seriously, I must have tried all the software.

This time, XVidCap crashed every time I hit the record button. After a day of tinkering with it, I tried changing my video driver. That made it work better. Now it was only crashing occasionally. After fiddling with it, trying over and over again, I finally got videos that I could show to the world.

And I didn't even want to start trying to use Cinelerra---my normal video editing software. It crashes continuously. But it is also the most powerful tool there is on Linux.

So I decided to use my Mac to record video. It's well known that video is easy on it. And I don't have a Windows box. I bought Screenflow and I've been using it pretty happily since. It hasn't crashed once. And after you get past the Mac pseudo-user-friendly interface, it's actually not bad. I've been playing with what to put in my video, not how do I get this thing to work without crashing. That's a much more pleasant experience.

Episode 8 (which is rendering as we speak---it's coming) is a mule: recorded half on Linux and half on Mac. It will be more than watchable. But it will also end the series. I'll start a series of shorter, hopefully better produced videos now that I've put down cash for better software.

What to expect from the new videos

• Higher resolution. Why not record at full-screen?
• Shorter but sweeter. I developed an application before. New videos will probably be more look-at-this-feature or hey-look-what-I-did in feel.
• Shiny and Cocoa
• Better produced. Embedding graphics, callouts, and other fun things is easier
• More plentiful. It shouldn't be as much of a chore to get it going.
• Quicktime. Sorry, open-sourcers: I have had so much trouble with OGG that I'm just giving up.

I'm always open to suggestions as to content. Leave a comment if you want something in particular.

And stay tuned for the next video.

A while ago I posted an article called "Java is not Object Oriented". It was about the direction Java is evolving. But I came to regret my choice of title. People were thrown off. Many comments were insulting. Many comments just missed the point. I knew that I had a good, clean, controversial topic.

So I was very happy when I saw this post today. Neal expresses it better than I ever have. To quote him: "In the same way that C isn't a \"Non-GOTO\" language, I contend that Java is no longer an object-oriented language." This is my point exactly.

If you are intrigued by the idea, read The Paradigm Cycle and Java is evolving.

Brian Carper wrote this response to my article. He describes a true-to-life situation where PHP is just more practical than Lisp. And the situation is more common than I like to admit. But it is common. And it dictates many of our choices as developers.

My question is this: how did PHP get so many libraries, get installed on so many computers, and attract so much developer attention in the first place? I've written about how abysmal Lisp is at helping the newbies. (Yes, I said it. And I'm not afraid to delete stupid comments about how it really is simple to install and get started with Lisp. You have been warned.)

There are some who agree with me. Dave Roberts responded to Brian's post, and does much to elucidate the problem. To summarize: Lisp is marketing itself poorly. Lisp either needs to get competitive on the ease of use and productivity front, or lose programmers to other languages.

Dave also brings up another point, which is that there are two classes of complaints about Lisp. One is fundamental complaints about the language. These are about unchangeable things in the language. Like Common Lisp having dynamic typing. You can change how people feel about it, but the nature itself won't change.

The second class are complaints about the Lisp reality. Are there libraries for what you want to do? How easy is it to install? What's the learning curve? These can change. A complaint of this type is a call to change the reality.

I envision a world where Common Lisp is easy to install. Where up-to-date, fun tutorials guide the newbie through the world of Lisp. Where libraries abound for every purpose. And each has a website with forums for discussing its use, and good documentation. Where installing those libraries is as simple as calling their name. Where people cry out into the blogosphere that their favorite language must emulate the awesomeness of Lisp -- and people envy the keyboards Lispers type on.

Lisp is a little behind on these fronts. But it doesn't have to be. Lisp can be leading the way, much as it has always done in the past. We can show people what Lisp offers in terms of productivity by being incredibly productive. Let's make the first impression of Lisp elegant, to highlight Lisp's elegance. Let us mimic Lisp's power in the forging of our own community -- by melding flexibility, dynamism, and expressivity -- into a force as yet unknown in all the internet.

The day will come when Lisp won't be cast aside as a quaint relic of bygone days. On that day, Lisp will be seen as equal to the big languages. And it will learn from and share with them as peers. On that day, Lispers will say to PHP guys "Hey, I didn't know PHP could do that. That's pretty cool." And the PHP guy will say "Wow. Parentheses aren't so bad once you get used to them." I hope to see that day.

Friend: What's your favorite programming language?
Me: At the moment, Lisp.
Friend: Lisp? How can you like a language that doesn't have a FOR loop?
Me: Uh. Lisp does have a FOR loop.

Has this ever happened to you? That someone has serious misconceptions about Lisp? It has happened to me explicitly three times so far. And I think other people I talk to have similar misconceptions, though they haven't come up.

I talked to this friend a little more about why he thinks Lisp doesn't have a FOR loop. He eventually explained that he had to use Lisp at university. They used it to teach recursion and functional programming. So they conveniently left out all of the parts of Lisp that weren't part of the purely functional curriculum.

The other friends have similar errors in their understanding of Lisp, and for similar reasons. Another friend, whom I respect as a great programmer, serious thinker, and astounding understander of all things computer science, did not know that Lisp allowed side effects. He was under the impression that Lisp was a purely functional language.

Lisp is seriously misunderstood out there. And its nobody's fault. You can't blame the programmers with misconceptions. They were taught incorrectly. Whenever someone makes a face when I say I like Lisp, the first thing I do is explain that it has a FOR loop. In fact, it has more looping constructs than their language. DO, DO-LIST, DO-TIMES, and you can't forget LOOP. Man, LOOP makes looping fun, simple, and easy. And you can do almost anything with it. Plus you have recursion on top of that, when it's convenient. And usually they wind up curious to learn more.

I hope university professors hear this message and switch to teaching Haskell or any other purely functional language when they are teaching purely functional programming. It has lazy evaluation, strict typing, and it's side-effect free. Lisp is misunderstood enough. But be nice to people who were taught the wrong thing in college. They might turn out to be real fans.