> That's one thing Unison is trying to fix.
Is that actually a problem? If you're never allowed to input incomplete/broken code, then the way you program is very limited. Often I like to start writing a function, get to the point where I realize I need another function, write that one, and come back to the first function.
In an editor where only working code can be input, you can't do this style of programming, which almost rules out exploratory programming. You have to more or less know what you're doing from the start.
This sounds implausible. How can you run your intermediate program if it's missing a function? I don't see that accepting only well-typed programs changes anything, and furthermore it applies to all typed languages not just ones that enforce well-typedness by construction.
You can't run it. The point is that if I'm trying to figure out how to implement something, I can start writing down my ideas and adjust as I go. If I have to write valid code the whole time, my ability to do this is very limited.
If you already know what code you want to write, this makes sense. But how often does that happen? I suppose you could work out your ideas on paper first, but that eliminates the much of the value modern editors provide.
> If you already know what code you want to write, this makes sense. But how often does that happen? I suppose you could work out your ideas on paper first, but that eliminates the much of the value modern editors provide.
What would be ironic is if this semantic editing would force us to sketch our functions/modules/program with pen and paper before we are able to actually input them into this semantic editor. An editor that tries to go beyond the "archaic" textual interface, and ends up forcing you to use the even more "archaic" pen and paper.
In an editor where only working code can be input, you can't do this style of programming, which almost rules out exploratory programming. You have to more or less know what you're doing from the start.