Often, I found that the best (only?) way to edit some code I had written was to delete it and rewrite it again

[pbiggar]

A user says:

I was able to successfully deploy the MVP of my slack bot this weekend. It was amazing how fast it was to get up and running. Almost all my time was spent working on my actual application logic. The experience of typing out a line and then immediately returning to slack to test the changes was particularly magical.

That said, parts of the experience were a lot buggier than I was expecting, the editor in particular. Often, I found that the best (only?) way to edit some code I had written was to delete it and rewrite it again. Usually this was because I wasn't able to insert my cursor in the middle of a statement and edit it in the middle. Some examples:

If I want to convert an expression into a let statement my instinct is to put my cursor at the front of the line and type "let". The editor doesn't actually let me do this. When I try it now, nothing happens at all. To get the desired effect, I have to put my cursor at the end of the line and hit to insert a new line after it. This converts the current line into a let statement.

For another example, let's say I have an expression like a == b and realize later that I actually want to change it to a >= b. Again, my instinct is to use my cursor to highlight the first "=" in the operator and replace it with ">". In testing this just now I get several different, baffling results from this. In one case I end up with what looks like the correct result "a" >= "b" (in this case both operands are strings) but the who expression has been converted into a single string literal (""a" >= "b"") but without the outer quotes in place to make it clear what happened. In another test (I'm not sure what I did differently this time) attempting to change the operator condensed down the whole expression into the string "a>b". At least this time the editor makes it clear that the whole expression is a string literal by displaying the quote marks.

Another example that I came across a lot while developing my slack bot (though I can't seem to recreate now) involved accidentally creating new functions from fragments of variable names or other symbols. While editing some syntax I would hit space (to introduce a space a split a token into two) and get unexpectedly popped out into a new function view having inadvertently created a new function.

These are just a few examples to illustrate what made writing code with the editor difficult. While the above examples contain clear bugs, I think they all ultimately stem from the underlying philosophy of the structured editor. I think I understand this philosophy. I'm not editing text but rather editing the AST directly in ways that make it impossible to construct an invalid program. I honestly think this is a great idea and look forward to working with a more refined version of the concept. That said, the current presentation repeatedly tricks me into believing that I am editing text and convinces me I can edit it in ways that I actually can't. This leads to frustration.

I can see two alternatives. One is to try to create an editor that doesn't try to present the program as text but as something else (a tree maybe?). Users will have to learn a new way to edit this structure but at least they don't have to unlearn everything they think they know about editing text. The second is to allow people to actually edit the code as text and run it through a parser as with a normal programming language. This gives up some of the benefits of the structured editing approach but provides a more familiar experience while being easier to implement correctly.