5 ms·

every form of visual programming I've ever seen is a singular style of some of a box that does processing and a line that connects that box to another box.

wild_egg 2y ago
Anyone know of an example of any other style? Would love to see any half-baked experiments even. Seems like a space that could really use some innovation
- __MatrixMan__ 2y ago
  I don't have any code for this, but I always thought it would be better if the boxes represented data types and the arrows represented functions. Then you could use the arrow as a progress bar, and you'd have something that's a bit more focused on the inputs and outputs. Also, the data types could show up as a stack of boxes (like a deck of cards) so you can see when you've calculated a novel dataset (highlight new card on top the deck) or when you've recalculated a previous dataset (highlight the nth card). Such a view would resemble a commutative diagram (from category theory) and if you let the cards pile up for a while you could use their sizes to reason about which functions are bijective, which are good candidates for memorization, etc. When you want to know why a certain datum is the way it is, you can use the same view to trace it back to it's inputs (in the boxes-as-tasks mode, you end up zooming in on some imperative artifact... logs usually... And discerning the inputs is left as an exercise to the reader). I think this goes by the buzzword "data lineage" and it's usually this extra thing but I think it should be the main thing. Which is why I want to make the nodes into edges and the edges into nodes.
  - deleted 2y ago
    [deleted]
  - andyferris 2y ago
    This is interesting. How do you visually identify a function with multiple inputs and outputs? I tend to imagine it as a bi-graph - with boxes for values and for functions, and arrows in between. The stack idea is interesting and can work here too. I could get behind saying "all functions have exactly one input value and one output value" but you really need to be able to construct and deconstruct structs/records/tuples to be able to e.g. pass two values to one function.
    - __MatrixMan__ 2y ago
      Ah, yeah, you caught me. It's not so simple as a transform from nodes to edges. What I actually have in mind is a bit stranger, but the node/edge swap was my stepping stone towards it, which is why I mentioned it. The structs/records/tuples approach would work (I think this would correspond with "currying"), but I have this weird idea that certain types of reasoning have a "shape" and that we might be able to more heavily lean on analagous reasoning if we could easily show that shape in correspondence with explanations of our reasoning. I worry that currying everything would force us further away from the "natural" shape (if there even is such a thing). I've been working on something called plibs (simPlical mad LIBS, since really we're showing a https://en.m.wikipedia.org/wiki/Simplicial_complex https://en.m.wikipedia.org/wiki/Simplicial_complex here). The functions are represented as tuples of the same arity, and described via sentences with blanks in them (e.g. when you run ____ code in ____ environment you get ____ from stdout). One with three blanks would then appear like a triangle and then I'd fill it in with a gradient indicating which sides are inputs and which are outputs. Functions sharing a mad lib would appear as a regular polygon in the same color (one edge for each blank). Or maybe they're sort of starfish shaped so that each leg can reach out an touch whatever the data representation ends up being. One could imagine algorithms that generate patchwork quilts or 3D structures (like how protein folding is represented) out of such things. These could be computed only in one direction (from inputs towards outputs) but they could be traversed in any direction if one wanted to explore the relationships. I'm hoping it will be a nice way of citing your computational sources. You would attach them to any computational result (alongside a scientific paper, perhaps) as a way if saying "here's how I came up with this, rerun it to verify my result". Aside from the computational pathway that yielded the result that's being scrutinized, you could explore adjacent plibs to understand why certain inputs were chosen or to gain other contextual hints. Now that I'm describing it it sounds a bit like that awful zooming-through-towers-of-data visualization in "Hackers" the movie. So the "edge" that I was using as a progress bar in my previous description is really a series of paths through a space made of these things. The details of the functions being called (and of the datasets being generated) are attached to the polygonal regions that the paths connect. The paths may merge or branch. It could get unwieldy, so the user would have to be explicit about which plibs to show and which to highlight as a chain of computation. As for how the represent the intermediate data and their types, I keep changing my mind. Some days I like the stacks of cards thing, some days not. Hopefully something will sick soon, then I'll try to build it.
- viraptor 2y ago
  Depends how literally you mean programming and processing. For example UML is a programming diagram. If you don't have the definitions anywhere else and always merge the diagram with specific methods implementation when compiling, is that an good example? What about ERD? If you materialise that into schema, is that programming? I think you'll run only into those two categories - boxes represent literal code you join together, or boxes represent something declarative that gets compiled into code but not necessarily in a straightforward way. I guess visual reporting like in MS Access could be thought of as a separate category? Depending on whether prose is programming, there's also https://visar.app/ https://visar.app/ And then there's CUBE https://marc.najork.org/papers/vl1992.pdf https://marc.najork.org/papers/vl1992.pdf
  - Ringz 2y ago
    Thank you for the very interesting links. I used UML extensively during my studies in the nineties, back then on Unix machines. Interestingly, even then, it was possible to work together on a UML concept. I'm not sure anymore if the novelty of working with a graphical UML program was the motivation, or the opportunity to program in something other than Modula. In the end, after my studies, I still had to program only in C++. Once accustomed to the relative directness, it is difficult to embrace new innovative concepts. But I would welcome it.
- jdougan 2y ago
  Scratch is arguably a style of visual programming
  - viraptor 2y ago
    Scratch is boxes and arrows with arrows of zero length ; )
    - jdougan 2y ago
      I know that's a joke, but in that case every screen is a grid of (v. small) boxes with arrows of zero length.
    - philsnow 2y ago
      Blockly (the visual editor used by Scratch) elegantly shows hierarchy of control flow. I've never seen a boxes-and-lines visual editor where loops are as easily understood as Blockly pieces.
