How do people develop code in CL?
Tuesday, November 30, 2004
Bob Hutchinson kicked off an interesting discussion when he asked on the LispWorks mailing list "how do people actually develop code using LispWorks". He said:
"I've assumed that you work in the provided IDE. I was at the first meeting of the Toronto lisp users meeting (organised by Bill Clementson while he is visiting Toronto, thank you) and a couple of things came up. First we were talking about IntelliJ IDEA (a Java IDE) and I 'recalled' that this is one of the very few IDEs that I actually like. Then the traditional emacs vs. vi discussion erupted (I admit that I'm a vi kind of guy :-) but I'm not completely ignorant of emacs (despite the impression I may have left last night) and that I do prefer emacs to most IDEs..."In response, he got a range of different replies. Some people use just the LispWorks IDE and editor. Others used the tools from the LispWorks IDE but used Emacs (usually with SLIME) for editing. I personally use a "blended" approach when I use LispWorks. Sometimes I use just SLIME/Emacs with LispWorks started up in an inferior-lisp buffer. I do this when I am in "heads down" coding mode (this configuration is described in this posting). At other times, I want to be able to access the LispWorks IDE tools but still use SLIME/Emacs or I am using a PC with only the LispWorks Personal version installed (which does not allow you to create the "console" version of LispWorks necessary for use as an "inferior-lisp" in Emacs). In those scenarios, I use a combination of SLIME/Emacs and the LispWorks IDE (this configuration is described in this posting). Incidentally, I also take this "blended" approach when using Franz ACL (configurations described in this posting and this posting). I feel that this often gives you the best of both worlds - the superior editing environment provided by Emacs combined with the specialist tools that the Lisp vendor provides.
One interesting posting in the thread that Bob started was one by Christopher Stacy. He reminisced about the superior development environments on the Lisp Machines and outlined some of the "wish list" features he would like to see in a future Lisp editor:
"Having the development environment integrated into a single program is just a hack for efficiency (both in terms of the machine, and in terms of the implenentor). It's the easiest way to program the integration on the operating systems we have at the moment. Otherwise, you have to create a bunch of machinery on each end, and it wouldn't be as good. But it's easy to imagine alternatives in various directions.
The systems I grew up on were ITS (on the PDP-10) and the Lisp Machine.
ITS had hierarchically structured user processes ('jobs'). The editor was EMACS, which was a seperate program written in TECO. There were various packages to allow EMACS to communicate with running Lisp program. As I recall, usually the editor was the 'inferior'. The MACLISP compiler was a seperate program from the REPL/interpreter; you invoked it on a command-line with the name of the file to load. The compiler could be invoked from Emacs as an inferior, so you could capture its output in a buffer. There was no in-Lisp support for 'meta-dot - seperate TAGS files were used in Emacs. Mostly I just used Emacs seperately (without any integration package) from MACLISP, in a more traditional edit-compile/load-run cycle. ITS had good job/terminal handling, so you could switch back and forth.
Much tighter integration was achieved later on the Lisp Machine, where the entire system was one huge Lisp program. The LispM had just one large address space, running multiple threads ('processes'). Source lookup, arglist queries, and other amazing goodies came from there.
A better approach (in the future) would have multiple protected logical spaces capable of communicating with each other (passing and sharing data and function calls) in some pretty direct way. There would need to be a common notion of objects and calling, which does not involve any 'remote' or 'foreign' programming or networking. You would just invoke an administrative function to tell the system that you wanted to the programs to be allowed to talk to each other, and they would figure it out for you. This would represent a natural combination of concepts from the Lisp Machine, Multics, and other ideas that have been languishing for decades. The past 10 years mainstream interest in object-oriented programming, and the recent interest in higher-level (eg. XML-based) communication protocols are small steps in the right direction. Maybe I'll see something like this before I die.
I've been using Emacs for 25 years, starting with the original TECO implementation, and I like having just one editor that I can easily program to do anything I want; it should include a large body of libraries, features like graphics and understanding CLIM presentations, and the ability to semlessly intergrate at least with certain other programs (eg. my Lisp interactor/compiler.) That's what we had on the Lisp Machine, and it's very painful not to have it anymore. The height of Emacs technology was Symbolics Zmacs, and while it had some design problems, I'd far prefer that old implementation over what I have now. GNU Emacs has an elisp that is very poor, but it has more of the basic editor functionality, and is more compatible with Zmacs, than the IDE editors. So I sort of have the worst of both worlds, and I use them both depending on exactly what I am doing.
I would just switch to using GNU Emacs for all my LWW editing if the integration worked a little better. I haven't had very good luck with LWW and ILISP or SLIME. I'll probably try it again someday. I would still make heavy use of the graphical features of the LWW IDE, of course. (This would be easier than trying to fix up the Lispworks editor, and does not entail the impractical restrictions involved in using the Xanalys product for all my editing needs everywhere.)"
