3 ms·

My initial reaction, from an SEng POV, is that visualising code in this way is pointless: the text of the code is the graph of the code. And if you really reall

My initial reaction, from an SEng POV, is that visualising code in this way is pointless: the text of the code is the graph of the code. And if you really really value an identity here, use lisp. So visual coding, for SEng, I think just is pointless. The text isnt the hard part, the hard part the is mental model -- and visuals often impair the quick exploration (etc.) needed to build the mental model. Likewise, in the YT video introducing this, the creator distinguishes between "code" and your mental model of its execution, as if the latter can and should be ditched. This, of course, is a fallacy as far as SEng is concerned. The whole point is the mental model. Nevertheless, after watching for longer, the sales pitch here seems directed towards data science (, + DEng perhaps) where applications are often trivial amounts of code. Coupled with interactive visualisations, this is at least a more plausible use-case. There the creator's distinction between "how the machine runs your code" and "the problem you're trying to solve" makes more sense. Since practitioners arent building automation systems, apps, etc. they're using code instrumentally to arrive at an outcome. Also, cf. https://enso.org/docs/developer/enso/enso-philosophy.html https://enso.org/docs/developer/enso/enso-philosophy.html

kitd 4y ago
Graphical representations tend to be better than 2D text when dealing with concurrent streams of execution. You can do it in plain text, but either it is difficult to follow or it becomes a mess of text alignments. IME.
- mjburgess 4y ago
  Perhaps, but how much of that it just an imperative phrasing? I think the visual capabilities of horizontal and vertical spacing are, certainly, vastly under-used. We could easily divide regions of files into two 60chr lines, or many 20char lines, GetWater . Boil(Water) | | GetCoffee, GetMilk, GetCup . Grind(Coffee) | | Pour(Milk) . Brew(Coffee, Water) . Pour(Coffee) .
  - blondin 4y ago
    this sounds good for pure concurrent processes. but synchronization will be harder to represent using vertical bars.
  - kitd 4y ago
    But you quickly come up against problems of text alignment, trying to show 2+ theoretical streams of text on one 2D page, and it's a pig to get the DX right. A specialist editor would help, but then you could ask, why not just use a structured doc in eg JSON and represent it graphically. For background, I wrote a tool that would convert an ASCII art diagram in comments describing the state flow of a class into a set of method declarations in the class. Even using online diagramming tools, it's not easy.
- WillAdams 4y ago
  This is the route I've been going w/ my work on 3D --- I program in BlockSCAD and make modules for each component, or aspect of a component, and then the design can be visualized as the options/logic which arrive at a particular iteration.
worldsayshi 4y ago
>visuals often impair the quick exploration (etc.) needed to build the mental model. If that was true why do we use whiteboards do much?
awinter-py 4y ago
their image processing example on the github readme is compelling I sort of agree that they're conflating a few things: - resumable processes - text graph description format - using graph descriptions to lint or generate code - UX / visualization for graphs But I could be convinced that these are things that go better together

kitd 4y ago

Graphical representations tend to be better than 2D text when dealing with concurrent streams of execution. You can do it in plain text, but either it is difficult to follow or it becomes a mess of text alignments. IME.

mjburgess 4y ago
Perhaps, but how much of that it just an imperative phrasing? I think the visual capabilities of horizontal and vertical spacing are, certainly, vastly under-used. We could easily divide regions of files into two 60chr lines, or many 20char lines, GetWater . Boil(Water) | | GetCoffee, GetMilk, GetCup . Grind(Coffee) | | Pour(Milk) . Brew(Coffee, Water) . Pour(Coffee) .
- blondin 4y ago
  this sounds good for pure concurrent processes. but synchronization will be harder to represent using vertical bars.
- kitd 4y ago
  But you quickly come up against problems of text alignment, trying to show 2+ theoretical streams of text on one 2D page, and it's a pig to get the DX right. A specialist editor would help, but then you could ask, why not just use a structured doc in eg JSON and represent it graphically. For background, I wrote a tool that would convert an ASCII art diagram in comments describing the state flow of a class into a set of method declarations in the class. Even using online diagramming tools, it's not easy.
WillAdams 4y ago
This is the route I've been going w/ my work on 3D --- I program in BlockSCAD and make modules for each component, or aspect of a component, and then the design can be visualized as the options/logic which arrive at a particular iteration.

worldsayshi 4y ago

>visuals often impair the quick exploration (etc.) needed to build the mental model. If that was true why do we use whiteboards do much?

awinter-py 4y ago

their image processing example on the github readme is compelling I sort of agree that they're conflating a few things: - resumable processes - text graph description format - using graph descriptions to lint or generate code - UX / visualization for graphs But I could be convinced that these are things that go better together