As for IDEs, I have a marked distaste for special purpose tools: I want to be able to use on tool to edit all text. And not all IDEs are good: IntelliJ is pretty rubbish (although that's more to do with Java than IJ itself...)
Emacs's limitations tend to line up with the length you can go before you start becoming a special purpose tool, tightly tied to your environment, or the point at which the Unix model doesn't really work, and you're going to have to go build your own little world (like Smalltalk did). They certainly aren't perfect, and could go a bit farther (something work is being done on, last I checked), but it usually works well enough, and it's so extensible, and has had so many extensions written for it, that it can beat just about any other general purpose editor, and sometimes even some of the special purpose ones.
Obviously not. SLIME's inspiration comes from various other integrations of Lisp into Emacs editors, especially Emacs Lisp and ILISP. SOME of its inspirations comes from the Lisp Machine, direct or indirect. SOME. Not ALL and not even MOST. For example the Lisp Machine does NOT use Zmacs as a Lisp REPL, like ILISP/SLIME/... does. The Lisp Machine has a REPL, which is called a 'Listener', which is a separate application and which is not based on a Zmacs editor buffer. The Lisp Machine listener has a very different feature set and look&feel, from an ILISP/SLIME repl.
The LispWorks listener is a mix of both: it is based on an Emacs substrate, but offers slightly more Lisp Machine like interaction. SLIME though adds a simple presentation system, which LispWorks does not use in the listener.
> I want to be able to use on tool to edit all text.
A Lisp system is not text-based.
Lisp is based on data. Code is data and data can be code.
Using an editor to work with text is only half of the story. A good Lisp IDE lets me more or less directly interact with the data.
Interlisp-D worked with Lisp data throughout the IDE. That's a whole different interaction.
> IntelliJ is pretty rubbish
It isn't. It's actually quite good at what it does.
...And what makes you say that? I was actually aware, in any case.
>A Lisp system is not text-based.
>Lisp is based on data. Code is data and data can be code.
>Using an editor to work with text is only half of the story. A good Lisp IDE lets me more or less directly interact with the data.
I'm aware of that, but text is a fairly convenient representation of Lisp data. In fact, I'm unsure what you mean by directly interacting with the data, as you can't have bytes fly from your fingertips, AFAIK.
In addition, files are a pretty good metaphor as well: If you want to store your code as something textual, they're indispensible. And sure, you can use image storage and navigate in other ways, but Lisp isn't Smalltalk: The way Lisp is written isn't as unified, so that wouldn't work as well, AFAIK.
And sure, IntelliJ does what it does well, but I don't think that what it does is especially good, and most of it is just making up for Java's sins, things that don't exist in other languages: A good development environment is imperative, but if it's painful to write code in the language without the tools IDEs provide, than there's something wrong with the language.
Some Lisp data does not have a textual representation, it might have a graphical representation or the textual representation may not be very helpful (Lisp data being a graph might be better displayed as a 2d or even 3d graph, than as a textual representation). The Symbolics UI of the REPL/Listener would allow you to interact with the 2d/3d graph as it were Lisp data, which it actually is underneath.
> In fact, I'm unsure what you mean by directly interacting with the data, as you can't have bytes fly from your fingertips, AFAIK.
GNU Emacs pushes characters around.
S-Edit manipulates S-expressions.
GNU Emacs lets you pretend that you edit s-expressions, by pushing characters in a buffer around. But you don't. All you do is push text around.
S-Edit directly manipulates the data. It's a structure editor.
Symbolics Genera uses 'presentations' to record for every output (graphical or not) the original Lisp data. When you interact with the interface, you interact with these data objects. For example in a Listener (the REPL) programs and the Listener itself display presentations, which then can be acted on. It also parses text into data objects and then runs the commands on the data objects and not on text.
SLIME provides a very simple and partial reconstruction of that - which is a nice feature.
> In addition, files are a pretty good metaphor as well: If you want to store your code as something textual, they're indispensible. And sure, you can use image storage and navigate in other ways, but Lisp isn't Smalltalk: The way Lisp is written isn't as unified, so that wouldn't work as well, AFAIK.
Smalltalk does not use data as representation for source code. It uses text as representation for source code.
Interlisp-D is more radical than Smalltalk 80. The Smalltalk editor edits text. The Interlisp-D editor S-Edit edits s-expressions as data.
Interlisp-D treats the files as a code database similar to Smalltalk, but the source code loaded remains data and you can run the program from that data directly via the Lisp interpreter. Smalltalk execution does not provide something like that. The so-called interpreter in Smalltalk executes bytecode. This is different from a Lisp interpreter, which works over the Lisp source data.
The combination of a s-expression editor with an s-expression interpreter (plus optional compilation) is very different, from what Smalltalk 80 did.
When you mark an expression in Smalltalk 80 and execute it via a menu command, then the expression gets compiled to bytecode and the bytecode interpreter then runs it.
If you mark an expression in S-Edit, the s-expression data is extracted from the data structure you edit and you can run that s-expression data with an interpreter, walking directly over that s-expression data.
There was an emacsy interface made by Kelly ??? in the office next to me which I extended into a real Emacs clone (with modes and everything) which a bunch of us used. In retrospect I should have gone native and adopted D-edit directly but what can I say I was a snot-nosed 20 year old kid.
In any case, I don't really want my editor editing sexps. The moment my editor is working with sexps rather than characters, it's no longer a general-purpose tool.
Imagine the editor and the runtime work on the same data:
EDIT <-> data <-> EVAL
Emacs EDIT -> text -> Emacs SAVE FILE
SBCL LOAD FILE -> SBCL READ -> SBCL EXECUTE
Emacs EDIT -> text -> Emacs TRANSFER to SBCL
-> SBCL READ > SBCL EXECUTE ->
SBCL generate TEXT -> SBCL TRANSFER to Emacs
-> Emacs DISPLAY -> text
That's a lot of indirection, a lot of conversions, different runtimes, etc.
S-Edit feels like working with clay. A text editor feels like working with instruments, manipulating something which then manipulates the clay and you are watching the result through goggles.
Could you link me some information about S-Edit? I can't find anything on it, and it might help me understand what you mean.
Chapter 16 describes DEdit, the display oriented structure editor of Interlisp-D.
ALso see for general philosophy of interactive Lisp systems this article from 1978 (!!!):
http://www.softwarepreservation.org/projects/interactive_c/b...
But that's just me. You use your cool lispm tools, I'll resign myself to never acheiving ultimate productivity.
But I was resigned to that already, pretty much.
From the sidelines, your approach is "all I have are nails and all I need is the biggest hammer you can get me".
>From the sidelines, your approach is "all I have are nails and all I need is the biggest hammer you can get me".
From my perspective, my approach is "that development environment sounds really unpleasant, and while I can appreciare the elegance, I'm having trouble finding the relative upshot."
Data representation is not the data. It's just this: "re" presenting. And when this representation is disconnected from the source by means of showing only the raw text and not allowing access to the source you get what you describe as "unpleasant".
You may find it enjoyable to work only with raw text but you're missing out on working with what that text is supposed to represent.
>And when this representation is disconnected from the source by means of showing only the raw text and not allowing access to the source you get what you describe as "unpleasant".
First off, pleasantness of an interaction is a matter of personal opinion. If you like DEdit, great: I'm not stopping you. But I don't enjoy DEdit and its like. That's my prerogative.
Secondly, I'm not working "only with raw text." Paredit &co let me manipulate the sexpr data structure more directly (or less directly, depending on how you look at it). Geiser and SLIME let me evaluate and manipulate the code as code. But at the end of the day, I'm also operating on text, so I have all of the textual data tools as well, and because Paredit is actually operating on text, it can be used outside of the context of Lisp: As Perlis said, "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."
There is a lot of software out there which needs powerful and/or different IDEs to be written.
> Although it is telling that SLIME (which is excellent, by the way) is one of the most popular ways to write Lisp code.
Guess where the inspiration for some of the SLIME features is coming from... Slime also does many cool new things, but it is still missing a lot of features and usability from the old environments. Part of the reason is GNU Emacs. It is what it is: a programmable editor with zillions of features. But its base, its UI, its interaction model, its integration idea is limiting in many ways. Many of the defining/leading IDEs were very different: Smalltalk 80, Interlisp-D, Symbolics Genera, ... Turbo Pascal, Visual Basic, Hypercard, ... NeXT ..., IntelliJ, ... (and a lot of others)