<grammar weenie>Just noting a common misconception - "wherefore" as in "wherefore art thou Romeo?" means "why" not "where." In the often repeated quotation, Juliet is bemoaning that Romeo is a Montague and she a Capulet, not wondering where he is. The line that follows is "Deny thy father and refuse thy name."</grammar weenie>

As for LISP IDEs, I use vim:)

And I also wrote "where for" instead of "wherefore".

Lots of people have used "Where art thou" in titles, which I think is what I should have used.

Unfortunately I can't change it without breaking any links, so I will now forever have an idiotic title!

Adrian is right- I tried to keep my book fun and about Lisp and didn't think a discussion of IDEs was fun or informative about Lisp. However, this has tripped up some readers, so the second printing coming soon will have some limited discussion of these issues, and lisp file handling as well, to get people started in the right direction.

-Conrad Barski

Please leave a hint here or at /r/lisp when this second printing becomes available. Thanks. My personal preference would be to not include IDE-specific info into the printed book at all (other than maybe mention Emacs+SLIME as a de facto standard) but to make them available as webchapters only.

Also, if I may add, I think that using snipurl.com as a URL shortener in a printed book, for example for pointing to the Hyperspec, was a really bad idea. snipurl.com, like any other link shortener, may be short-lived and going out of business over night (think of tr.im), rendering all the printed links useless and seriously devaluing your book. So if there is any chance to change this for the second printing, by god, remove the link shorteners from the printed text! Anything, footnotes or a references page at the end with full URLs, is better than this.

It's not too late to add the full URLs to an errata page, too.

That's a minor nitpick on a great book, though. :)

Cool! Just some advice on using A Random Editor and loading files with "load" would be enough.

Thanks for the comment and the great book!

You definitely kept your book fun, and thank you for writing it. Though some mention of Lisp files would be handy. You sort of have to figure it out on your own now, or get through the entire book in one long REPL session.

I'm wondering how well other languages are supported by multiple IDEs.

If you want to develop for iOS and OS X, it's hard to avoid XCode and Interface Builder.

Isn't Windows development largely dominated by Visual Studio? (I could be completely wrong about this, as I haven't done any Windows development outside of Visual Basic many years ago.)

It seems that various dialects of Smalltalk are strongly tied to their own IDEs, by design.

I believe that Python, Ruby, and Perl still subscribe to the "pick your favorite text editor with syntax bindings for the language" development philosophy.

For Lisp, the problem is that Emacs + SLIME is such an outstanding development environment already, that it forecloses the "itch scratching" motivation of experienced Lisp developers to write something else. They sometimes give it a shot to welcome new Lispers, but their heart is not in it the way it would be if they needed it for themselves.

(And of course, this ignores the paid IDEs, which are also very good.)

I think I'm going to put an emacs config file online that I made for a friend of mine that mimmicks keybindings that windows users are used to.

I think there was a project to do that - and smooth out another few emacs quirks. I don't know how much it's being maintained though, but it was built by Xah Lee (afaik).

http://ergoemacs.org/

Is there an os x equivalent? I'd be interested...

Aquamacs is emacs with osx styling, I've heard good things. http://aquamacs.org/

Neat - just tried it and it seems very polished. Just got to get my head around emacs now.

Ah, you're right. I thought ErgoMacs had its own unique keybindings but it copies the default Windows keybindings well enough.

IDEs are hard.

Java was around for almost a decade when Eclipse became really mature... And Java was a language that was designed for GUI development from the very beginning, however, the Eclipse team had to develop their own windowing toolkit from scratch to get something that could swing that load.

The Python community has dreamed of a Python-based IDE for as long as Python has existed, but it faces two roadblocks: (i) there is no 'standard' GUI toolkit for Python and certainly none with the required maturity and (ii) it isn't easy for an IDE to reason about dynamically typed code (also not as necessary... Eclipse substantially lowers the 'verbosity tax' that makes Java programming so wet.)