- NaOH 2y ago
  Keyboard Maestro foregoes the lines between boxes, but it still presents the same general format. https://www.keyboardmaestro.com/img/v11/overview-dark@2x.png https://www.keyboardmaestro.com/img/v11/overview-dark@2x.png
- ninetyninenine 2y ago
  Text itself is a form of visual programming. We really have only two styles of visual programming: 1. Some sort language formed by left to right based alphabetic symbols in some pattern called "grammar". There's an almost infinite amount of possible grammars 2. Boxes and lines. Where boxes represent state or function and lines connect the boxes and state together. There's less formalization in this area so the axioms are vague but it can form something of a "grammar" similar to the above. That's it. It's not a space that could really use innovation. It's the fact that the entire space has never innovated. We've just been drilling down on a very specific and biased way of seeing the universe. The concept of a compiler literally illustrates how deep it goes and how tied the idea of a program is to a "language".
  - DonHopkins 2y ago
    I disagree that "It's not a space that could really use innovation." There's quite a lot of innovation and experimentation in the visual programming space, and many vastly different approaches to visual programming. You forgot about block based visual programming languages like Scratch, Snap!, and Nassi-Shneiderman diagrams, and also the most ubiquitous, widely used, universally known, commonly taught, extremely powerful, and easily accessible style of visual programming language, which the worldwide economy depends on and would collapse if millions of people didn't regularly use them every day: spreadsheets.
- okennedy 2y ago
  Spreadsheets.
  - smegger001 2y ago
    Spreadsheets are to visual box and line programming what goto spaghetti-code is to traditional programming languages.
- jes5199 2y ago
  I’ve seen a demo - cannot immediately remember where - where instead of data flowing through lines, it actually had a physics engine where the data was shot out of the boxes in various directions, and did computation with whatever box it intersected with next
- CannisterFlux 2y ago
  The only other thing I can think of is GB Studio - https://www.gbstudio.dev/ https://www.gbstudio.dev/ - but the visual scripting there is like regular coding, but with visual blocks. It doesn't use boxes and lines. Instead, the script elements are more like blocks within blocks.
