Hacker News Reader

Comment by claystu | Hacker News Reader

> emacs & slime[1]

I've spent a lot of time with emacs, and slime was what I used when I was exploring Common Lisp: both SBCL and CLISP. Emacs is really powerful and I'm fairly at home with it, but I've come to prefer more graphical IDE's. Judging from the popularity of Eclipse, Visual Studio, NetBeans, etc...I'd say I'm not alone. Telling programmers it's emacs+slime or the highway is not a strength; it discourages everyone who prefers those other environments.

> I'd even go as far as saying that targeting a specific implementation is usually a sign of bad coding style.

I was suggesting ABCL because it is a full implementation of CL on the JVM. If there are other CL's with ABCL's level of maturity on the JVM, then they would work just as well.

Beyond that, I imagine that many programming projects target specific implementations for various, pragmatic reasons.

View on HN

> I've spent a lot of time with emacs, and slime was what I used when I was exploring Common Lisp: both SBCL and CLISP. Emacs is really powerful and I'm fairly at home with it, but I've come to prefer more graphical IDE's. Judging from the popularity of Eclipse, Visual Studio, NetBeans, etc...I'd say I'm not alone. Telling programmers it's emacs+slime or the highway is not a strength; it discourages everyone who prefers those other environments.

LispWorks and Clozure CL are good non-emacs IDEs, and there are several others. I will agree that Emacs and Slime are pushed a little too hard sometimes.

> Beyond that, I imagine that many programming projects target specific implementations for various, pragmatic reasons.

That has not been my experience actually using Lisp for a number of projects. IME it's far more likely to support specific platforms (Linux, Windows, OSX, ...) than it is to support specific Lisp implementations. Even that is usually only because a required C library doesn't run on Windows or something like that, which is no different than Python, Java, or any other language.

No offense, but between your conclusions being incorrect and your phrasing ("I imagine..."), it sounds like you're hypothesizing without much actual experience writing Lisp.

Clozure CL's IDE basically is a clone of Emacs/Slime though -- you even send sexps from the Emacs-style editor to the repl via C-x C-e. Not that I mind it myself, but people who don't like Emacs wouldn't like it, I'd imagine.

That's slightly backwards.

The second Emacs (after TECO) was written in Lisp. On a Lisp Machine. Stallman later went for an Emacs, GNU Emacs, written on top of Lisp VM implemented in C. That one then got support for 'inferior' Lisps, external Lisp processes run from GNU Emacs. Extensive modes were ILISP and ELI. Slime is kind of a reimplementation of ILISP.

Clozure CL goes back to Coral Lisp, an early Lisp for the Macintosh, written in the mid 80s. Coral Lisp, and the Coral Common Lisp, and then Macintosh Allegro Common Lisp and then Macintosh Common Lisp all were written mostly in Lisp and had an Emacs-like editor (FRED - FRED Resembles Emacs Deliberately) included plus a bunch of tools: backtrace, inspector, interface designer, Editor-based Listener with REPL, etc. The main difference to GNU Emacs: it was focused on Common Lisp programming, it was implemented all in Common Lisp, it all ran in one application (no external Lisp), much of the tools made use of the GUI toolkit from the mac (menus, dialogs, buttons, copy/paste, AppleEvents, ...). MCL then was dead end, because it was tied to the old Macintosh libraries. OpenMCL was a fork initially thought to run on the spaceship mentioned before (but it was actually LispWorks, which was used for the spaceship). It was stripped down and ported to Unix or something similar. OpenMCL, later renamed to Clozure CL, was brought to the new Mac OS and got a simple IDE, but not based on the MCL code, but using some of its IDEs.

So Clozure CL's IDE goes back to the old MCL IDE and to Hemlock (the Emacs-like editor from Spice Lisp / CMUCL). It's not based on remote/external execution, like Slime.

Clozure CL's IDE is very simple, offers not many tools, and those tools are not really powerful. For MCL there were much better IDE tools developed. But MCL is gone.

