I'd say the opposite - in your shoes, I'd just try it, doomed or not! (But then again building an IDE is My Thing atm - check my profile.) Building one of these systems is going to be really fun.
If you don't have the time/inclination to just do it cause it's a cool project, one option is to "paper prototype" the feasibility of the transforms you'd need.
Next time you're writing any code in the first language you want to support in that AST editor, take a screen recording of at least half an hour's coding. Watch it back later, and keep a count of how many times you:
* transition from one valid program to another in a simple way (eg just writing a line of code from scratch that's valid first time)
* transition in a way that would require abandoning your keyboard and reaching for your mouse in your editor (NB this is a seriously slow operation, usually taking a couple of seconds or more).
* transition in a complex way your editor would support if it had that kind of transform built in (eg if/else-> switch), and work out exactly how clever that transform would have to be (would it work if the if/elses weren't simple equality checks? If they weren't, how would you make the transform if you weren't allowed any non-compiling code?) Then enumerate the distinct such transforms you'd need to cover that half-hour of typing. (You will probably discover a Pareto-type distribution - the question is how tight the head/long the tail is. My guess is you'd need a huge number of special transforms to cover 95% of your edits, but data beats guessing)
* Jump around between statements (eg half-write something, leave it in an utterly broken state, then go actually define the variable/function you're using, then jump back and finish your thought). Your editor would have to permit this somehow or it will be really frustrating to use.
Thanks for the reply meredydd. That does seem like a good approach.
Actually, I spent 1.5 years building an editor in this style (see link in my original post here) while working at a grocery store :)
Unfortunately, while I can see now that I should have first been super focused on validating the concept—I instead just kind of ran with it, assuming it was going to work, and built this massive, probably over-engineered, framework for generating editors for given grammars (with my starting point being: not even knowing what a grammar was, thinking I'd have to invent some kind of 'linguistic constraint description' format ;) ).
As it stands the editing portion works well enough for a demo, but the program never reached the point where I could write code with it, so a lot of these questions are still un answered for me. I think doing the paper prototype on these edit actions would be a good pre-coding validation step.
I did check out Anvil briefly. My two second, potentially incorrect summary would be VB for web apps. Is that close? Are you guys doing anything special for working with text itself?
"VB for web apps" is a fair summary. We made a conscious decision against anything AST-based (for the reasons I outlined above), and we're about to deploy an Intellisense-style autocompleter instead. Our general philosophy is that coding is fine - it's the web/Javascript ecosystem that's the problem. We fix that, then get out of the way and let you write code :)
As for validating one's side projects before starting work - I personally think the Lean Startup thing can be taken a bit far. An interesting leisure-time technical project doesn't need the same level of prior justification as a big commercial project (even if it might one day evolve into one), as long as you're having fun. We do this stuff because we enjoy it!
> it's the web/Javascript ecosystem that's the problem.
I agree—that's definitely the bigger issue. I think differences between editors and languages tend to be overblown in general.
Unfortunately the project for me was not quite a fun thing: I ran into an issue with mouse/keyboard overuse, so I was trying to build an editor that could work efficiently with motion sensors. In the meantime, coding was painful :/ I'm still looking for an alternative for that reason—but VR and mobile also have needs for efficient editors that can be operated with fewer unique symbols.
Also, another solution to the AST editor issue: just convert any non-parsing nodes into plain text nodes until they're fixed.
If you don't have the time/inclination to just do it cause it's a cool project, one option is to "paper prototype" the feasibility of the transforms you'd need.
Next time you're writing any code in the first language you want to support in that AST editor, take a screen recording of at least half an hour's coding. Watch it back later, and keep a count of how many times you:
* transition from one valid program to another in a simple way (eg just writing a line of code from scratch that's valid first time)
* transition in a way that would require abandoning your keyboard and reaching for your mouse in your editor (NB this is a seriously slow operation, usually taking a couple of seconds or more).
* transition in a complex way your editor would support if it had that kind of transform built in (eg if/else-> switch), and work out exactly how clever that transform would have to be (would it work if the if/elses weren't simple equality checks? If they weren't, how would you make the transform if you weren't allowed any non-compiling code?) Then enumerate the distinct such transforms you'd need to cover that half-hour of typing. (You will probably discover a Pareto-type distribution - the question is how tight the head/long the tail is. My guess is you'd need a huge number of special transforms to cover 95% of your edits, but data beats guessing)
* Jump around between statements (eg half-write something, leave it in an utterly broken state, then go actually define the variable/function you're using, then jump back and finish your thought). Your editor would have to permit this somehow or it will be really frustrating to use.