4 ms·

In the lisp universe the future was in the 80's, thats when we tried the whole "structural editors" idea and concluded that they didn't work out as nicely as we

In the lisp universe the future was in the 80's, thats when we tried the whole "structural editors" idea and concluded that they didn't work out as nicely as we hoped. I believe the sgml people tried them too, with poor results as well.

calibraxis 15y ago
Sounds unlikely. May I ask what experience you had with 1980's structure editors (presumably Interlisp)? My reading of history is that it wasn't rejected by users, but rather killed off by MacLisp implementors teaming up to create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to consolidate Lisp). (https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2SYUk/EoSmODsX7WgJ https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2...) Paredit, a favorite among modern Lisp users, was directly inspired by Interlisp's structure editing. Paredit's own author calls it a "cheesy imitation" of Interlisp. (http://mumble.net/~campbell/emacs/paredit.credits http://mumble.net/~campbell/emacs/paredit.credits) Personally, I think Lisp is ripe for many different visual/kinesthetic interpretations, and this one certainly is pretty.
- sedachv 15y ago
  Paredit is nice, but barely works for stock Lisp syntax. One of the best things about Common Lisp is reader macros, and in order to integrate them with structured editing, you'd need to change the reader macro mechanism to be based around a composable context-free grammar description that can be shared between the reader and the structure editor. I'm pretty sure that's still an open research problem. Personally I think structured editing is an idea that seems great until you actually try it.
  - calibraxis 15y ago
    At least among the Emacs-using Common Lisp users I've known (and discussed the topic with), Paredit is considered a clear win. Same in my experience. What do you use? If there's something better, I'd be happy to use it. (When I last observed someone editing Common Lisp code without turning on Paredit, it was rather depressing, how much time he spent closing parens and re-indenting everything. But maybe you use something else which avoids this problem?) Reader macros (in the worst-case scenario you describe) are a very rare use-case, and therefore probably not worth optimizing an IDE for. Perhaps for you they're common, but I'm virtually certain that most Common Lisp users have never written even one. If macros are already uncommon to write, reader macros have a far higher bar of justification.
    - sedachv 15y ago
      I started using Paredit in 2010, and wrote Lisp in Emacs for 7 years before that. Paredit make some things very convenient, but I can't say it has sped up my programming significantly. It has made it a lot more convenient for me to use the REPL, which has changed my programming style. Two things that save time when indenting code and work in all Emacs programming modes: 1. (global-set-key (kbd "RET") 'newline-and-indent) in .emacs to automatically indent every newline (also points out problems in your syntax right away) 2. C-Space to start region selection, C-M-b or C-M-f to jump back/forward a code block (s-exp), then C-M-\ to reindent region. The other thing I use is my https://github.com/vsedach/mouse-copy https://github.com/vsedach/mouse-copy mode for "structured" copy and paste. It's convenient sometimes. I use reader macros a lot more than Common Lisp programmers do now, and I encourage people to use them and think that reader macro usage will become more widespread, in particular due to Tobias Rittweiler's named-readtables library (http://common-lisp.net/project/named-readtables/ http://common-lisp.net/project/named-readtables/). In particular, I use cl-interpol (http://weitz.de/cl-interpol/ http://weitz.de/cl-interpol/) both for string interpolation and to do HTML templating (http://paste.lisp.org/display/118522 http://paste.lisp.org/display/118522). I also wrote a uri-temple library for Common Lisp (http://common-lisp.net/project/uri-template/ http://common-lisp.net/project/uri-template/). When I used CL-SQL, I used its reader macro syntax, and I thought it was worthwhile, but could have been better designed.
  - colonel_panic 15y ago
    Maybe it would work if you designed a language with structured editing in mind from the start.
- pavelludiq 15y ago
  I'm a lisp history nut, but I wasn't around at that time. Paredid doesn't really turn emacs into a structure editor, its more like a "standard editor with some of the better ideas of structure editors miked in" kind of mode. Structure editors introduce a lot of complexity in general. Maybe Interlisp was able to work well in practice despite the added complexity, I don't know, I really would like to know more about such systems. As for your last sentence, Erik Naggum who had a bad opinion on structure editors in general, seems to have liked the idea of a structure inspector, as in using such tools to inspect code, ratter than create it: http://www.xach.com/naggum/articles/3064225496493947@naggum.no.html http://www.xach.com/naggum/articles/3064225496493947@naggum....
  - calibraxis 15y ago
    You might be interested in the debates between Stallman and Sandewall. It's in _Interactive Programming Environments_; Stallman took the side of text editing, and Sandewall took the side of structure editing. The book is maybe a good gift for Lisp history nuts, and it's only $3 used on amazon.com.
pshc 15y ago
It is a huge UI problem. For example, it's tempting to start adding flashy chrome to a structure editor just because you can. Pretty Lisp's rounded rectangles are obviously not going to scale to real programs; they generate a lot of noise. Visually, an ideal structure editor looks a lot like the text-format code we have today for its readability. There's a lot of usability failure in Lisp's history but I know that a great structure editor is possible.

