4 ms·

They can also be quite messy and hard/annoying to follow/parse since a lot of screen real estate is used for trivial things. For example the first graph wastes

They can also be quite messy and hard/annoying to follow/parse since a lot of screen real estate is used for trivial things. For example the first graph wastes 300x250 pixels several times for what would be a single character in a text-based language (and that's if you ignore the padding between the nodes since you could claim that whitespace in a text-based language serves the same purpose). And unlike a text-based language where there is (usually) a single flow path going towards a single direction, with graphics like the one in the article you have several "flows" so your eyes need to move all over the place all the time to connect the "bits" in order to figure out what is going on. Though that last part could probably be solved by using DRAKON graphs instead (which can also use less screen space) since those have a more strict flow. IMO graph-based visual languages are nice for very high level flows but the moment you need to use more than a couple "dot product" or "add values" nodes, it is time to switch to a text-based one.

pavlov 2y ago
I agree that large node graphs get unwieldy and nobody has come up with a great solution for that. Macros and independently scalable groups and visual annotations can help, but it depends on the type of program. I disagree about the single-direction “1D” nature of textual programs being unequivocally a benefit. When there are many independent paths that eventually combine, it’s easier to see the complete flow in a 2D graph. Linear text creates the illusion of dependency and order, even if your computation doesn’t actually have those properties. Conserving screen space is a double-edged sword. If that were the most important thing in programming, we’d all be writing APL-style dense one-liners for production. But code legibility and reusability is a lot more than just who does the most with the least symbols.
- badsectoracula 2y ago
  > I disagree about the single-direction “1D” nature of textual programs being unequivocally a benefit. When there are many independent paths that eventually combine, it’s easier to see the complete flow in a 2D graph. This is where having separate functions help - as a bonus you can focus on that independent path without the rest being a distraction. If there are multiple independent paths that connect at separate points where you can't isolate them easily if they were a function, the graph is already a mess. > Conserving screen space is a double-edged sword. If that were the most important thing in programming, we’d all be writing APL-style dense one-liners for production. That is a bit of an extreme case, it isn't about conserving all the screen real estate, just not being overly wasteful. After all the most common argument you'd see about -say- Pascal-style syntax is that it is too verbose compared to C-like syntax, despite the difference not being that great. You'll notice that despite APL-like syntax not being very popular, COBOL-like syntax isn't popular either. You don't have to go to extremes - notice that in my comment i never wrote that all uses of graphs should be avoided.
nkrisc 2y ago
I would wager that Blender's geometry nodes are over all a net saving in screen real estate when compared to the amount of code they abstract away. Sure, in a trivial example they seem unnecessarily large, but there are some nodes that do a lot of heavy lifting, and are no bigger than any other node. Overall a strange metric to track, IMO, unless all your variable names are one letter.
- badsectoracula 2y ago
  Which is why i wrote that last paragraph: for high level stuff with nodes that abstract the heavy lifting they are fine. Sometimes you may even need these "add" and "dot product" nodes to glue these together. The issue is when you start using a lot of "low level" nodes. Think of it like using a shell script vs something like Python: you can do a ton of things in shell scripts and write very complex shell scripts, but chances are if a shell script is more than a few lines that glue other programs together, it'd be better to use Python (or something similar) despite both being "scripting" languages.

pavlov 2y ago

I agree that large node graphs get unwieldy and nobody has come up with a great solution for that. Macros and independently scalable groups and visual annotations can help, but it depends on the type of program. I disagree about the single-direction “1D” nature of textual programs being unequivocally a benefit. When there are many independent paths that eventually combine, it’s easier to see the complete flow in a 2D graph. Linear text creates the illusion of dependency and order, even if your computation doesn’t actually have those properties. Conserving screen space is a double-edged sword. If that were the most important thing in programming, we’d all be writing APL-style dense one-liners for production. But code legibility and reusability is a lot more than just who does the most with the least symbols.

badsectoracula 2y ago
> I disagree about the single-direction “1D” nature of textual programs being unequivocally a benefit. When there are many independent paths that eventually combine, it’s easier to see the complete flow in a 2D graph. This is where having separate functions help - as a bonus you can focus on that independent path without the rest being a distraction. If there are multiple independent paths that connect at separate points where you can't isolate them easily if they were a function, the graph is already a mess. > Conserving screen space is a double-edged sword. If that were the most important thing in programming, we’d all be writing APL-style dense one-liners for production. That is a bit of an extreme case, it isn't about conserving all the screen real estate, just not being overly wasteful. After all the most common argument you'd see about -say- Pascal-style syntax is that it is too verbose compared to C-like syntax, despite the difference not being that great. You'll notice that despite APL-like syntax not being very popular, COBOL-like syntax isn't popular either. You don't have to go to extremes - notice that in my comment i never wrote that all uses of graphs should be avoided.

nkrisc 2y ago

I would wager that Blender's geometry nodes are over all a net saving in screen real estate when compared to the amount of code they abstract away. Sure, in a trivial example they seem unnecessarily large, but there are some nodes that do a lot of heavy lifting, and are no bigger than any other node. Overall a strange metric to track, IMO, unless all your variable names are one letter.

badsectoracula 2y ago
Which is why i wrote that last paragraph: for high level stuff with nodes that abstract the heavy lifting they are fine. Sometimes you may even need these "add" and "dot product" nodes to glue these together. The issue is when you start using a lot of "low level" nodes. Think of it like using a shell script vs something like Python: you can do a ton of things in shell scripts and write very complex shell scripts, but chances are if a shell script is more than a few lines that glue other programs together, it'd be better to use Python (or something similar) despite both being "scripting" languages.