Part of the problem is that an IDE requires that people who are passionate about programming get together with people who are passionate about designing user interfaces. GUI programming is particularly expensive, especially for open mixed initiative applications such as moderns IDEs. The kind of person who is 'hyperproductive' in LISP (or any other language) tends to avoid the morass of GUI development, where you can spend months and months going back and forth with designers and customers making sure the app correctly supports every interaction that would be intuitive to end user.

Now, LISP does have the advantage of being easy to reason about (since the program is also data) but it's fair to say that a really good IDE costs millions and millions of dollars worth of programmer time to develop. The core of Eclipse/Java was developed by professional programmers working around the clock. The community contributed plugins for Eclipse, such as the PHP and Python modes, are just a joke in comparsion... In some sense they're a step up from vi, but they're an embarassment if you compare them to Eclipse/Java or Visual Studio/C#.

JBuilder predated Eclipse and was a lot more usable (IMHO); it came out 2 years after Java was released. It started out written in Delphi though, and only later transitioned to Swing. I think it's also a push to say Java was designed for GUI; AWT was very much a hack.

Some of my favorite IDEs are written in Delphi: LispIDE and Dev-C++.

> Now, LISP does have the advantage of being easy to reason about (since the program is also data)

Is this true? Could you (or someone else) elaborate? I would assume that an editor trying to reason about Ruby or Python code would parse the source code into an abstract syntax tree, and that would be just as easy (or hard) to reason about as Lisp, since those languages are all dynamically typed.

However, I'm pretty ignorant of how tools like Eclipse reason about Java code, so this is all just guessing.

Well, the advantage of a language like Java or C# is that the IDE knows the types of objects, so, for instance, it can autocomplete method and property names. Because introspection is used rarely in static languages, IDEs can do automated refactoring operations and KNOW that they found all the (non-introspection) references that are affected.

