4 ms·

> This post is about why terminal-based input seems stuck in the 80s It's actually more 60s/70s, when the first terminals, command-line prompts, and shells wer

> This post is about why terminal-based input seems stuck in the 80s It's actually more 60s/70s, when the first terminals, command-line prompts, and shells were built. The reason why it's stuck there is technology has only improved iteratively rather than revolutionarily. The "lets add another layer of abstraction" form of innovation, rather than outside-the-box thinking and reinvention. The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. It's not that far removed from punch cards.

maximus-decimus 4y ago
What would you prefer it to be? Audio recording of spoken words? Diagrams like Labview?
- 0xbadcafebee 4y ago
  Ideally? That holographic interface Tony Stark uses. I would settle for a combination of SolidWorks and Visual Basic. SoldWorks to model and visualize the whole thing, pick it apart, run it. Visual Basic to assemble DCOM objects, add simple logic, design an interface. Export/import SolidWorks models and connect them to new models to re-use a whole "machine". Keep a corporate library of "machines", import one to do what you need, fork it and make a new one if it doesn't do what you want.
  - maximus-decimus 4y ago
    So a holographic LabView.
- solarkraft 4y ago
  Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text. The editor I'm imagining looks and works a lot like your typical code view, but has a better understanding of the semantics and makes things there are keyboard shortcuts for more visible. From the top of my head: First-class code folding and commenting and actions primarily on blocks rather than lines. e.g. if you disable ("comment out") an if-statement, either disable the whole block or the wrapping of the inside code with the condition. It's very rare that you want to do something in between and in textually based languages this action is much harder than it needs to be without producing a syntax error. An important part of GUI design is to avoid the possibility for invalid states, but text-based code editing in its current form produces a lot of them, totally unnecessarily and annoyingly so, in my opinion. I'm sure that tools with features like this already exist, but they're certainly not popular.
  - nuancebydefault 4y ago
    There is a big problem with graphical programming: it is very hard to diff graphs in a graphical way. How can you even give review comments on changes? How would an automatic merge work? Also, the benefit of graphic representation of an algorithm is that it gives an overview that is easier to understand. But the whole graph with the real details, is just harder to understand. But the details are necessary, they make simplistic software smarter and better.
    - solarkraft 4y ago
      You're right: The tooling ecosystem for text-based programming is already very mature, which is why I wouldn't want to replace it. Current programming languages are stored as text anyway (trying to replace an entire established ecosystem without any steps in between doesn't really work, see Microsoft's constant failures attempting to bundle new things). That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.
    - derefr 4y ago
      You can do all that at the text level, if it makes the tooling easier; the tooling would just be operating on a canonically-chosen textual projective representation of graphical code (think: `go fmt`, but as a FUSE mount!), rather than against canonically textual code. Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents. As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even. But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.
      - shakow 4y ago
        Honestly, I'm under the impression that you have basically just reinvented Lisp ;) Or any homoiconic language.
solarkraft 4y ago
> The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. Agreed. This makes some changes that could be simple unnecessarily hard. Formatting shouldn't even be a thing. FWIW though, having an auto-formatter on save has solved a big chunk of that pain for me.
- bombolo 4y ago
  I hate autoformatters with a passion. They love to generate 3000 lines diff for a 3 lines change, and then I have to review that. Also git blame becomes kinda pointless.
astrobe_ 4y ago
> The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. It's not that far removed from punch cards. Well, it wasn't hard to beat punch cards in terms of convenience (BTW did you use them once?), but apparently it's very difficult to beat text editors because they've survived for 50+ years despite the fact the mouse was available in the 80s and that people have been saying that sort of thing once in a while for at least 3 decades.

maximus-decimus 4y ago

What would you prefer it to be? Audio recording of spoken words? Diagrams like Labview?

0xbadcafebee 4y ago
Ideally? That holographic interface Tony Stark uses. I would settle for a combination of SolidWorks and Visual Basic. SoldWorks to model and visualize the whole thing, pick it apart, run it. Visual Basic to assemble DCOM objects, add simple logic, design an interface. Export/import SolidWorks models and connect them to new models to re-use a whole "machine". Keep a corporate library of "machines", import one to do what you need, fork it and make a new one if it doesn't do what you want.
- maximus-decimus 4y ago
  So a holographic LabView.
solarkraft 4y ago
Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text. The editor I'm imagining looks and works a lot like your typical code view, but has a better understanding of the semantics and makes things there are keyboard shortcuts for more visible. From the top of my head: First-class code folding and commenting and actions primarily on blocks rather than lines. e.g. if you disable ("comment out") an if-statement, either disable the whole block or the wrapping of the inside code with the condition. It's very rare that you want to do something in between and in textually based languages this action is much harder than it needs to be without producing a syntax error. An important part of GUI design is to avoid the possibility for invalid states, but text-based code editing in its current form produces a lot of them, totally unnecessarily and annoyingly so, in my opinion. I'm sure that tools with features like this already exist, but they're certainly not popular.
- nuancebydefault 4y ago
  There is a big problem with graphical programming: it is very hard to diff graphs in a graphical way. How can you even give review comments on changes? How would an automatic merge work? Also, the benefit of graphic representation of an algorithm is that it gives an overview that is easier to understand. But the whole graph with the real details, is just harder to understand. But the details are necessary, they make simplistic software smarter and better.
  - solarkraft 4y ago
    You're right: The tooling ecosystem for text-based programming is already very mature, which is why I wouldn't want to replace it. Current programming languages are stored as text anyway (trying to replace an entire established ecosystem without any steps in between doesn't really work, see Microsoft's constant failures attempting to bundle new things). That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.
  - derefr 4y ago
    You can do all that at the text level, if it makes the tooling easier; the tooling would just be operating on a canonically-chosen textual projective representation of graphical code (think: `go fmt`, but as a FUSE mount!), rather than against canonically textual code. Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents. As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even. But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.
    - shakow 4y ago
      Honestly, I'm under the impression that you have basically just reinvented Lisp ;) Or any homoiconic language.

solarkraft 4y ago

> The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. Agreed. This makes some changes that could be simple unnecessarily hard. Formatting shouldn't even be a thing. FWIW though, having an auto-formatter on save has solved a big chunk of that pain for me.

bombolo 4y ago
I hate autoformatters with a passion. They love to generate 3000 lines diff for a 3 lines change, and then I have to review that. Also git blame becomes kinda pointless.

astrobe_ 4y ago

> The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. It's not that far removed from punch cards. Well, it wasn't hard to beat punch cards in terms of convenience (BTW did you use them once?), but apparently it's very difficult to beat text editors because they've survived for 50+ years despite the fact the mouse was available in the 80s and that people have been saying that sort of thing once in a while for at least 3 decades.