What do the graphical environments gain you, in most cases? I'll not argue that they don't usually have better defaults configured. Autocomplete, in particular, typically works out of the box. These can work in emacs, though. (Even in vim, to be honest.)

Seems most of them "win" by having more effective advocacy than they do more effective features.

A tree view of the bazillion files in the typical Java project. (of course, if the project wasn't organized as one file per "design pattern" + domain part, each file of which has 1 or 2 executable lines nested within the required ritual...)

As well as a tree view of the properties and methods of the handful of "god classes" within said projects.

But seriously, on the plus side, IntelliJ is actually fairly usable in that you can quickly toggle on and off the supplemental info panels and just use the "distraction free" editor panel, particularly with the vim (key map) plugin (don't know if there's an emacs plugin).

I think Steve Yegge had a comment in one of his rants that IDEs have better support for languages that require IDEs :-)

There are tree views in emacs. Looks like the most popular is https://www.emacswiki.org/emacs/NeoTree.

Pretty sure I have seen similar things written for class views. I had one that was interactive view of javap's output. I liked that one pretty well. (I'm partial to anything that is just an interactive version of an existing cmd line.)

>What do the graphical environments gain you

Simplicity. In my IDE, I start it up and then program.

With emacs, it always felt like I spent a lot of time curating the editor. Part of that was because customizing emacs is fun--I have this big .emacs file that imports an even bigger .elisp file--but I also always seemed to be referring to some documentation because I'd forgotten that particular set of key-chords or messing with something to get it to work.

I've come to prefer simplicity. In fact, after years of using emacs, I switched to vim for the moments when I want to program on the command line. (I think my only customization in VIM is mapping jj to escape)

In case this helps anyone else, I've found that a better shortcut for me is Ctrl+[ , which actually maps to escape too. I too found having to tap escape to exit modes was annoying since I had to make my fingers leave the home row and there is no need to customize mapping in this case.

If you're used to hitting ctrl with your left pinky, which is necessary for us emacsers, then Ctrl+[ will be 100x better than hitting escape.

I like IntelliJ, but I still spend time here and there window-shopping the settings and plugins. That seems to be the nature of things, regardless of the tool.

Take a look at what the Smalltalkers are up to these days, with custom visualisations for different classes:

http://gtoolkit.org/

I don't know how useful this is in practice, and it's not representative of what IDEs for mainstream languages are doing, but it's pretty cool.

You hit my fundamental problem. Specifically, "how useful this is in practice."

It makes for some awesome demos. But... so does https://www.youtube.com/watch?v=VEcobuYr5wg. I'm just not sure how practical this is.

Don't get me wrong. Sometimes, I do want to boot into IDEA for some of the refactor tools. If I truly used them enough, though, I would write one for myself in emacs.

> [emacs & slime]

I was not aware you have experience with both, I just tried to point out what most people use today. I did not intend to start yet another editor war, even clay tablets are fine with me :).

> If there are other CL's with ABCL's level of maturity on the JVM

My point is that the (virtual) machine does not matter at all. ABCL is just another CL and it should not be relevant except for when you are specifically looking into interfacing java libraries (for which one does not need a book, just a few paragraphs of docs).

> Beyond that, I imagine that many programming projects target specific implementations for various, pragmatic reasons.

Only to the point that you sometimes have to implement things for your current CL implementation (i.e. stuff not defined in the standard and for which no interop. libs exist - a pretty rare thing).

This is how the LispWorks IDE on ARM/Linux/Gtk+ looks, when displayed on a Mac X11 server: https://pbs.twimg.com/media/CoufhEFUkAExgqe.jpg:large

https://pbs.twimg.com/media/CouoF9DVUAUUhg1.jpg:large

On the Mac using native Cocoa:

https://pbs.twimg.com/media/CouqqaLVIAA4DRU.jpg:large

I love emacs, but I must admit that slime is not very appealing to me. I can not stand the lack of readline in the repl.

emacs + slime + semantic + srefactor

The last two are game changers.

Reply on news.ycombinator.com