
Lisp IDEs (where for art thou?) - amouat
http://www.adrianmouat.com/bit-bucket/2011/01/lisp-ides-where-for-art-thou/
======
pge
<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:)

~~~
amouat
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!

------
drcode
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

~~~
muuh-gnu
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.

~~~
silentbicycle
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. :)

------
jimbokun
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.)

~~~
aerique
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.

~~~
antileet
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/>

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

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

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

------
PaulHoule
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#.

~~~
spacemanaki
> 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.

~~~
PaulHoule
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.

~~~
spacemanaki
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.

------
bitdiddle
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.

~~~
spacemanaki
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.

------
mahmud
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.

~~~
iheartmemcache
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.

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

~~~
mahmud
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.

------
zachbeane
[https://groups.google.com/group/comp.lang.lisp/msg/6e91e20f2...](https://groups.google.com/group/comp.lang.lisp/msg/6e91e20f2f371b52?&noredirect)
has some good advice for making life easier when hacking Lisp regardless of
the editor involved.

~~~
vog
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>

------
Confusion
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.

~~~
shawndumas
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

~~~
jimbokun
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.

------
Zak
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.

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

~~~
Zak
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?

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

------
taloft
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.

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

~~~
amouat
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.

~~~
brlewis
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?

------
waterhouse
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).

------
gibsonf1
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?

~~~
amouat
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.