deleted 2y ago
[deleted]
x-complexity 2y ago
> every form of visual programming I've ever seen is a singular style of some of a box that does processing and a line that connects that box to another box. Mainly because it's the most straightforward method to: 1) Visualize a contained piece of code / function (box) 2) Show where the output of X goes to (line) There may be other styles, but this style is the easiest for a newbie to wrap their head around, and is the cleanest method of visualization. The box method can then be used to further wrap a bunch of boxes into a larger box when needed.
- chefandy 2y ago
  There are other advantages to this method: easily showing which wires are active while debugging, giving new programmers an intuitive sense of what's happening in control structures like for loops, using color, symbols and line weights to intuitively convey things about data/object types, giving users a complete list of potential methods and parameters without having to look for it, being able to use more complex code shapes to navigate complex classes, people can learn the basics of coding logic without needing to memorize syntax simultaneously... There are obviously tons of shortcomings to visual code, but I do think a lot of the guff they get is unwarranted.
  - hermitcrab 2y ago
    The subject of textual vs graphical programming comes up so often that I attempted to write a summary of the pros and cons of each. https://successfulsoftware.net/2024/01/16/visual-vs-text-based-programming-which-is-better/ https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
    - chefandy 2y ago
      Nice!
pacificmint 2y ago
I realized at some point that when people at work draw on whiteboards it usually ends up as boxes and lines between boxes. But after thinking about it, it feels natural, because usually we talk about "Things" and the "Connections" between them. Could be a companies org chart, a family tree, a network diagram, abstract things like processes. It's all "Things" and "Connections". Maybe that's why graph theory has so many applications. Because at the end, it's all just graphs with vertices and edges.
- ninetyninenine 2y ago
  Well programming itself with text doesn't have boxes and lines. So there's other isomorphisms to represent this concept.
  - yunohn 2y ago
    Programming, especially imperative, is essentially boxes (statements, function calls) and lines (control flow). That’s why algorithms can be represented as flowcharts.
    - ninetyninenine 2y ago
      Right. I call it an isomorphism. You can translate one into the other and back. Whatever "other" form of programming exists it can and should be translatable to boxes and diagrams. But this "other" form on first glance can look very different. There are no boxes and lines in C++ or python for example.
      - yunohn 2y ago
        I think you misread my post. Why would C++/Python not fit my description? Which languages do you consider?
        ninetyninenine 2y ago
        No. I did not misread. I believe you misunderstood. You’re saying c++ and python fit into a category of programs that is foundation-ally really just boxes and lines. I’m saying that’s not the right way to look at it. Because you can make the opposing statement. You can say that programs that are boxes and lines are foundation-ally just text programs. So because both contradictory statements can be made both aren’t really correct. There is no hierarchy. Boxes and lines is one concept and textual programming is another peer concept standing on equal footing. Both are isomorphic and thus translatable to each other. The point of my post is to suggest that there are other concepts that occupy this equivalency space. Imagine a category of interchangeable interpretations of programming that are all translate-able between each other with no hierarchy. It’s similar to the space of human languages. All human languages don’t occupy a hierarchy yet all are isomorphic.
high_5 2y ago
Because programming is essentially about receiving the input data, transforming it through a process and in the end outputting it in some other form?
- ninetyninenine 2y ago
  But then how come we can represent this concept in a form without boxes and lines? See python, C++, javascript, etc.
  - theshrike79 2y ago
    The functions and objects are the boxes, them calling each other are the lines =)
  - scott_w 2y ago
    Because the boxes and lines are just an abstraction.
    - ninetyninenine 2y ago
      No the text is the abstraction. Or perhaps neither is the abstraction and they are just equivalent concepts like how uno is the same thing as one. Uno is spanish, one is English… there is no hierarchy where one concept is an abstraction over the other. The main point of my post is to suggest that there are other equivalent concepts between text and box/line.
      - taeric 2y ago
        I think we are operating on different definitions of abstractions/concepts, here. My guess is you are trying to invoke a very specific meaning of "abstraction" in another context. To note, most text is a symbolic representation of spoken words and words are abstractions of any number of things. Both physical things such as "running" and less physical things such as "thinking." (Yes, legographic texts exist, such that they may not be representing spoken words, but I fail to see how that changes things here?)
