6 ms·

On the surface it sounds interesting, but I don't really buy the idea that programming is terribly limited by the quality of text editors. Even "basic" editors

by bcg1 11y ago

On the surface it sounds interesting, but I don't really buy the idea that programming is terribly limited by the quality of text editors. Even "basic" editors like vim and emacs can almost instantly catch most syntax problems, and IDEs like Eclipse and Visual Studio are great about complaining if you make a mistake. In my experience, these days relatively few problems come from language syntax errors ... most problems come from mistakes in logic, poor systems integration, or incorrect validation of input data. Not sure how Unison will solve those challenges, but to be fair maybe that is out of scope. However it is hard to slog through the marketing, and in the end its just not clear from the writeup what sort of programs one would write in Unison, so it doesn't really inspire me to spend any more time trying to learn about it.

Dewie3 11y ago
The editor (or whatever it's called) promises to only allow only well-typed programs. Not just syntactically correct programs.
- marcosdumay 11y ago
  Eclipse, Visual Studio, and all the Haskell IDEs catch type errors on the fly and help you fix them.
  - Dewie3 11y ago
    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.
    - mnx 11y ago
      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.
      - Dewie3 11y ago
        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! :)
      - alphapapa 11y ago
        If this video < http://pchiusano.github.io/2015-03-17/unison-update5.html 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.
      - pshc 11y ago
        Agreed; editor "slop" is important for UX. A structure editor needs to model a text editor, with all its indeterminacy, to be usable.
  - kyllo 11y ago
    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.
    - wtetzner 11y ago
      > 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.
      - tome 11y ago
        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.
        wtetzner 11y ago
        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.
        Dewie3 11y ago
        > 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.
desireco42 11y ago
It is very limited, I am a vim guy, it has nothing to do with vim. Simply we are reinventing the wheel every time and that is the biggest issue.
deleted 11y ago
[deleted]
Ericson2314 11y ago
One of the mantras of functional programming is get your data structure right, and everything else falls into place. As an experienced functional programmer, I see this in practice every time I program--even a slightly "wrong" type pollutes the code dramatically. The idea then with structure/tree/semantic editors is two-fold. First, text is obviously the wrong the wrong data structure for programs, so even if people manage to provide fairly good support with the "modern IDE", the effort it takes is staggering. And still details like files, character encodings, god damn tabs vs. spaces, and terminals leak through. One can't help but wonder how much farther they would get were their efforts directed more efficiently. Look at this https://github.com/yinwang0/ydiff https://github.com/yinwang0/ydiff for example, blows text diff out of the water. Second the idea is maybe text is the "wrong data structure" for programmers too, not just tool-smiths. I admit there are bunch more psychological/neurological aspects that make the answer less obvious. But I see no reason why not to keep an open mind until a polished tree editor exists for empirical testing. Even if text is in someways better, the improved functionality a tree editor offers could offset that dramatically.
- seanmcdirmid 11y ago
  Functional programming kind of screws itself when it comes to "implementing" modern good IDEs; the aversion to state makes it difficult to implement good tree-incremental error resistant parsing and type checking that is usable in a language aware editor. I've developed plenty of advanced IDE infrastructure; e.g. see http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti... and http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx http://research.microsoft.com/en-us/projects/liveprogramming... The trick was abondoning FRP-style declarative state abstractions (which was my previous research topic) and moving onto something that could manage state in more flexible ways (as we say, by managing times and side effects instead of avoiding them). And once you nailed the state problem, incremental parsing, type checking, and rich editing are actually easy problems.
  - tome 11y ago
    Can you give some more detail about what you replaced FRP with? Sounds interesting.

by bcg1 11y ago

Dewie3 11y ago

The editor (or whatever it's called) promises to only allow only well-typed programs. Not just syntactically correct programs.

marcosdumay 11y ago
Eclipse, Visual Studio, and all the Haskell IDEs catch type errors on the fly and help you fix them.
- Dewie3 11y ago
  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.
  - mnx 11y ago
    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.
    - Dewie3 11y ago
      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! :)
    - alphapapa 11y ago
      If this video < http://pchiusano.github.io/2015-03-17/unison-update5.html 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.
    - pshc 11y ago
      Agreed; editor "slop" is important for UX. A structure editor needs to model a text editor, with all its indeterminacy, to be usable.
- kyllo 11y ago
  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.
  - wtetzner 11y ago
    > 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.
    - tome 11y ago
      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.
      - wtetzner 11y ago
        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.
        Dewie3 11y ago
        > 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.

desireco42 11y ago

It is very limited, I am a vim guy, it has nothing to do with vim. Simply we are reinventing the wheel every time and that is the biggest issue.

deleted 11y ago

[deleted]

Ericson2314 11y ago

One of the mantras of functional programming is get your data structure right, and everything else falls into place. As an experienced functional programmer, I see this in practice every time I program--even a slightly "wrong" type pollutes the code dramatically. The idea then with structure/tree/semantic editors is two-fold. First, text is obviously the wrong the wrong data structure for programs, so even if people manage to provide fairly good support with the "modern IDE", the effort it takes is staggering. And still details like files, character encodings, god damn tabs vs. spaces, and terminals leak through. One can't help but wonder how much farther they would get were their efforts directed more efficiently. Look at this https://github.com/yinwang0/ydiff https://github.com/yinwang0/ydiff for example, blows text diff out of the water. Second the idea is maybe text is the "wrong data structure" for programmers too, not just tool-smiths. I admit there are bunch more psychological/neurological aspects that make the answer less obvious. But I see no reason why not to keep an open mind until a polished tree editor exists for empirical testing. Even if text is in someways better, the improved functionality a tree editor offers could offset that dramatically.

seanmcdirmid 11y ago
Functional programming kind of screws itself when it comes to "implementing" modern good IDEs; the aversion to state makes it difficult to implement good tree-incremental error resistant parsing and type checking that is usable in a language aware editor. I've developed plenty of advanced IDE infrastructure; e.g. see http://research.microsoft.com/en-us/people/smcdirm/managedtime.aspx http://research.microsoft.com/en-us/people/smcdirm/managedti... and http://research.microsoft.com/en-us/projects/liveprogramming/typography.aspx http://research.microsoft.com/en-us/projects/liveprogramming... The trick was abondoning FRP-style declarative state abstractions (which was my previous research topic) and moving onto something that could manage state in more flexible ways (as we say, by managing times and side effects instead of avoiding them). And once you nailed the state problem, incremental parsing, type checking, and rich editing are actually easy problems.
- tome 11y ago
  Can you give some more detail about what you replaced FRP with? Sounds interesting.