7 ms·

I've been working on a Structured Code Editor for a couple of years: https://i.imgur.com/wvcduDk.png https://i.imgur.com/wvcduDk.png (in the picture above "st

by BoppreH 12y ago

I've been working on a Structured Code Editor for a couple of years: https://i.imgur.com/wvcduDk.png https://i.imgur.com/wvcduDk.png (in the picture above "string" is selected, and "find" is slightly highlighted because its on the same level. this helps visualize the tree and plan your movements) It actually started as my final project during undergrad. Here's my 78-page thesis on it (unfortunately Portuguese, but has English pictures): https://projetos.inf.ufsc.br/arquivos_projetos/projeto_1398/editor-estruturado.pdf.1 https://projetos.inf.ufsc.br/arquivos_projetos/projeto_1398/... Structured editing is much, much, MUCH better suited for programming than plain text. Syntax preservation and source-display separation are game changers, and they are not the only benefits. Unfortunately it has a Vim-level difficulty curve and people don't realize how much time they currently waste on syntax mucking. This makes marketing kinda hard, even with a fully operational and well polished implementation. Fun fact: structured editing also works with non-programming structured text, like JSON, HTML and CSS!

makmanalp 12y ago
Very neat! I think the issue with high learning curve tools is not that the learning curve is high, it's that the benefit seems (rightly) dubious at the beginning. You can find videos of people whizzing along with emacs or vim, and it's not difficult to see the productivity gain. So it'd be cool if you had a video of what it looks like to program with this thing.
- BoppreH 12y ago
  Thank you, and you're absolutely correct. I think a side-by-side video comparison would work even better, because it's not immediately clear how much time is spent moving commas around, playing with whitespace or hunting parenthesis. That said, I'm not trying to convert people just yet. It still needs polishing and support for a few more languages (right now it only does Lua, Python and basic Lisp, which is not very exciting).
  - RootDynasty 12y ago
    Is your editor open source? It looks really interesting.
    - BoppreH 12y ago
      I haven't opened it yet for two reasons: 1) Premature open-sourcing complicates commercial projects, and a man gotta eat. 2) Because it would be a first, any flaws in the implementation will be assigned to the concept of structured editing itself, hurting the development of alternative implementations. Even if my vision of it fails, I want other people to have a shot without fighting incorrectly formed opinions. In the end, it's the ideas and not the source that are important. It's like developing for VR now, or mobile a few years ago. The space of possible interfaces is so big that most of the effort goes into combing it.
    - deleted 12y ago
      [deleted]
seanmcdirmid 12y ago
> Structured editing is much, much, MUCH better suited for programming than plain text. Syntax preservation and source-display separation are game changers, and they are not the only benefits. You can do a lot of things with a parser and a rich code editor...e.g. http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx http://research.microsoft.com/en-us/projects/liveprogramming... Parsing is just a detail, if you can get it right, you don't necessarily need a structured or projected text editor. And its not even the "big" detail, which would definitely be type checking, and structural isn't going to help you much there (that is, if you want any kind of fluidity).
- BoppreH 12y ago
  Interesting research, specially because it has a lower learning curve. I see it as a halfway between fully structured and fully textual. The large screenshot[0] is a textbook example of structured editor, but the cursor moves around as if it was text. It looks like the document is modeled as a combination of complete structures plus a few incomplete pieces of text. That's interesting because you get the benefits of structured display without paying for structured input. However, I'm not sure I would use this. It's not clear how to call the Δ function, for example. You can consult the manual or ctrl+c the character, but that's not desirable. Also, does erasing the dot after ≱ yield ≥ or ≯? I do like structured input. You type an awful lot less and there's no meddling with commas and parenthesis. The learning curve is tough, but Vim users are here to prove people are willing. If structured editing lives up to the hype, of course. Anyway, I'm always glad to see research in this area. [0] http://research.microsoft.com/en-us/projects/liveprogramming/tp5.png http://research.microsoft.com/en-us/projects/liveprogramming...
  - seanmcdirmid 11y ago
    > Also, does erasing the dot after ≱ yield ≥ or ≯? Yes. Actually, in my newest prototype, the dots disappear and we treat ≱ as having 3 characters (the first is !, the second is >, the third =). Deleting the first character is deleting the ! (you get ≥), or deleting the last character is deleting the = (you get ≯).