onion2k 2y ago
In the Scratch language blocks connect to each other like jigsaw pieces for internal function logic.
- TeMPOraL 2y ago
  Scratch is Lisp, you're literally assembling the AST :).
  - DonHopkins 2y ago
    Scratch is much simpler and less powerful than Lisp, missing many of Lisp's most important features, like first class functions, complex data structures, and other first class objects. You can't even pass lists around as parameters, or include lists in other lists, and it's missing homoiconicity (representing code as data), reflection, macros, special forms, or even user defined blocks and control structures, etc. But Snap! goes way beyond Scratch, since it was inspired by and visually similar to Scratch, but is just as powerful as Scheme, including functions and everything else as first class objects, lexical closures, continuations, user defined blocks, macros, special forms, etc. It's much more powerful than Scratch, but uses the same visual interlocking block syntax. https://snap.berkeley.edu https://snap.berkeley.edu
    - EclipseMantis 2y ago
      Scratch does support user-created blocks.
DonHopkins 2y ago
Block based visual programming languages don't use lines connecting boxes to each other, which has been widely used for a long time with popular visual programming languages like Snap!, Scratch, Squeak eToys, Blockly, etc. Snap!: https://snap.berkeley.edu https://snap.berkeley.edu Scratch: https://scratch.mit.edu/ https://scratch.mit.edu/ Squeak eToys: http://www.squeakland.org/ http://www.squeakland.org/ Blockly: https://developers.google.com/blockly https://developers.google.com/blockly Also, spreadsheets are an extremely popular form of visual programming that has been around for a long time, which don't use lines to connect boxes either. VisiCalc: https://en.wikipedia.org/wiki/VisiCalc https://en.wikipedia.org/wiki/VisiCalc Lotus 1-2-3: https://en.wikipedia.org/wiki/Lotus_1-2-3 https://en.wikipedia.org/wiki/Lotus_1-2-3 Microsoft Excel: https://en.wikipedia.org/wiki/Microsoft_Excel https://en.wikipedia.org/wiki/Microsoft_Excel Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages: https://news.ycombinator.com/item?id=26061576 https://news.ycombinator.com/item?id=26061576
micheljansen 2y ago
Apple's Shortcuts seems heavily inspired by the visual programming language that Scratch uses: https://support.apple.com/guide/shortcuts-mac/intro-to-how-shortcuts-work-apdad3cbabfc/7.0/mac/14.0 https://support.apple.com/guide/shortcuts-mac/intro-to-how-s...
- Tijdreiziger 2y ago
  More like Automator: https://support.apple.com/guide/automator/welcome/mac https://support.apple.com/guide/automator/welcome/mac (although [per Wikipedia] the first Scratch prototype does seem to predate Automator by 1.5 years, so I suppose it’s possible there’s a connection)
  - micheljansen 2y ago
    Shortcuts is indeed the (more than spiritual) successor to Automator. Scratch was pretty famous in interface design circles in the early 2000s (it was a pretty high profile MIT Media Lab project). I'm sure the Automator developers were aware of it, but it may also have been a case of both having a rich neighbour [1]. Agentsheets, for example, predates both by over 10 years [2] [1] https://folklore.org/A_Rich_Neighbor_Named_Xerox.html https://folklore.org/A_Rich_Neighbor_Named_Xerox.html [2] https://en.wikipedia.org/wiki/AgentSheets https://en.wikipedia.org/wiki/AgentSheets
smusamashah 2y ago
Turns out there is another form of visual programming called Spatial Programming https://www.youtube.com/watch?v=eQgxFuw8f1U https://www.youtube.com/watch?v=eQgxFuw8f1U
HumblyTossed 2y ago
There is already a diagram that would capture it so much better - flowcharts.
hermitcrab 2y ago
It is also what techies naturally draw on whiteboards. It is a very concise, expressive and flexible way to model things.
whartung 2y ago
Galactic Modeling Language: https://wiki.c2.com/?GalacticModelingLanguage https://wiki.c2.com/?GalacticModelingLanguage

