4 ms·

>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

>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.
- qwertyuiop924 10y ago
  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.
  - lispm 10y ago
    It feels very different. 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.
    - qwertyuiop924 10y ago
      I am aware of that indirection, but it never really shows up, or gets in my way. Maybe I'm missing something. 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.
      - lispm 10y ago
        http://www.textfiles.com/bitsavers/pdf/xerox/interlisp/3101273_InterlispD_2_Oct85.pdf http://www.textfiles.com/bitsavers/pdf/xerox/interlisp/31012... 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/bib/Sandewall-1978.pdf http://www.softwarepreservation.org/projects/interactive_c/b...

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.

qwertyuiop924 10y ago
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.
- lispm 10y ago
  It feels very different. 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.
  - qwertyuiop924 10y ago
    I am aware of that indirection, but it never really shows up, or gets in my way. Maybe I'm missing something. 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.
    - lispm 10y ago
      http://www.textfiles.com/bitsavers/pdf/xerox/interlisp/3101273_InterlispD_2_Oct85.pdf http://www.textfiles.com/bitsavers/pdf/xerox/interlisp/31012... 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/bib/Sandewall-1978.pdf http://www.softwarepreservation.org/projects/interactive_c/b...