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.)
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.
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.
Are the semantics available anywhere? I've been waiting for someone to create a Lisp with pure/monadic IO, but I don't know whether Shem is what I imagine.
"Shem is a new compiled-to-JS, statically typed, pure-by-default functional programming language. The semantics are based on Haskell but the language evaluates strictly in a similar way to PureScript."
The document, unfortunately, doesn't go deeper into what about the semantics are derived from Haskell. A better HN title might be "Shem: a Statically Typed Compile-to-Javascript LISP".
[+] [-] chenglou|10 years ago|reply
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|10 years ago|reply
[+] [-] lomnakkus|10 years ago|reply
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.
[+] [-] CMCDragonkai|10 years ago|reply
[+] [-] baghead66|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] xixixao|10 years ago|reply
[+] [-] sooheon|10 years ago|reply
Actually, I do have a question: do you have a blog or thought dump I can read?
[+] [-] bkase|10 years ago|reply
[1] https://www.youtube.com/watch?v=HnZipJOan54 [2] http://shem.io/
[+] [-] ScottBurson|10 years ago|reply
[0] http://www.shenlanguage.org/
[+] [-] provemewrong|10 years ago|reply
[+] [-] yenda|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] techdragon|10 years ago|reply
The title translates to "biblical speak" pretty well haha
[+] [-] mikkom|10 years ago|reply
http://www.shenlanguage.org/
[+] [-] jamesfisher|10 years ago|reply
Are the semantics available anywhere? I've been waiting for someone to create a Lisp with pure/monadic IO, but I don't know whether Shem is what I imagine.
[+] [-] daxfohl|10 years ago|reply
[+] [-] izym|10 years ago|reply
[+] [-] reycharles|10 years ago|reply
[+] [-] kornish|10 years ago|reply
"Shem is a new compiled-to-JS, statically typed, pure-by-default functional programming language. The semantics are based on Haskell but the language evaluates strictly in a similar way to PureScript."
The document, unfortunately, doesn't go deeper into what about the semantics are derived from Haskell. A better HN title might be "Shem: a Statically Typed Compile-to-Javascript LISP".