Smoothing the way

Periodically, I like to ego-surf to find out what people think of Cusp. It's usually complimentary, which is always nice to see (even if they tend to call it "CUSP"), but I like to keep a special eye out for people who are having issues, since that usually points me toward ways I can improve the experience for people.

Recently, I ran into this post. The author had a load statement in his file that just wasn't working. Why? Because he was calling it merely "file.lisp." No absolute path was given, and since sbcl is almost certainly not being run in the same directory as that file, it's not going to be able to find it without more information.

The sad part for me is that I'm not entirely sure there's much I can do for this kind of problem. Firstly, a person could very easily have multiple projects going at the same time, so determining the proper working directory is a chancy thing. Even then, automatically shifting working directories is the kind of anti-feature that soon causes more trouble than it saves.

This isn't an issue isolated to this one guy, though. Judging from the comments and recent posting on the Cusp discussion boards, others have tried to do the same thing. I think the real answer here is actually to educate people on the usage of asd files, and to get them to treat them as project files. I intend to add some comments to the auto-generated asd files to get people on the right track, but that's probably the best I can do.

Sadly, I couldn't resolve that issue technologically, but I was able to do something about one of the comments on that entry. The problem? When you create a new project, Cusp automatically wraps it all into a new package. Once you know what you're doing, this a very nice thing, because it is what you should be doing anyway. But when you're completely fresh to Lisp, you're not likely to realize that the stuff in the file is going to one package, while the Repl is sitting in another.

The fix was easy. Now when you make a new project, the REPL is automatically switched to that project's package. 99% of the time, this is what you'll want to do, and it should allow newbies to experiment without first having to learn all about the packaging system.

Credo

Starting with Lisp is a daunting task. First you download SBCL. Then you check out SBCL from cvs, and use the version you just downloaded to compile a new one. Then you download some flavor of Emacs and install it. Then you download the latest release of Slime. Then you go back and do a cvs checkout of Slime instead, because the last release is nearly two years old. Then you customize your .emacs file so that Slime can hook up to lisp.

Ok, so that was a great big pain, but at long last, you're ready to try out the most advanced language ever! You cross your fingers and fire up Emacs. Behold!

This is the face of the most advanced and powerful language ever? The development environment clearly hasn't taken advantage of any advances in user interface since the 70's. If the development environment hasn't evolved past the command line, can we really expect better of the language?

And what if you don't know how to use Emacs? Now you have two problems. Your early forays into Lisp are going to be frustrating and slow as you struggle just to edit text using a program which acts like no other. This is surely going to taint your perception of the language itself. How many newcomers turn away in disgust at this early stage?

And we haven't even mentioned the library situation yet.

Enter Cusp. Cusp was made with two goals in mind:

• Provide a high quality Lisp IDE with all the amenities that users of modern IDE's have come to expect.
• Ensure that it works straight out of the box.

I may be biased, but so far I think it has fulfilled those goals quite well. But there's always more work to be done. Join us!