4 ms·

Looking sweet. The future is in structural editors. The client-server separation is a nice bonus. Unfortunately this is running up against the UI problem. How

by pshc 15y ago

Looking sweet. The future is in structural editors. The client-server separation is a nice bonus. Unfortunately this is running up against the UI problem. How do you make this intuitive and powerful? A lot of hard work on usability is needed to get up to par with text editors. Very glad to see it being tackled.

CoffeeDregs 15y ago
> The future is in structural editors. I liked CodeBubbles, but do you have any other examples of structural editors for generic programming? Obviously, UI-centric editors and LabView are structural editors, but for very specific domains.
- pshc 15y ago
  EastWest is one that comes to mind. I aim to write one, but that's a long time coming.
- rsl7 15y ago
  I used one called Genie Pascal in 1988, out of CMU, on the Mac Plus. They did lots of work on supporting various languages. http://www.cs.cmu.edu/~pane/ile.html http://www.cs.cmu.edu/~pane/ile.html
pavelludiq 15y ago
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.
- 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.

by pshc 15y ago

CoffeeDregs 15y ago

> The future is in structural editors. I liked CodeBubbles, but do you have any other examples of structural editors for generic programming? Obviously, UI-centric editors and LabView are structural editors, but for very specific domains.

pshc 15y ago
EastWest is one that comes to mind. I aim to write one, but that's a long time coming.
rsl7 15y ago
I used one called Genie Pascal in 1988, out of CMU, on the Mac Plus. They did lots of work on supporting various languages. http://www.cs.cmu.edu/~pane/ile.html http://www.cs.cmu.edu/~pane/ile.html

pavelludiq 15y ago

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