wild_egg 2y ago

Anyone know of an example of any other style? Would love to see any half-baked experiments even. Seems like a space that could really use some innovation

__MatrixMan__ 2y ago
I don't have any code for this, but I always thought it would be better if the boxes represented data types and the arrows represented functions. Then you could use the arrow as a progress bar, and you'd have something that's a bit more focused on the inputs and outputs. Also, the data types could show up as a stack of boxes (like a deck of cards) so you can see when you've calculated a novel dataset (highlight new card on top the deck) or when you've recalculated a previous dataset (highlight the nth card). Such a view would resemble a commutative diagram (from category theory) and if you let the cards pile up for a while you could use their sizes to reason about which functions are bijective, which are good candidates for memorization, etc. When you want to know why a certain datum is the way it is, you can use the same view to trace it back to it's inputs (in the boxes-as-tasks mode, you end up zooming in on some imperative artifact... logs usually... And discerning the inputs is left as an exercise to the reader). I think this goes by the buzzword "data lineage" and it's usually this extra thing but I think it should be the main thing. Which is why I want to make the nodes into edges and the edges into nodes.
- deleted 2y ago
  [deleted]
- andyferris 2y ago
  This is interesting. How do you visually identify a function with multiple inputs and outputs? I tend to imagine it as a bi-graph - with boxes for values and for functions, and arrows in between. The stack idea is interesting and can work here too. I could get behind saying "all functions have exactly one input value and one output value" but you really need to be able to construct and deconstruct structs/records/tuples to be able to e.g. pass two values to one function.
  - __MatrixMan__ 2y ago
    Ah, yeah, you caught me. It's not so simple as a transform from nodes to edges. What I actually have in mind is a bit stranger, but the node/edge swap was my stepping stone towards it, which is why I mentioned it. The structs/records/tuples approach would work (I think this would correspond with "currying"), but I have this weird idea that certain types of reasoning have a "shape" and that we might be able to more heavily lean on analagous reasoning if we could easily show that shape in correspondence with explanations of our reasoning. I worry that currying everything would force us further away from the "natural" shape (if there even is such a thing). I've been working on something called plibs (simPlical mad LIBS, since really we're showing a https://en.m.wikipedia.org/wiki/Simplicial_complex https://en.m.wikipedia.org/wiki/Simplicial_complex here). The functions are represented as tuples of the same arity, and described via sentences with blanks in them (e.g. when you run ____ code in ____ environment you get ____ from stdout). One with three blanks would then appear like a triangle and then I'd fill it in with a gradient indicating which sides are inputs and which are outputs. Functions sharing a mad lib would appear as a regular polygon in the same color (one edge for each blank). Or maybe they're sort of starfish shaped so that each leg can reach out an touch whatever the data representation ends up being. One could imagine algorithms that generate patchwork quilts or 3D structures (like how protein folding is represented) out of such things. These could be computed only in one direction (from inputs towards outputs) but they could be traversed in any direction if one wanted to explore the relationships. I'm hoping it will be a nice way of citing your computational sources. You would attach them to any computational result (alongside a scientific paper, perhaps) as a way if saying "here's how I came up with this, rerun it to verify my result". Aside from the computational pathway that yielded the result that's being scrutinized, you could explore adjacent plibs to understand why certain inputs were chosen or to gain other contextual hints. Now that I'm describing it it sounds a bit like that awful zooming-through-towers-of-data visualization in "Hackers" the movie. So the "edge" that I was using as a progress bar in my previous description is really a series of paths through a space made of these things. The details of the functions being called (and of the datasets being generated) are attached to the polygonal regions that the paths connect. The paths may merge or branch. It could get unwieldy, so the user would have to be explicit about which plibs to show and which to highlight as a chain of computation. As for how the represent the intermediate data and their types, I keep changing my mind. Some days I like the stacks of cards thing, some days not. Hopefully something will sick soon, then I'll try to build it.
viraptor 2y ago
Depends how literally you mean programming and processing. For example UML is a programming diagram. If you don't have the definitions anywhere else and always merge the diagram with specific methods implementation when compiling, is that an good example? What about ERD? If you materialise that into schema, is that programming? I think you'll run only into those two categories - boxes represent literal code you join together, or boxes represent something declarative that gets compiled into code but not necessarily in a straightforward way. I guess visual reporting like in MS Access could be thought of as a separate category? Depending on whether prose is programming, there's also https://visar.app/ https://visar.app/ And then there's CUBE https://marc.najork.org/papers/vl1992.pdf https://marc.najork.org/papers/vl1992.pdf
- Ringz 2y ago
  Thank you for the very interesting links. I used UML extensively during my studies in the nineties, back then on Unix machines. Interestingly, even then, it was possible to work together on a UML concept. I'm not sure anymore if the novelty of working with a graphical UML program was the motivation, or the opportunity to program in something other than Modula. In the end, after my studies, I still had to program only in C++. Once accustomed to the relative directness, it is difficult to embrace new innovative concepts. But I would welcome it.
jdougan 2y ago
Scratch is arguably a style of visual programming
- viraptor 2y ago
  Scratch is boxes and arrows with arrows of zero length ; )
  - jdougan 2y ago
    I know that's a joke, but in that case every screen is a grid of (v. small) boxes with arrows of zero length.
  - philsnow 2y ago
    Blockly (the visual editor used by Scratch) elegantly shows hierarchy of control flow. I've never seen a boxes-and-lines visual editor where loops are as easily understood as Blockly pieces.
