I've been using the Lispworks IDE for the last few years with medium to low satisfaction. Our production server is running SBCL on Ubuntu (which runs considerably faster that LW) and my cofounder is working with Slime. He swears by Slime and I'll be making the switch soon. We are also moving from SVN to GIT.

+1 for both slime and git

Performance Note: Our code is running at least 10x faster on Ubuntu with SBCL over Lispworks on Windows

Do you attribute most of the difference in performance to the OS change or to the implementation change, though? (I'll never use Windows, but I've been considering using Lispworks again on OS X for a few things.) I've always used LW with Emacs in the past, not the LW IDE. I use Aquamacs for almost everything now...and SLIME is great.

What Lisp libs are you using, if you don't mind my asking? I'm trying to figure out why CL-Memcached is slower than freaking PHP and Python for most things (!)

- dcphillips /AT/ runbox /DOT/ com

You call being slower by a (sometimes) 34 msec over 10000 network io requests as slow ? Most of the io stuff for php etc. is pure C. If you have /any/ non trivial application then the stability and performance of CL systems become apparent. If that is your problem, then try benchmarking string operations of CL vs. the rest of the gang.

We're guessing primarily Windows, but with no LW Linux version to compare with, it is a guess.

We're using cl-sql, uffi, md5, portableaserve (with net.html and minimal use of webactions).

We have our own caching system (for key mysql db data) running in the application.

Out of curiosity (as a Lispworks and SBCL user who has never seen this sort of performance difference between the two) is there anything in particular that you could attribute this to (eg. FFI, Streams)

It's hard to say, as we don't have LW on Linux to compare to. My guess is that Windows is a big contributor to the slowness.

Really? That is a lot. I noticed a factor of two when I moved from CLisp to SBCL, and I was under the impression that CLisp is generally the slowest implementation.

Thanks for the info! I was more tending towards Scheme than Common LISP, does that make a difference?

The best Scheme IDE probably is DrScheme (plt-scheme.org)

I use DrScheme every day. It's pretty good and getting better - they just added autocompletion (only for the standard library, not for your own bound variables) for example.

I also use DrScheme regularly.

Slime doesn't exist for scheme. You can use Slime48 for Scheme48 version 1.3, but I don't know of any other ports for Scheme.

If you're using MIT Scheme, you might try Edwin?

Besides Slime, there's also the Cusp plugin for Eclipse (although I haven't used it):

http://bitfauna.com/projects/cusp/index.html

And for Scheme/Emacs there's Quack (google quack.el)

I was quite happy hacking lisp code (cmucl and then sbcl and a bit of clisp) in emacs with slime

I can't recommend slime highly enough - I miss something comparable now that I'm hacking Python.

Maybe IPython would fit the bill for you: http://ipython.scipy.org/moin/

Vim and SBCL.

How do you interact with your REPL? SBCL is designed around SLIME. I find it virtually unusable without it.

You could use vilisp.vim[1], which will basically copy-and-paste Lisp forms into your REPL for you. If you use OSX, you can try pg's method[2] of dragging text between terminals.

Better yet, you could resurrect Slim-Vim[3] if you really want SLIME-like features.

[1]: http://www.vim.org/scripts/script.php?script_id=221

[2]: http://news.ycombinator.com/item?id=72863

[3]: http://wiki.alu.org/Slim-Vim

SBCL recommends SLIME, but I see no evidence that it's "designed around" SLIME.

Vim and Chicken.

Nedit is very nice.

Can Nedit send expressions from the file you're editing to a REPL? I think that's a requirement for a decent Lisp editor.

I don't think it can, but I tend to copy and paste code from Nedit into a REPL.

I did that sort of thing when I first started out with Lisp too. Do yourself a favor and try an editor that integrates with the REPL. It makes life so much easier.