5 ms·

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.
- derefr 4y ago
  In other words, text should be a projective UX for modifying an underlying graphical model; not a canonical storage format for code.
  - solarkraft 4y ago
    I'd go exactly the other way around since every programming tool under the sun already knows how to deal with text. Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.
    - derefr 4y ago
      The problem is that there's always a valid textual projection for any graph, but there isn't always a valid graphical projection for any text. Think like: your syntax highlighter has no idea what your code when you're in the middle of typing, because once you type an opening parenthesis without yet having typed a closing one, your code no longer has any possible valid parse. Ideally, you shouldn't be able to modify the text in ways that don't represent an atomic graphical operation in the first place. But if you enforce that, you can't really say that the textual representation is the canonical one. It's just a storage projection.
- __MatrixMan__ 4y ago
  Sounds like emacs paredit mode. I tried to learn it, but in the end I waved the white flag and went back to vimming through invalid states to achieve the next valid one.

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.
derefr 4y ago
In other words, text should be a projective UX for modifying an underlying graphical model; not a canonical storage format for code.
- solarkraft 4y ago
  I'd go exactly the other way around since every programming tool under the sun already knows how to deal with text. Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.
  - derefr 4y ago
    The problem is that there's always a valid textual projection for any graph, but there isn't always a valid graphical projection for any text. Think like: your syntax highlighter has no idea what your code when you're in the middle of typing, because once you type an opening parenthesis without yet having typed a closing one, your code no longer has any possible valid parse. Ideally, you shouldn't be able to modify the text in ways that don't represent an atomic graphical operation in the first place. But if you enforce that, you can't really say that the textual representation is the canonical one. It's just a storage projection.
__MatrixMan__ 4y ago
Sounds like emacs paredit mode. I tried to learn it, but in the end I waved the white flag and went back to vimming through invalid states to achieve the next valid one.