calibraxis 15y ago

Sounds unlikely. May I ask what experience you had with 1980's structure editors (presumably Interlisp)? My reading of history is that it wasn't rejected by users, but rather killed off by MacLisp implementors teaming up to create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to consolidate Lisp). (https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2SYUk/EoSmODsX7WgJ https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2...) Paredit, a favorite among modern Lisp users, was directly inspired by Interlisp's structure editing. Paredit's own author calls it a "cheesy imitation" of Interlisp. (http://mumble.net/~campbell/emacs/paredit.credits http://mumble.net/~campbell/emacs/paredit.credits) Personally, I think Lisp is ripe for many different visual/kinesthetic interpretations, and this one certainly is pretty.

sedachv 15y ago
Paredit is nice, but barely works for stock Lisp syntax. One of the best things about Common Lisp is reader macros, and in order to integrate them with structured editing, you'd need to change the reader macro mechanism to be based around a composable context-free grammar description that can be shared between the reader and the structure editor. I'm pretty sure that's still an open research problem. Personally I think structured editing is an idea that seems great until you actually try it.
- calibraxis 15y ago
  At least among the Emacs-using Common Lisp users I've known (and discussed the topic with), Paredit is considered a clear win. Same in my experience. What do you use? If there's something better, I'd be happy to use it. (When I last observed someone editing Common Lisp code without turning on Paredit, it was rather depressing, how much time he spent closing parens and re-indenting everything. But maybe you use something else which avoids this problem?) Reader macros (in the worst-case scenario you describe) are a very rare use-case, and therefore probably not worth optimizing an IDE for. Perhaps for you they're common, but I'm virtually certain that most Common Lisp users have never written even one. If macros are already uncommon to write, reader macros have a far higher bar of justification.
  - sedachv 15y ago
    I started using Paredit in 2010, and wrote Lisp in Emacs for 7 years before that. Paredit make some things very convenient, but I can't say it has sped up my programming significantly. It has made it a lot more convenient for me to use the REPL, which has changed my programming style. Two things that save time when indenting code and work in all Emacs programming modes: 1. (global-set-key (kbd "RET") 'newline-and-indent) in .emacs to automatically indent every newline (also points out problems in your syntax right away) 2. C-Space to start region selection, C-M-b or C-M-f to jump back/forward a code block (s-exp), then C-M-\ to reindent region. The other thing I use is my https://github.com/vsedach/mouse-copy https://github.com/vsedach/mouse-copy mode for "structured" copy and paste. It's convenient sometimes. I use reader macros a lot more than Common Lisp programmers do now, and I encourage people to use them and think that reader macro usage will become more widespread, in particular due to Tobias Rittweiler's named-readtables library (http://common-lisp.net/project/named-readtables/ http://common-lisp.net/project/named-readtables/). In particular, I use cl-interpol (http://weitz.de/cl-interpol/ http://weitz.de/cl-interpol/) both for string interpolation and to do HTML templating (http://paste.lisp.org/display/118522 http://paste.lisp.org/display/118522). I also wrote a uri-temple library for Common Lisp (http://common-lisp.net/project/uri-template/ http://common-lisp.net/project/uri-template/). When I used CL-SQL, I used its reader macro syntax, and I thought it was worthwhile, but could have been better designed.
- colonel_panic 15y ago
  Maybe it would work if you designed a language with structured editing in mind from the start.
pavelludiq 15y ago
I'm a lisp history nut, but I wasn't around at that time. Paredid doesn't really turn emacs into a structure editor, its more like a "standard editor with some of the better ideas of structure editors miked in" kind of mode. Structure editors introduce a lot of complexity in general. Maybe Interlisp was able to work well in practice despite the added complexity, I don't know, I really would like to know more about such systems. As for your last sentence, Erik Naggum who had a bad opinion on structure editors in general, seems to have liked the idea of a structure inspector, as in using such tools to inspect code, ratter than create it: http://www.xach.com/naggum/articles/3064225496493947@naggum.no.html http://www.xach.com/naggum/articles/3064225496493947@naggum....
- calibraxis 15y ago
  You might be interested in the debates between Stallman and Sandewall. It's in _Interactive Programming Environments_; Stallman took the side of text editing, and Sandewall took the side of structure editing. The book is maybe a good gift for Lisp history nuts, and it's only $3 used on amazon.com.

pshc 15y ago

It is a huge UI problem. For example, it's tempting to start adding flashy chrome to a structure editor just because you can. Pretty Lisp's rounded rectangles are obviously not going to scale to real programs; they generate a lot of noise. Visually, an ideal structure editor looks a lot like the text-format code we have today for its readability. There's a lot of usability failure in Lisp's history but I know that a great structure editor is possible.