3 ms·

I am well aware of where SLIME's inspiration comes from. As for IDEs, I have a marked distaste for special purpose tools: I want to be able to use on tool to e

I am well aware of where SLIME's inspiration comes from. 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.

lispm 10y ago
> 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.
- deleted 10y ago
  [deleted]
- qwertyuiop924 10y ago
  >Obviously not. ...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.
  - lispm 10y ago
    > 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.

lispm 10y ago

> 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.

deleted 10y ago
[deleted]
qwertyuiop924 10y ago
>Obviously not. ...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.
- lispm 10y ago
  > 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.