NaOH 2y ago
Keyboard Maestro foregoes the lines between boxes, but it still presents the same general format. https://www.keyboardmaestro.com/img/v11/overview-dark@2x.png https://www.keyboardmaestro.com/img/v11/overview-dark@2x.png
ninetyninenine 2y ago
Text itself is a form of visual programming. We really have only two styles of visual programming: 1. Some sort language formed by left to right based alphabetic symbols in some pattern called "grammar". There's an almost infinite amount of possible grammars 2. Boxes and lines. Where boxes represent state or function and lines connect the boxes and state together. There's less formalization in this area so the axioms are vague but it can form something of a "grammar" similar to the above. That's it. It's not a space that could really use innovation. It's the fact that the entire space has never innovated. We've just been drilling down on a very specific and biased way of seeing the universe. The concept of a compiler literally illustrates how deep it goes and how tied the idea of a program is to a "language".
- DonHopkins 2y ago
  I disagree that "It's not a space that could really use innovation." There's quite a lot of innovation and experimentation in the visual programming space, and many vastly different approaches to visual programming. You forgot about block based visual programming languages like Scratch, Snap!, and Nassi-Shneiderman diagrams, and also the most ubiquitous, widely used, universally known, commonly taught, extremely powerful, and easily accessible style of visual programming language, which the worldwide economy depends on and would collapse if millions of people didn't regularly use them every day: spreadsheets.
okennedy 2y ago
Spreadsheets.
- smegger001 2y ago
  Spreadsheets are to visual box and line programming what goto spaghetti-code is to traditional programming languages.
jes5199 2y ago
I’ve seen a demo - cannot immediately remember where - where instead of data flowing through lines, it actually had a physics engine where the data was shot out of the boxes in various directions, and did computation with whatever box it intersected with next
CannisterFlux 2y ago
The only other thing I can think of is GB Studio - https://www.gbstudio.dev/ https://www.gbstudio.dev/ - but the visual scripting there is like regular coding, but with visual blocks. It doesn't use boxes and lines. Instead, the script elements are more like blocks within blocks.

deleted 2y ago

[deleted]

x-complexity 2y ago

> every form of visual programming I've ever seen is a singular style of some of a box that does processing and a line that connects that box to another box. Mainly because it's the most straightforward method to: 1) Visualize a contained piece of code / function (box) 2) Show where the output of X goes to (line) There may be other styles, but this style is the easiest for a newbie to wrap their head around, and is the cleanest method of visualization. The box method can then be used to further wrap a bunch of boxes into a larger box when needed.

