> I am well aware of where SLIME's inspiration comes from.
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.
> I'm aware of that, but text is a fairly convenient representation of Lisp data.
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.
BTW while pretty much every Interlisp-D user used D-edit, I was never comfortable with it because it required use of the mouse. By the time I started using Interlisp I had about six or seven years of Emacs wired into my fingers and didn't like being slowed down by taking my fingers off the keyboard.
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.
Thanks for the information. It is legitimately interesting. But while it is a neat idea, the difference seems to be largely inside-baseball. Sure, we're dealing with text, but we can still inspect our code quite well, and we can do much of the same sort of stuff.
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
In GNU Emacs it looks like this:
Emacs EDIT -> text -> Emacs SAVE FILE
SBCL LOAD FILE -> SBCL READ -> SBCL EXECUTE
or
Emacs EDIT -> text -> Emacs TRANSFER to SBCL
-> SBCL READ > SBCL EXECUTE ->
SBCL generate TEXT -> SBCL TRANSFER to Emacs
-> Emacs DISPLAY -> text
With presentations it looks for the user that the Emacs side knows the data for the 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.
Neat. But actually, I find that mechanism quite unpleasant, and one I wouldn't like working with. I'm sure it's quite powerful, but so is Vim, and I never really "got" Vim either. I would, in fact, argue that manipulating text has advantages over direct object manipulation: the first of which is that you can more directly edit text, whereas the DEdit interface is all about executing commands on objects. Secondly, you can apply useful transformations to text which don't necessarily make sense to apply to raw datastructures (search + replace, regexes, other handy transforms). Finally, many of the advantages of manipulating a pure datastructure can be had in text as well: see paredit.
But that's just me. You use your cool lispm tools, I'll resign myself to never acheiving ultimate productivity.
Text is a raw data structure, it's just not the one that's used behind the scenes: Everything is a datastructure. And actually I do touch the data by manipulating text.
>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."
When your editor's cursor hovers over "transistor T1" do you in fact touch the transistor on the board over your desk, the transistor in the schematic diagram, or only the text that happens to be "1T rotsisnart" spelled backwards (with no underlying meaning that is)?
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.
All is representations. Some are closer to the data they are representing than others. I am aware that text is a representation. It is a also a data structure: A data structure which we are better able to manipulate directly with our human senses, and a data structure which tools like DEdit still render to.
>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."
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.