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