[chenglou]

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

[pinouchon]

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

[lomnakkus]

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]

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

[lomnakkus]

That's a valid point, but if the compilation/IDE pipeline is arranged sensibly, you'll get those errors and insert a couple of ")" and get to the real meat of the issue a few seconds later...?

On the other hand... with an AST-only editor I now have to mentally tune in even more to the way the editor will behave while typing code and any deviation from the expected behavior becomes absolutely crippling[1]. For me, personally, this can become more overhead than it's worth to correct a few misplaced ")" or "]" or ";" or whatever when I've finished typing the gist of my idea. (I honestly don't know what would be faster overall, and I suspect it depends on hideously complex factors like "how much time do you intend to spend on learning IDE-X vs. learning to 'edit files', etc. I guess we could start with studies on "does it work?" as in medicine, even if we have no clue as to how it supposedly works.)

I'm saying that given the enormous success (all things considered, etc.) of text-based editing the claimants have the burden of proof.

(Actually, I'll happily admit that I was at one point on the hype-train regarding AST-editing, but I'm more skeptical these days. The thing is that it's easy to produce the 80% solution at to make it look awesome, but the problem is that getting those last 10% is a killer. Just look at Chris Granger's project for an example of just how difficult it is to get to 90%.)

[1] The machine is a machine and can do ASTs perfectly all day long, but if I'm a bit sleepy or drunk it suddenly becomes impossible to edit and type in code because I can't do a perfect job at prediction...? That would be strange indeed!

[baghead66]

Awesome.

Naive question; is "defn" really necessary?, isn't "let" and "lambda" enough to express a program?.

[diminishedprime]

One thing I've noticed is depending on how your code is being compiled/transpiled, having smaller defn's over them being nested in a let can lead to better performance since inlining becomes an easier problem.

This is particularly true in clojure, since it's being compiled to java byte-code, and the jvm has a few default settings for how deep it'll look into the call tree for inlining. See https://www.youtube.com/watch?v=0tUrbf6Uzu8 for a talk that mentions this.

[kpmah]

You're right, it's not necessary, it's just a preference :)

Although it does 'flatten' the bindings. Defn a, Defn b… is the same as let a = … in let b = … in …

[CMCDragonkai]

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]

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]

https://github.com/chrisdone/structured-haskell-mode

[CMCDragonkai]

It can allow you to edit code faster, make changes faster, refactor faster, because rather than editing at the "text-level" abstraction, you're editing at the "code-level" abstraction. By itself it's not that useful, but combine it with type awareness, semantic awareness, you have an expert system, not just a code editor.

[lomnakkus]

> It can allow you to edit code faster, make changes faster, refactor faster, because rather than editing at the "text-level" abstraction, you're editing at the "code-level" abstraction.

I explicitly stated that I at least don't perceive editing (keystroke) speed as a limiting factor, so I'm not sure what you're trying to say. My perceptions may obviously be wrong, but I think this places the burden of proof on those claiming an improvement.

My point (or contention, if you will) is that the power gained through local refactoring like this (moving a bunch of parenthesized code around quickly) is absolutely negligable in the grand scheme of things.

> By itself it's not that useful, but combine it with type awareness, semantic awareness, you have an expert system, not just a code editor.

That's really the crux isn't it? I can only say that I haven't seen anything even close to this yet even from AST-only editors, and we've been promised it for sooooo many years.

As of now IntelliJ IDEA/Eclipse can do far more advanced refactorings at the press of a few buttons... and some of these refactorings are actually non-trivial -- as opposed to just doing a block-select and moving code.

Granted, I'm sure they have a lot of code to achieve that, but I'd wager that the actual parsing from text->AST is a very minor portion of the refactoring code. I'm pretty sure the most difficult bit of that refactoring code is the bit that guarantees that the refactor preserves semantics.

EDIT: What I'm saying is basically this: I think it's naïve to think that the AST is the big problem when doing IDE/editor-supported refactoring.

[CMCDragonkai]

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]

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]

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]

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