I had to give up on that slime tutorial as well, and that was after really, really WANTING to set up the same sort of thing he had going there. The reason I had to quit? My workstation runs Windows.

I was all psyched up to set up a remote IDE like the Slime tutorial demonstrates, running SBCL on a friend's Linux server and editing locally. Only when I was about three straight hours into trying to get this configured did I discover, the hard way, that the remote file editing feature built into emacs (which a remote Slime relies on) completely fails to work in native-compiled Windows emacs.

I still intend to plug away at Lisp in the future, but trying to get a reasonable Slime environment running on my OS was a ridiculous waste of time. (The free Allegro trial with Lispbox was great for a while, until I tried loading a regexp library and immediately hit the memory limit.) I'm giving up on Slime, at the very least until I have a spare PC to run Linux on at home.

josh g.: do you have an ssh client in your path? that's the main dependency TRAMP has on the outside world.

Running emacs under the cygwin environment works for me...and you get ssh w/cygwin too. Maybe I'm missing something, but I don't see any reason to use the native windows version of emacs instead of the cygwin version.

I didn't at the time. The only TRAMP documentation I could find at the time wasn't very optimistic about making it work in Windows at all.

Googling now does look a bit more promising - looks like I could've used plink.

I still feel like there's some pattern to my frustrations, like everything the Lisp community promotes would magically work if a) I ran Linux and b) I was an emacs wiz. I intend to do a) in the future, and I'm working on b), but it still seems to be shortsighted to expect that of all new Lispers.

Craig: You're probably right, but the problem was that I had no way of knowing that choosing native emacs would turn out to be a bad thing.

"I was all psyched up to set up a remote IDE like the Slime tutorial demonstrates, running SBCL on a friend's Linux server and editing locally. Only when I was about three straight hours into trying to get this configured did I discover, the hard way, that the remote file editing feature built into emacs (which a remote Slime relies on) completely fails to work in native-compiled Windows emacs."

For what it is worth, I got the remote file editing to work in native xemacs for windows, using the putty tools. Sadly, I cannot find any of my config files, nor remember the name of the package for remote file editing... but it goes into detail on how to set it up in windows using the putty tools.

I gave up on the slime movie myself, simply because it was putting me to sleep. I think the most interesting parts were the emacs s-expr editing, which I later stole from Marco's emacs files.

Completely off-topic: I followed the link from the nice warning picture to the Japanese earphones and they look like a B&O knock-off to me. They should sue them... :)

Well, even I am not going to watch a 55 minute video on SLIME. 5 or 10 minutes would be a reasonable upper limit, I think.

Maybe someone can remix the video.

But yeah, using Lisp is harder than people let on. This is why I tend to discourage people somewhat, pointing out to them that advocates tend not to offer a good picture of gotchas.

Tayssir John Gabbour - Indeed, the initial stages of getting Lisp to work with regular things (such as OpenGL) is sometimes quite difficult (especially on Win32, since the Lisp community isn't focused much on it). I think this fact might explain why Lisp advocates are very ... let's say, "overzealous". ;-)

Anyone without a kind of zealous fervour for Lisp would have climbed out of the pool long ago.

I wouldn't say "very overzealous." Just compare them to the average big tech company unwilling to admit defects, except in ways which serve them most. The kind running commercials showing you that Intel CPUs make it seem like Seal's sitting on your couch singing to you.

"The reason I had to quit? My workstation runs Windows."

Enter Lisp In a Box: http://common-lisp.net/project/lispbox/#windows

Worked great for me.

EnigmaJerk: I used Lisp in a Box, then LispBox 0.6 from Peter Seibel, to work through most of his book. But when I hit the chapter on writing a spam filter, my Lisp choice (Allegro 6.2 free version) broke down as I mentioned above.

I will be very happy when someone writes a solid SBCL port for Windows. Allegro and Lispworks both look great, if you can afford them, but the free versions get annoying. And everything I've heard and read leads me to believe that CLISP is, well, lacking.

I thought the video was very informative. I had been using Slime for a short while, but you never really pick up on some of the useful features simply by reading the documentation.

Also, as far as the general criticism of Slime, I'm a noob, but what out there even compares (for free, of course.) Slime seems incredible to me.

I have had all sorts of fits getting Lisp working under Windows. I hate cygwin, having been bitten by it many times -- it doesn't uninstall! Since a large percentage of the world uses Windows, supporting it might be a good idea. I'd work on porting SBCL myself, but it's mainly implemented in Lisp... You see the circular problem. The gotchas in the Lisp world seem to be in the implementations, not in the language. Implementation work just needs more people, but people aren't going to join up until they can work in an environment that works for them. Yet another circular problem...

If "real" Lispers want to make Lisp take over the world, they need to get a free Windows Lisp environment working. Then they can go back to their Linux/Emacs world and be happy whilst Windows programmers take over the Windows work. Until then, Lisp will remain a sidelight in the the world of mainstream development.

Out of curiosity are there similar screencasts for Java/Eclipse, C#, etc?

Chad,

Porting SBCL (which is indeed mainly implemented in Lisp) is not difficult because of the "implemented in Lisp" part: the vast majority of that Lisp is portable, ANSI Common Lisp. The difficult bit in a port to Windows is in the Operating System interface, which is mostly written in C and assembler.

(As for "take over the world", why should I care about that? Unless the extra people working on SBCL that a Windows port brings in have a greater effect than the number of people desiring free support, a Windows port is utterly useless, if not worse, from my point of view; judging from the dynamics of the existing, functional Windows port of SBCL, the number of people willing to put in any effort to work towards their own goal is minimal at best.)

josh g., et al.,

Here's how I make SLIME work over an SSH tunnel in Windows.

http://a1k0n.net/blah/archives/2005/11/04/T18_00_44/index.html

You still need a unix box somewhere running some Lisp; I mainly use this to connect to our development (or production, on occasion) server from my Windows box at home, so I include bonus instructions on getting Tramp to tunnel through firewalls.

HTH.

Sure the movie was long, because you have to watch the whole thing to see what's in it. I wrote a reference guide to it with timestamps, links to more documentation, etc to make the movie more useful.

http://www.pchristensen.com/blog/articles/reference-for-the-slimelispemacs-screencast/

Take a look!

-Peter

Hmmm.
Ok, first step, if you want to run Emacs in windows...don't. Run PuTTY in windows and emacs on the remote machine. Save the files on that machine and email yourself the work as a backup.

Second, most lispers are about as likely to write native Windows implementations for Windows as Microsoft is to write native programs for Linux.

They want Lisp to gain ground, but on THEIR terms.
In an interpreted language, things often work better, functionally WORK BETTER with the code itself being what you execute, thus they're also FLOSS advocates as well as Lisp advocates.
It's hard to wrap your head around stuffing everything into an .exe file if you're used to just writing a BASH script that calls your favourite implementation, then setting a dependency when you package it. It would also be hard for some Windows users to wrap THEIR heads around needing one program installed to run these other 200 programs.
They don't have standard repositories, nor are they used to dependency hell(at least not many of them remember it).

Basically Lispers care about programmers who run Windows, but not much about Windows itself.
It's like christians(I'm an antheist) who often care about muslims, but not islam.

In a way it's sad. It's slowing the progress of Lisp. However, I don't care about Windows either, so that's only my objective opinion.
Subjectively I'm laughing very, very hard.

I think ABCL should work in a Windows environment, but I havn't tried it myself:

http://armedbear.org/abcl.html
http://sourceforge.net/project/showfiles.php?group_id=183565

Cusp from

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

runs SBCL within the Eclipse IDE on Windows.

vik