It's certainly possible to parse PHP, Python or Ruby into an abstract syntax tree (OK, Perl is a little harder) but practically very few people do metaprogramming at that level, even when it's officially supported. (C# and VB have had "expression trees" for a few years now and they're barely used.)

Part of the appeal of LISP is that you can pretend Noam Chomsky was never born and never need to learn how to write parsers or deal with the data structures that they spit out.

Any kind of extreme metaprogramming is going to defeat 'reasoning-in-code'. For instance, in LISP I can easily implement a new kind of control structure... Because 'understanding' a program in general (rather than running it) is an undecidable problem, it's clear that an IDE will ultimately get bogged down.

I've written a lot of PHP lately in a metaprogramming-heavy framework that uses magic methods to 'create' new properties and methods. The way this is done is systematic, and an IDE could probably be loaded with rules that would help it 'understand' this usage, but so far as I do this kind of code analysis, it's going to be in command-line tools that are cheap to develop compared to GUI tools.

Hmm, I guess I was confused about what you meant when you said "LISP does have the advantage of being easy to reason about"

I thought you meant easy for an IDE to reason about to support the kind of auto-complete Intellisense that Eclipse and VS offer.

I guess it's easier to parse, but however NetBeans does it they have pretty decent Ruby support so I don't know if it's really that big of a disadvantage.

Seems like you'd want a handful of really good, comprehensive parsers for any language and people would just use those rather than rolling a new one each time.

I've seen several posts now with this same theme.

Emacs is an awesome lisp IDE and it appears to be not widely known that emacs is written primarily in elisp, a lisp dialect.

So I would highly recommend learning emacs and elisp together and forget CL for the time being. Sure elisp isn't as pure as Scheme but it's still a good first start and learning the pitfalls of dynamic scope will provide an appreciation for the features of other lisps.

Moreover, though you may not use lisp much in your other work, by learning emacs/elisp you end up with an awesome programmable editor that you can use elsewhere.

I agree with you, Emacs is great and I am only just starting to realize how cool it is to have a Lisp environment underneath all the text editing facilities.

But if this writer picked up Land of Lisp, they might not be that quick to drop Common Lisp and jump to Emacs Lisp.

That being said, I think they should just start reading and hacking and not worry about which editor to use. That's going to be the least difficult part of learning Lisp, but people seem to make it out to be much more than that.

If you're on Windows, this one just does the job. I use it when I am on battery since it's very efficient:

http://www.daansystems.com/lispide/

You can run sbcl, clozure and clisp underneath it.

I really wanted to write a portable "IDE" for Land of Lisp, I even have Scintilla right here on my desktop, semi-FFIed, but I absolutely have no time.

P.S. Don't call Java/C#/C++ stuff "IDEs" until you have seen Smalltalk. Pharo/Squeak are inimitable and have yet to be equaled, much less bested. Just a whole different class of software, really.

LispWorks Professional is frickin' fantastic. It's commercial, but if you don't want to "deal" with Emacs[1], basically the only option in my book.

[1] You'll pry emacs away from my cold dead fingers, but I understand how it's not for everyone.

That's a little funny, since the LispWorks IDE editor is an Emacs written in Common Lisp.

That's a common mistake. I was "bitten" by Emacs, so I threw it away and learned Lisp with CMUCL and its builtin Hemlock editor.

Hemlock, turns out, was not only an Emacs variant, but an old-skool one, requiring 8 fingers per human hand.

https://groups.google.com/group/comp.lang.lisp/msg/6e91e20f2... has some good advice for making life easier when hacking Lisp regardless of the editor involved.

Thanks for sharing this! I just submitted it to HN, so that more people will notice that great article: http://news.ycombinator.com/item?id=2070905

My solution was to turn to PLT Scheme (now: Racket) and DrScheme. I figured that would work just fine as long as I didn't understand the difference between Scheme and Lisp anyway.

Does anyone know if Land of Lisp could be done (and by done I mean cradle to grave) in Racket?

I own the book but have put off starting it for the lack of knowledge regarding a cross-platform IDE to do all the exercises in -- as my time would be split between my work Windows [1] and my home OS X environments.

I do, however, have Racket installed on both; so...

----

[1]: and I have already been shot down on Cygwin

One thing I sometimes enjoy doing with programming books is just re-writing all the example code in a different language. It's a lot lazier than actually doing the exercises, but still requires you to fully understand the concepts in the example code in order to translate them.

One example: I re-implemented much of the example Haskell code from a functional data structures book in Clojure, which improved my Haskell reading, my Clojure writing, and ensured that I actually understood the algorithms.

So I heartily endorse your idea of implementing the Land of Lisp examples in Racket Scheme.

Use Land of Lisp with clisp and LispIDE. I have already posted the link elsewhere in this thread.

LispIDE already ships with CLISP and full Common Lisp documentation. If you know how to use a text editor and click on a button labeled "Run", then you can use LispIDE.

You can stop by the IRC channel #lisp on Freenode, or you can shoot me an email if you need help, or tweet me a hola. Details in my profile.

I spent many hours of my college career in DrScheme... Racket is definitely the way to go!

Nothing against Racket, but working through examples in a book with Common Lisp source using a Scheme implementation is going to be unnecessarily confusing.

There seems to be a strong bias toward using Emacs, probably because Emacs itself uses a Lisp. There's no reason other (programmable) editors couldn't talk to Swank (the Lisp-side of Slime) though, and I'm not sure why people writing things like Eclipse plugins haven't taken that approach.

My understanding is that the Eclipse plugin CUSP does use slime to talk to the SBCL instance.

Yes, evidently it does. Seems strange that it would be tied to a specific version of SBCL then, or is that the user not knowing how to start Swank elsewhere and connect Cusp to it?

CUSP ships with SBCL, not sure how hard it is to play with the Swank stuff.

What many of us emacs users understand, but can't convey adequately, is that he seems to be asking the question "I want to learn Common Lisp, without learning Lisp". Or, "Lisp is just a language like Ruby or Python. Editor is irrelevant." Neither of these statements make sense.

Emacs integration with Lisp distinguishes it from other programming languages, in the same way Smalltalk and it's environment does. You could learn Common Lisp without learning emacs, but you wouldn't want to.

Emacs isn't just an editor. It's arguably one of the best examples we have of how to think in, architect, and use Lisp, Common or otherwise.

The way to learn a language is to immerse yourself in it, and emacs gives you that opportunity, while other editors do not.

Funny how he does not even provide single reason, why he discards Emacs as a Lisp IDE.

Because I didn't want to start a religious debate about Emacs, which seems to have happened anyway ;)

Actually, I don't see why I have to defend this. I've used Emacs before, I don't really want to again. Isn't that good enough? I'm happy for everybody that gets along with Emacs, but I'd appreciate another choice.

I don't see a single comment here on HN resembling religious debate. I see a lot of people wanting to help, but unable to unless you're specific about your problems with emacs. Emacs is the dominant IDE. All the alternatives have weaknesses. Which weaknesses are showstoppers for you, and which aren't?

But for common lisp emacs+slime is the way to go. This is similar to writing .NET in anything but visual studio, or java without eclipse or intelliJ. Of course you can do these things, but it's very likely you'll find some frustration. Of course sometimes using your favorite tool is worth the frustation, sometimes it's not.

Ever since writing an application in Smalltalk (squeak) I've realize that a language and the environment it's edited in are very closely tied together. If 90% of the community of lispers uses Emacs+Slime there's probably a good reason. I don't particularly like Eclipse, but if I'm doing a reasonably large Java project I'll definitely be using it.

Since he tried slimv first I assume he's a vim user. But if he's willing to try eclipse he should be willing to try emacs, at least with cua-mode: http://emacswiki.org/CuaMode

I left a comment to that effect.

I inferred that he doesn;t want to spend time learning how to use Emacs, given Conrad "doesn't want to spend time explaining how to use Emacs".

Emacs is well worth the time, though; I agree with you.

No, I agree that Conrad shouldn't be teaching Emacs. He could have explained how to use any old text editor by loading from the REPL though.

I just don't want to learn Emacs. I just don't want to learn Emacs. I didn't think this was a controversial point. Why does learning lisp mean learning Emacs?

Why does learning Lisp mean learning Emacs? Because it is the best available environment for Lisp, at least among free ones.

Mobody forces you to learn Emacs, but then you either have to pay for commercial IDEs, or use some unhelpful (even hostile, if you are used to benefits provided by sophisticated IDEs) enviroment. You can also set up Eclipse plugins which nobody in the Lisp world heard about, let alone uses. You can use simple text editor and go back to the way software was written in 70s. All these things because you refuse to use some piece of software, and yet are willing to learn others. The choice is yours, of course.

Are you the child of Erik Naggum's cat?

Excuse me, what?

OK, OK ;) Upvoted for repetition.

I generally use DrRacket to edit files and rlwrap to interact with a REPL. I do this with Arc (which I use most often) and Common Lisp (which I use now and then), and I use pure DrRacket to deal with Racket. It works pretty well for me.

DrRacket does indentation (which can be customized), paren-matching, and syntax coloring, plus it has some Emacs-like keybindings. rlwrap does paren-matching, provides up-arrow access to previous commands (ctrl-p also works), and allows in-line editing (an improvement over the raw REPL, which isn't saying much).

I'm not sure why such negativity toward Emacs? Emacs slime is amazing for lisp (and javaScript mode in emacs with auto formatting is also really good). It's true that emacs has more features and commands than other editing options, but you can be really productive in a powerful way with a smaller subset which is not hard to learn in a very short time. And why not use the best open source lisp out there, SBCL?

I'm happy to use SBCL actually, it's just a bit easier to use CLISP as the book examples are for CLISP. I've already figured out how to run external programs from SBCL (so that I could run dot which is used in Land of Lisp).

However, there's no reason CUSP should be tied to SBCL.