4 ms·

Regarding the 'code without syntax' part: I wrote something that basically does this for any language that you have an EBNF grammar for. It turns the grammar in

Regarding the 'code without syntax' part: I wrote something that basically does this for any language that you have an EBNF grammar for. It turns the grammar into a graph; wherever your cursor is in the document at a given moment corresponds to some node in the graph; the edges going out of that node are the syntactically valid things you can insert from that point. Unfortunately there is no UI for it atm—though there is UI for the editing portion (which almost exactly matches the author's .gif at the end of the document): https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be&t=1m36s https://www.youtube.com/watch?v=tztmgCcZaM4&feature=youtu.be... It's a concept that a lot of people have explored. My understanding is that some academics were interested in it a while ago but never produced anything that worked well and kind of wrote it off. Now some people are revisiting it (e.g. Unison[1] and Jetbrains MPS[2]). I think the core idea involved is a shift away from using text as a model for representing programs; instead, interact with more abstract representations of code, and render those abstractions as text. This allows your editor to have better understanding of the language you're using, so syntax becomes a property of a language's visualization rather than something totally central to it (and now you don't have to memorize it!). [1] http://unisonweb.org/2015-05-07/about.html http://unisonweb.org/2015-05-07/about.html [2] https://www.jetbrains.com/mps/ https://www.jetbrains.com/mps/

meredydd 10y ago
The problem with these environments is that humans routinely want to write syntactically incorrect code as they transition from one valid program to another. An AST-based editor like this enforces that every intermediate step must parse as a valid program. This restriction makes making changes a massive pain in the ass, because you can no longer take the shortest route from where you are to where you want to be. For example, imagine you're restructuring an if-else sequence into a switch statement. You're probably going to change that first "if" to a "switch", then go down changing all the "else"s into "case"s. This is eminently sensible, but an AST-based editor will stop you dead if you try to do this, because the intermediate states are not valid ASTs. The only system slightly like this I've seen in widespread use is Paredit, which prevents you typing anything that isn't a valid s-expression. This only works because s-expression syntax is so minimal, and most of Lisp's actual syntax is layered on top with macros. Even if you're using Paredit, your spit/slurp/kill operations will produce invalid intermediate code that would fail to compile.
- westoncb 10y ago
  That's an interesting point. I've heard other people bring up this issue in a vague way, but your example makes it clear why people would have a concern about this. At the same time, however, I'm not convinced it's a serious issue—it's more important to save work and avoid re-typing the shell of a switch when you have to type it one character at a time. If you're mapping language constructs to single keys (this was the way I went), you can crank out a new multi-block switch statement in a few keystrokes; then (in my editor anyway), you can just drag the code blocks from the if statements into the new structure. Even better, since the editor has easy access to info about language structure, it could include automatic transformations to transition between structurally similar language constructs. I think it seems unnatural at first because we're so used to typing characters out one at a time, and it seems like we're throwing that skill out the window when considering an alternate form of editor. I still don't really see an intrinsic limit though. I'd appreciate any other counter-example you may have (a lot of why I don't continue working on my own project at the moment is concern that these are lurking and I'll only discover them after lots more wasted effort—so if I could definitively rule out that this project is a good idea, that'd be great.)
  - meredydd 10y ago
    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.
sakamies 10y ago
Your editor looks insanely slick! I had no idea there was prior work in this area. It sounds like your editor could trivially support html. That last paragraph is exactly what I was thinking with foolproof html, except applied to markup/data languages. Is your editor available to try somewhere?
- westoncb 10y ago
  Thanks! Unfortunately it's not available to try. I spent a lot of time building it in my free time and eventually got burnt out :/ It's still not to a point where it's usable (it's edit only). I'd love to revisit the project in some form, but time/money/other projects are obstacles at the moment. I still think the concept has merit, but the implementation is more difficult than it seems (including lower-level design decisions, e.g., like the discussion in the other comment here). Good luck to you if you do give it a try, though. If nothing else, you'll probably learn a lot ;) There's a little more info on the project here, btw, if you're curious: http://westoncb.com/projects/tiledtext http://westoncb.com/projects/tiledtext
  - sakamies 10y ago
    My story is kind of similar, including the wrist pain part. I've been brewing this thing for a bit over ten years. I got burnt out for other work and the editor some years ago and had to take a long break. Last year I started about the tenth new prototype and finally got it on a path that I think could lead to something that actually works. This time I'm trying to give away the code, ideas and everything, so maybe someday someone would continue the work so I won't have to. I just want to see it get made somehow and use the damn thing.
    - westoncb 10y ago
      Hehe, I know the feeling.

meredydd 10y ago

The problem with these environments is that humans routinely want to write syntactically incorrect code as they transition from one valid program to another. An AST-based editor like this enforces that every intermediate step must parse as a valid program. This restriction makes making changes a massive pain in the ass, because you can no longer take the shortest route from where you are to where you want to be. For example, imagine you're restructuring an if-else sequence into a switch statement. You're probably going to change that first "if" to a "switch", then go down changing all the "else"s into "case"s. This is eminently sensible, but an AST-based editor will stop you dead if you try to do this, because the intermediate states are not valid ASTs. The only system slightly like this I've seen in widespread use is Paredit, which prevents you typing anything that isn't a valid s-expression. This only works because s-expression syntax is so minimal, and most of Lisp's actual syntax is layered on top with macros. Even if you're using Paredit, your spit/slurp/kill operations will produce invalid intermediate code that would fail to compile.

westoncb 10y ago
That's an interesting point. I've heard other people bring up this issue in a vague way, but your example makes it clear why people would have a concern about this. At the same time, however, I'm not convinced it's a serious issue—it's more important to save work and avoid re-typing the shell of a switch when you have to type it one character at a time. If you're mapping language constructs to single keys (this was the way I went), you can crank out a new multi-block switch statement in a few keystrokes; then (in my editor anyway), you can just drag the code blocks from the if statements into the new structure. Even better, since the editor has easy access to info about language structure, it could include automatic transformations to transition between structurally similar language constructs. I think it seems unnatural at first because we're so used to typing characters out one at a time, and it seems like we're throwing that skill out the window when considering an alternate form of editor. I still don't really see an intrinsic limit though. I'd appreciate any other counter-example you may have (a lot of why I don't continue working on my own project at the moment is concern that these are lurking and I'll only discover them after lots more wasted effort—so if I could definitively rule out that this project is a good idea, that'd be great.)
- meredydd 10y ago
  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.

sakamies 10y ago

Your editor looks insanely slick! I had no idea there was prior work in this area. It sounds like your editor could trivially support html. That last paragraph is exactly what I was thinking with foolproof html, except applied to markup/data languages. Is your editor available to try somewhere?

westoncb 10y ago
Thanks! Unfortunately it's not available to try. I spent a lot of time building it in my free time and eventually got burnt out :/ It's still not to a point where it's usable (it's edit only). I'd love to revisit the project in some form, but time/money/other projects are obstacles at the moment. I still think the concept has merit, but the implementation is more difficult than it seems (including lower-level design decisions, e.g., like the discussion in the other comment here). Good luck to you if you do give it a try, though. If nothing else, you'll probably learn a lot ;) There's a little more info on the project here, btw, if you're curious: http://westoncb.com/projects/tiledtext http://westoncb.com/projects/tiledtext
- sakamies 10y ago
  My story is kind of similar, including the wrist pain part. I've been brewing this thing for a bit over ten years. I got burnt out for other work and the editor some years ago and had to take a long break. Last year I started about the tenth new prototype and finally got it on a path that I think could lead to something that actually works. This time I'm trying to give away the code, ideas and everything, so maybe someday someone would continue the work so I won't have to. I just want to see it get made somehow and use the damn thing.
  - westoncb 10y ago
    Hehe, I know the feeling.