19 ms·

I agree it's kind of odd that our dev process is essentially a sea of broken states with intermittent workingness (if you count by states, I mean). Version con

by pjz 4y ago

I agree it's kind of odd that our dev process is essentially a sea of broken states with intermittent workingness (if you count by states, I mean). Version control commits are an attempt to hilight/preserve those working states. Limiting deltas to working-only states would, I think, result in something akin to MIT's 'Scratch' language, where kids put together puzzle pieces - a program can only be wrong at a semantic level, never at a source code level. OTOH, refactoring power tools available in modern IDEs are a bit of a counter-argument in that they allow code transforms that don't usually make much of a semantic difference (eg. 'inline this', 'extract this as a variable', etc) But as you say, that's "written code" not "writing code". For writing code, I think the closest current IDE feature to tylr would maybe be syntax hilighting. It'd be cool to maybe have some kind of 'expression hilighting' mode, and maybe an 'expression editor' mode with actions like tylr supports.

kqr 4y ago
I mean, the closest I know to avoiding this is something like writing lisp with smartparen. This ensures the code is always syntactically valid, but it doesn't prevent you from partially typed function names like "filte". However, I think that's a good thing. The alternative to partially typing out functions would be selecting them from a list or automatically having the editor fill in the most likely match from before the first letter is typed. Both the latter would, if interrupted, convey less information than the partially typed out name. Phrased differently: writing code will always be a matter of narrowing down the full namespace to the appropriate function. Partially typing it provides the human about the most information on where things are going, even if it's not as friendly on compilers. So yeah, we could have compilers fill in the missing information to create a compiler-valid state from partial information, but what does that give us? A wildly incorrect program that's harder to fix? Programming is writing code for humans that computers occasionally read, not the other way around. With today's focus on tooling, I feel like we have forgotten this.

by pjz 4y ago

kqr 4y ago

I mean, the closest I know to avoiding this is something like writing lisp with smartparen. This ensures the code is always syntactically valid, but it doesn't prevent you from partially typed function names like "filte". However, I think that's a good thing. The alternative to partially typing out functions would be selecting them from a list or automatically having the editor fill in the most likely match from before the first letter is typed. Both the latter would, if interrupted, convey less information than the partially typed out name. Phrased differently: writing code will always be a matter of narrowing down the full namespace to the appropriate function. Partially typing it provides the human about the most information on where things are going, even if it's not as friendly on compilers. So yeah, we could have compilers fill in the missing information to create a compiler-valid state from partial information, but what does that give us? A wildly incorrect program that's harder to fix? Programming is writing code for humans that computers occasionally read, not the other way around. With today's focus on tooling, I feel like we have forgotten this.