chefandy 2y ago
There are other advantages to this method: easily showing which wires are active while debugging, giving new programmers an intuitive sense of what's happening in control structures like for loops, using color, symbols and line weights to intuitively convey things about data/object types, giving users a complete list of potential methods and parameters without having to look for it, being able to use more complex code shapes to navigate complex classes, people can learn the basics of coding logic without needing to memorize syntax simultaneously... There are obviously tons of shortcomings to visual code, but I do think a lot of the guff they get is unwarranted.
- hermitcrab 2y ago
  The subject of textual vs graphical programming comes up so often that I attempted to write a summary of the pros and cons of each. https://successfulsoftware.net/2024/01/16/visual-vs-text-based-programming-which-is-better/ https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
  - chefandy 2y ago
    Nice!

pacificmint 2y ago

I realized at some point that when people at work draw on whiteboards it usually ends up as boxes and lines between boxes. But after thinking about it, it feels natural, because usually we talk about "Things" and the "Connections" between them. Could be a companies org chart, a family tree, a network diagram, abstract things like processes. It's all "Things" and "Connections". Maybe that's why graph theory has so many applications. Because at the end, it's all just graphs with vertices and edges.

ninetyninenine 2y ago
Well programming itself with text doesn't have boxes and lines. So there's other isomorphisms to represent this concept.
- yunohn 2y ago
  Programming, especially imperative, is essentially boxes (statements, function calls) and lines (control flow). That’s why algorithms can be represented as flowcharts.
  - ninetyninenine 2y ago
    Right. I call it an isomorphism. You can translate one into the other and back. Whatever "other" form of programming exists it can and should be translatable to boxes and diagrams. But this "other" form on first glance can look very different. There are no boxes and lines in C++ or python for example.
    - yunohn 2y ago
      I think you misread my post. Why would C++/Python not fit my description? Which languages do you consider?
      - ninetyninenine 2y ago
        No. I did not misread. I believe you misunderstood. You’re saying c++ and python fit into a category of programs that is foundation-ally really just boxes and lines. I’m saying that’s not the right way to look at it. Because you can make the opposing statement. You can say that programs that are boxes and lines are foundation-ally just text programs. So because both contradictory statements can be made both aren’t really correct. There is no hierarchy. Boxes and lines is one concept and textual programming is another peer concept standing on equal footing. Both are isomorphic and thus translatable to each other. The point of my post is to suggest that there are other concepts that occupy this equivalency space. Imagine a category of interchangeable interpretations of programming that are all translate-able between each other with no hierarchy. It’s similar to the space of human languages. All human languages don’t occupy a hierarchy yet all are isomorphic.

high_5 2y ago

Because programming is essentially about receiving the input data, transforming it through a process and in the end outputting it in some other form?

ninetyninenine 2y ago
But then how come we can represent this concept in a form without boxes and lines? See python, C++, javascript, etc.
- theshrike79 2y ago
  The functions and objects are the boxes, them calling each other are the lines =)
- scott_w 2y ago
  Because the boxes and lines are just an abstraction.
  - ninetyninenine 2y ago
    No the text is the abstraction. Or perhaps neither is the abstraction and they are just equivalent concepts like how uno is the same thing as one. Uno is spanish, one is English… there is no hierarchy where one concept is an abstraction over the other. The main point of my post is to suggest that there are other equivalent concepts between text and box/line.
    - taeric 2y ago
      I think we are operating on different definitions of abstractions/concepts, here. My guess is you are trying to invoke a very specific meaning of "abstraction" in another context. To note, most text is a symbolic representation of spoken words and words are abstractions of any number of things. Both physical things such as "running" and less physical things such as "thinking." (Yes, legographic texts exist, such that they may not be representing spoken words, but I fail to see how that changes things here?)

onion2k 2y ago

