4 ms·

Man AST editors are so hard to get right. I've tried many of them, this one (Golem) included, but it's just very hard to kill the habit of wanting to move aroun

Man AST editors are so hard to get right. I've tried many of them, this one (Golem) included, but it's just very hard to kill the habit of wanting to move around/delete single text characters. Because of that, many people give up and don't move past the initial stage. I think what we need is "Elm error messages" (http://elm-lang.org/blog/compiler-errors-for-humans http://elm-lang.org/blog/compiler-errors-for-humans) for AST editors. Take paredit for example. If you're trying to delete a closing parenthesis, instead of refusing to do so and silently fail, display a tooltip that explains why such action is disallowed, and a list of (heck, hard-coded even, like some Elm errors) likely actions the user's trying to take. Deleting the list? Deleting just a token? Show the keybindings. Or even automatically pick the most likely action after a second invalid delete attempt. I actually believe the constraints imposed by structural editing can be very beneficial (again, see paredit which helps your program stay syntactically valid). But constraints are good when they're visible. You can exhaustively check what's there. Constraints are frustrating when they're invisible and you repeatedly accidentally stumble against them. (Ideally you'd also provide a free-form mode where you can edit things as plain text. But from personal experience I'd just go back to this instead of learning the AST editing keybindings.)

deleted 11y ago
[deleted]
CMCDragonkai 11y ago
The AST editor golem is really cool. But the habit of wanting to move around and delete single text characters can be trained out of you, just like people who use vim.
- chenglou 11y ago
  Right, and I'm saying that a huge amount of users wouldn't pass that initial barrier of training before dropping it. Vim's ubiquity, general applicability and community helped it achieve popularity; I do think it succeeded despite having less stellar error prompts as I described above. Current AST editors are frequently domain/language-specific and don't have the advantage of e.g. general applicability, so they need much better error prompts and other hand-holding stuff to make up for it.
  - rjknight 11y ago
    Right, and I'm saying that a huge amount of users wouldn't pass that initial barrier of training before dropping it. This may be the case. But these people (myself included!) are getting older by the day, and will eventually die or move into management roles. The students in the audience of the talk may well end up working at Facebook using AST editors, and in 10 years that will simply be the new normal.
baghead66 11y ago
I prefer "Eliza error messages". That said, congrats.
lomnakkus 11y ago
This makes it near-useless for me as well. The thing I'm wondering is why people are so obsessed with this kind of AST editing. I don't find that code text entry speed is the limiting factor for any of my coding. The limiting factor is usually a) understanding the problem well enough, and b) understanding the existing code well enough. A good IDE with symbol/type and usage lookup usually suffices for the latter. EDIT: If the point here is to prevent invalid ASTs, then I don't really see how much that helps. The number of invalid programs with valid ASTs is going to be huge, so you need good error handling anyway.
- kpmah 11y ago
  It lets you do some nice things. You can always get instant feedback (types, errors) because your code is always a valid AST. No ambiguous braces etc. Also things like markdown comments and inline evaluation. My attempt: http://sediment.io http://sediment.io
  - CMCDragonkai 11y ago
    Is it possible to make structure editors work for whitespace sensitive languages like Haskell? Limiting AST editors to just lisp is a bit weird.
    - kpmah 11y ago
      The reason AST editors look a lot like lisp is because lisp pretty much is just an AST. There's no technical reason the AST can't be a more complicated structure than a list, and you can present the AST any way you want - you don't have to show parenthesis. You can use mathematical symbols, whitespace, images, fonts... The problem is the further away you go from lists of symbols, the more complicated the AST is to edit and to present to the user, and the more complicated the interface is for the user. It's not an insurmountable problem though.
    - scottjad 11y ago
      https://github.com/chrisdone/structured-haskell-mode https://github.com/chrisdone/structured-haskell-mode
pinouchon 11y ago
Maybe something like parinfer (https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/) would help

deleted 11y ago

[deleted]

CMCDragonkai 11y ago

The AST editor golem is really cool. But the habit of wanting to move around and delete single text characters can be trained out of you, just like people who use vim.

chenglou 11y ago
Right, and I'm saying that a huge amount of users wouldn't pass that initial barrier of training before dropping it. Vim's ubiquity, general applicability and community helped it achieve popularity; I do think it succeeded despite having less stellar error prompts as I described above. Current AST editors are frequently domain/language-specific and don't have the advantage of e.g. general applicability, so they need much better error prompts and other hand-holding stuff to make up for it.
- rjknight 11y ago
  Right, and I'm saying that a huge amount of users wouldn't pass that initial barrier of training before dropping it. This may be the case. But these people (myself included!) are getting older by the day, and will eventually die or move into management roles. The students in the audience of the talk may well end up working at Facebook using AST editors, and in 10 years that will simply be the new normal.

baghead66 11y ago

I prefer "Eliza error messages". That said, congrats.

lomnakkus 11y ago

This makes it near-useless for me as well. The thing I'm wondering is why people are so obsessed with this kind of AST editing. I don't find that code text entry speed is the limiting factor for any of my coding. The limiting factor is usually a) understanding the problem well enough, and b) understanding the existing code well enough. A good IDE with symbol/type and usage lookup usually suffices for the latter. EDIT: If the point here is to prevent invalid ASTs, then I don't really see how much that helps. The number of invalid programs with valid ASTs is going to be huge, so you need good error handling anyway.

kpmah 11y ago
It lets you do some nice things. You can always get instant feedback (types, errors) because your code is always a valid AST. No ambiguous braces etc. Also things like markdown comments and inline evaluation. My attempt: http://sediment.io http://sediment.io
- CMCDragonkai 11y ago
  Is it possible to make structure editors work for whitespace sensitive languages like Haskell? Limiting AST editors to just lisp is a bit weird.
  - kpmah 11y ago
    The reason AST editors look a lot like lisp is because lisp pretty much is just an AST. There's no technical reason the AST can't be a more complicated structure than a list, and you can present the AST any way you want - you don't have to show parenthesis. You can use mathematical symbols, whitespace, images, fonts... The problem is the further away you go from lists of symbols, the more complicated the AST is to edit and to present to the user, and the more complicated the interface is for the user. It's not an insurmountable problem though.
  - scottjad 11y ago
    https://github.com/chrisdone/structured-haskell-mode https://github.com/chrisdone/structured-haskell-mode

pinouchon 11y ago

Maybe something like parinfer (https://shaunlebron.github.io/parinfer/ https://shaunlebron.github.io/parinfer/) would help