Yes, but you have to finish typing the syntax first, and the IDE that is constantly parsing your code file is always going to report errors as the code goes through a broken state while you're typing. That's one thing Unison is trying to fix.
> 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.
The difference is that this editor will supposedly not even allow the code to be in a state of type errors. You literally can not construct a program that is not well-typed. Don't ask me how that editing experience is supposed to work, or if it's a good idea.
Actually, that sounds terrible. I already am sometimes annoyed when I try to first use a variable, and then go back and decide where should I declare it - visual studio doesn't like that - literally not being able to go through a broken state would be annoying.
If this video < http://pchiusano.github.io/2015-03-17/unison-update5.html > is an example of this, then yes, it does look annoying and inefficient. Now I'm not sure if I understand exactly what he's doing here, but it looks like something along those lines: rather than inputting what he wants directly via the keyboard, he has to choose a pattern (like variable-operator-variable) from a drop-down list, and then tab between the fields to fill in the pattern.
A poor analogy might be the difference between speaking words verbally to form a sentence vs. shuffling through a stack of index cards to find the right words to arrange on a table to form a sentence. The latter would be useful if you were just learning a language, but once you know how to speak it, that would be an enormous waste of time.
I'm annoyed just by simple error-messages (like in Eclipse) while I'm editing in a "broke" state. I know that this class isn't valid Java yet, Eclipse; shut up! :)