mkramlich 12y ago
I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros right, on 1st attempt, becomes nearly effortless, once in that frame of mind. It's the think-design-code-test loop that is the biggest driver on my time/energy/brain cost. Not syntax conformance. Conformance becomes like a musician having played a certain instrument for enough years, you acquire muscle/eye memory for what note requires what finger/body/mouth positions/behaviors, nearly a one-to-one map, autonomous. Do agree that anything that enforces syntax correctness, upfront, is helpful for newbies, especially "forever newbie" use cases, the non-expert users.
- BoppreH 12y ago
  Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the keyboard. Three or four seconds, and to me feels like using a blunt knife. And yet you are just moving one element down a list. You do it all day with parameters in a function, statements in a block, items in a literal list. Which is why it has a dedicated command in my editor: "Move down" (https://i.imgur.com/wvcduDk.png https://i.imgur.com/wvcduDk.png). It's a single key. Works in all cases mentioned, for all supported formats. I'm not saying a structured editor is for people who forget semicolons. It's for people who have to work with semicolons.
  - mkramlich 12y ago
    again... I hear you. been there, done that, have the T-shirt, over 35 years of coding in multiple domains, including GUIs, graphics, games, code-driven visual layouts, etc. and I'm saying with a low-overhead deterministic-optimized editor like vim, and the right person at the keyboard, this can be done very quickly and accurately. and again, to continue your example, the hard part is not getting the syntax correct it's ensuring the resulting visual image -- your example suggests a vectory visual artifact ala OpenGL or SVG, etc. -- has the right shape and position. Syntax is something my brain/eye system just tells me, instantly, RIGHT or WRONG. our brains are great at this. I'm not saying you're wrong. I'm saying for non-newb, non-lame programmers it's a use case that optimizes for a cost that's one of the smallest costs imposed on the programmer. not unlike "premature optimization". I'm not saying syntax-enforcing keystrokes are a bad thing. I do think there are benefits to having a set of syntax-generic consistent keystrokes, like vim, across all the various syntaxes one has to deal with, day in and day out. If the only thing I ever had to edit was C files or JSON, that's it, nothing else, then yes having a C or JSON-semantic keystroke-restricted inescapable mode (with prompts, wizards, etc.) would be a help. (Which arguably is how all the big fat modern IDEs have evolved towards anyway.) But I'm very aware of the phenomenon where one can gain in the small but lose in the large. Local maxima, etc. Also benefits to having screen match print, etc. Being grep-friendly, diff-friendly, textual VCS-optimized friendly, etc. Local maxima. The sneakiest wrongs are right in the small.
chipsy 11y ago
Something I notice about the UI you use is that it tries very hard to emphasize the structured-ness of the underlying engine. Perhaps the middle ground goes back towards Emacs(or rather, a new iteration of the Emacs concept) - plain old text editing is the default, but the underlying editing engine is always working in structured form. Ultimately, I have to concur with the people calling out the lack of need; if my sustained average is 80 lines of code per day, I'm not being bottlenecked by my type time, but I am bottlenecked by typing errors that cascade to runtime. I would welcome seeing more modes that simplify specific, necessary-but-error-prone tasks like copy-paste-modify.
cheery 11y ago
I consider vim as a tarpit because it accelerates writing text without syntactic recognition. That is, it may inhibit reception of a better programming tool by being just too well designed for what it is used for. I have personally invested my time in the subject before with varying success. I'd like to see, study and try out your editor, perhaps even to contribute into it.

by BoppreH 12y ago

makmanalp 12y ago

Very neat! I think the issue with high learning curve tools is not that the learning curve is high, it's that the benefit seems (rightly) dubious at the beginning. You can find videos of people whizzing along with emacs or vim, and it's not difficult to see the productivity gain. So it'd be cool if you had a video of what it looks like to program with this thing.

BoppreH 12y ago
Thank you, and you're absolutely correct. I think a side-by-side video comparison would work even better, because it's not immediately clear how much time is spent moving commas around, playing with whitespace or hunting parenthesis. That said, I'm not trying to convert people just yet. It still needs polishing and support for a few more languages (right now it only does Lua, Python and basic Lisp, which is not very exciting).
- RootDynasty 12y ago
  Is your editor open source? It looks really interesting.
  - BoppreH 12y ago
    I haven't opened it yet for two reasons: 1) Premature open-sourcing complicates commercial projects, and a man gotta eat. 2) Because it would be a first, any flaws in the implementation will be assigned to the concept of structured editing itself, hurting the development of alternative implementations. Even if my vision of it fails, I want other people to have a shot without fighting incorrectly formed opinions. In the end, it's the ideas and not the source that are important. It's like developing for VR now, or mobile a few years ago. The space of possible interfaces is so big that most of the effort goes into combing it.
  - deleted 12y ago
    [deleted]

seanmcdirmid 12y ago

> Structured editing is much, much, MUCH better suited for programming than plain text. Syntax preservation and source-display separation are game changers, and they are not the only benefits. You can do a lot of things with a parser and a rich code editor...e.g. http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx http://research.microsoft.com/en-us/projects/liveprogramming... Parsing is just a detail, if you can get it right, you don't necessarily need a structured or projected text editor. And its not even the "big" detail, which would definitely be type checking, and structural isn't going to help you much there (that is, if you want any kind of fluidity).

BoppreH 12y ago
Interesting research, specially because it has a lower learning curve. I see it as a halfway between fully structured and fully textual. The large screenshot[0] is a textbook example of structured editor, but the cursor moves around as if it was text. It looks like the document is modeled as a combination of complete structures plus a few incomplete pieces of text. That's interesting because you get the benefits of structured display without paying for structured input. However, I'm not sure I would use this. It's not clear how to call the Δ function, for example. You can consult the manual or ctrl+c the character, but that's not desirable. Also, does erasing the dot after ≱ yield ≥ or ≯? I do like structured input. You type an awful lot less and there's no meddling with commas and parenthesis. The learning curve is tough, but Vim users are here to prove people are willing. If structured editing lives up to the hype, of course. Anyway, I'm always glad to see research in this area. [0] http://research.microsoft.com/en-us/projects/liveprogramming/tp5.png http://research.microsoft.com/en-us/projects/liveprogramming...
- seanmcdirmid 11y ago
  > Also, does erasing the dot after ≱ yield ≥ or ≯? Yes. Actually, in my newest prototype, the dots disappear and we treat ≱ as having 3 characters (the first is !, the second is >, the third =). Deleting the first character is deleting the ! (you get ≥), or deleting the last character is deleting the = (you get ≯).

mkramlich 12y ago

I hear what you're saying. But I've been programming for 35 years. I've found that getting syntax right is at worst a tiny percentage of my time/energy/brain cost when doing programming. Once out of the newb phase. Once I've fully grokked the language and I've had enough ramp-up that I'm in "the zone" it's nearly effortless to type syntax-perfect code on my 1st attempt. Even getting built-in library calls and macros right, on 1st attempt, becomes nearly effortless, once in that frame of mind. It's the think-design-code-test loop that is the biggest driver on my time/energy/brain cost. Not syntax conformance. Conformance becomes like a musician having played a certain instrument for enough years, you acquire muscle/eye memory for what note requires what finger/body/mouth positions/behaviors, nearly a one-to-one map, autonomous. Do agree that anything that enforces syntax correctness, upfront, is helpful for newbies, especially "forever newbie" use cases, the non-expert users.

BoppreH 12y ago
Try this exercise: change the first line into the second, with the cursor starting at the caret. Do it slowly and pay attention to each key you touch. lineTo((10, 35), (20, 15)) ^ lineTo((20, 15), (10, 35)) Maybe you had to hold Ctrl+Shift and mash the right arrow to select the first tuple, and then Ctrl+X. Or you typed "d2t,", paying attention to the inner comma. Probably between 10 and 20 movements, all over the keyboard. Three or four seconds, and to me feels like using a blunt knife. And yet you are just moving one element down a list. You do it all day with parameters in a function, statements in a block, items in a literal list. Which is why it has a dedicated command in my editor: "Move down" (https://i.imgur.com/wvcduDk.png https://i.imgur.com/wvcduDk.png). It's a single key. Works in all cases mentioned, for all supported formats. I'm not saying a structured editor is for people who forget semicolons. It's for people who have to work with semicolons.
- mkramlich 12y ago
  again... I hear you. been there, done that, have the T-shirt, over 35 years of coding in multiple domains, including GUIs, graphics, games, code-driven visual layouts, etc. and I'm saying with a low-overhead deterministic-optimized editor like vim, and the right person at the keyboard, this can be done very quickly and accurately. and again, to continue your example, the hard part is not getting the syntax correct it's ensuring the resulting visual image -- your example suggests a vectory visual artifact ala OpenGL or SVG, etc. -- has the right shape and position. Syntax is something my brain/eye system just tells me, instantly, RIGHT or WRONG. our brains are great at this. I'm not saying you're wrong. I'm saying for non-newb, non-lame programmers it's a use case that optimizes for a cost that's one of the smallest costs imposed on the programmer. not unlike "premature optimization". I'm not saying syntax-enforcing keystrokes are a bad thing. I do think there are benefits to having a set of syntax-generic consistent keystrokes, like vim, across all the various syntaxes one has to deal with, day in and day out. If the only thing I ever had to edit was C files or JSON, that's it, nothing else, then yes having a C or JSON-semantic keystroke-restricted inescapable mode (with prompts, wizards, etc.) would be a help. (Which arguably is how all the big fat modern IDEs have evolved towards anyway.) But I'm very aware of the phenomenon where one can gain in the small but lose in the large. Local maxima, etc. Also benefits to having screen match print, etc. Being grep-friendly, diff-friendly, textual VCS-optimized friendly, etc. Local maxima. The sneakiest wrongs are right in the small.

chipsy 11y ago

Something I notice about the UI you use is that it tries very hard to emphasize the structured-ness of the underlying engine. Perhaps the middle ground goes back towards Emacs(or rather, a new iteration of the Emacs concept) - plain old text editing is the default, but the underlying editing engine is always working in structured form. Ultimately, I have to concur with the people calling out the lack of need; if my sustained average is 80 lines of code per day, I'm not being bottlenecked by my type time, but I am bottlenecked by typing errors that cascade to runtime. I would welcome seeing more modes that simplify specific, necessary-but-error-prone tasks like copy-paste-modify.

cheery 11y ago

I consider vim as a tarpit because it accelerates writing text without syntactic recognition. That is, it may inhibit reception of a better programming tool by being just too well designed for what it is used for. I have personally invested my time in the subject before with varying success. I'd like to see, study and try out your editor, perhaps even to contribute into it.