In the Scratch language blocks connect to each other like jigsaw pieces for internal function logic.

TeMPOraL 2y ago
Scratch is Lisp, you're literally assembling the AST :).
- DonHopkins 2y ago
  Scratch is much simpler and less powerful than Lisp, missing many of Lisp's most important features, like first class functions, complex data structures, and other first class objects. You can't even pass lists around as parameters, or include lists in other lists, and it's missing homoiconicity (representing code as data), reflection, macros, special forms, or even user defined blocks and control structures, etc. But Snap! goes way beyond Scratch, since it was inspired by and visually similar to Scratch, but is just as powerful as Scheme, including functions and everything else as first class objects, lexical closures, continuations, user defined blocks, macros, special forms, etc. It's much more powerful than Scratch, but uses the same visual interlocking block syntax. https://snap.berkeley.edu https://snap.berkeley.edu
  - EclipseMantis 2y ago
    Scratch does support user-created blocks.

DonHopkins 2y ago

Block based visual programming languages don't use lines connecting boxes to each other, which has been widely used for a long time with popular visual programming languages like Snap!, Scratch, Squeak eToys, Blockly, etc. Snap!: https://snap.berkeley.edu https://snap.berkeley.edu Scratch: https://scratch.mit.edu/ https://scratch.mit.edu/ Squeak eToys: http://www.squeakland.org/ http://www.squeakland.org/ Blockly: https://developers.google.com/blockly https://developers.google.com/blockly Also, spreadsheets are an extremely popular form of visual programming that has been around for a long time, which don't use lines to connect boxes either. VisiCalc: https://en.wikipedia.org/wiki/VisiCalc https://en.wikipedia.org/wiki/VisiCalc Lotus 1-2-3: https://en.wikipedia.org/wiki/Lotus_1-2-3 https://en.wikipedia.org/wiki/Lotus_1-2-3 Microsoft Excel: https://en.wikipedia.org/wiki/Microsoft_Excel https://en.wikipedia.org/wiki/Microsoft_Excel Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages: https://news.ycombinator.com/item?id=26061576 https://news.ycombinator.com/item?id=26061576

micheljansen 2y ago

Apple's Shortcuts seems heavily inspired by the visual programming language that Scratch uses: https://support.apple.com/guide/shortcuts-mac/intro-to-how-shortcuts-work-apdad3cbabfc/7.0/mac/14.0 https://support.apple.com/guide/shortcuts-mac/intro-to-how-s...

Tijdreiziger 2y ago
More like Automator: https://support.apple.com/guide/automator/welcome/mac https://support.apple.com/guide/automator/welcome/mac (although [per Wikipedia] the first Scratch prototype does seem to predate Automator by 1.5 years, so I suppose it’s possible there’s a connection)
- micheljansen 2y ago
  Shortcuts is indeed the (more than spiritual) successor to Automator. Scratch was pretty famous in interface design circles in the early 2000s (it was a pretty high profile MIT Media Lab project). I'm sure the Automator developers were aware of it, but it may also have been a case of both having a rich neighbour [1]. Agentsheets, for example, predates both by over 10 years [2] [1] https://folklore.org/A_Rich_Neighbor_Named_Xerox.html https://folklore.org/A_Rich_Neighbor_Named_Xerox.html [2] https://en.wikipedia.org/wiki/AgentSheets https://en.wikipedia.org/wiki/AgentSheets

smusamashah 2y ago

Turns out there is another form of visual programming called Spatial Programming https://www.youtube.com/watch?v=eQgxFuw8f1U https://www.youtube.com/watch?v=eQgxFuw8f1U

HumblyTossed 2y ago

There is already a diagram that would capture it so much better - flowcharts.

hermitcrab 2y ago

It is also what techies naturally draw on whiteboards. It is a very concise, expressive and flexible way to model things.

whartung 2y ago

Galactic Modeling Language: https://wiki.c2.com/?GalacticModelingLanguage https://wiki.c2.com/?GalacticModelingLanguage