If you like this, you may find automation project engineer work fun... or at least familiar. Function block diagrams are quite like this: There function blocks are connected together with wires, and the order of operations is defined by block order. Blocks themselves are like builtin functions in the engine, or they can also be composites. The diagram is executed once per control cycle and generally (if no jump blocks exist), each block is always executed exactly once per control cycle regardless of if their inputs have changed or not.
And that is how control logic for anything from breweries to petrochemical plants is implemented! Fun stuff! I happen to work on the UI side of an FBD-based control system, so I float around this stuff day-to-day.
Yeah, exactly. I'm not too clear on how PLC, DCS (which is what I do), and others relate to each other but function block diagrams are used in both (according to Google anyway).
Ugh.... similar to BitGrid[1] (my own hobby horse), but not. I imagine bits marching in parallel across a grid in the ultimate simplification of an FPGA. It's an idea that either has supreme utility (Petaflops for the masses), or doesn't... it's all down to how much energy a DFF takes on an ASIC. (This is a pair of numbers I've been trying to find forever... static power, and energy to load a bit)
Oh... and the programming model, nobody likes plopping logic down on a grid, they try to abstract it away as fast as possible. I don't have sufficient focus to be able to do that bit.
[edit] Somewhere in exploring this, I came across Von Neumann cellular automaton[2] and Nobili cellular automata[3], which I've not encountered, despite being interested similar ideas for decades. It's frustrating just how little discoverability there is in this portion of computer science.
Of course both share the same insane foundation:
The set of FSAs define a cell space of infinite size. All FSAs are identical in terms of state-transition function, or rule-set.
It's that one "simplification" that relegates them to the domain of code golf.
> Technically the language is Turing complete at this point, but will be excruciatingly laborious to use, violating my design rule #2.
I stopped at step #1 with my Lambda Diagrams [1]. The bottom of that page links to all other graphical lambda calculus notations I know of (just added this one).
Excruciatingly laborious to read as well. The pixel font and line art is quaint but not ergonomic if you have to strain to read it or discern a wire shape. We left that stuff behind in the 90s when high res displays arrived.
These things have been done in Labview, and it's hard to get anywhere. It's also been done in sound/music generation programs, with Max [max] as a (the?) granddaddy. While you can get things done, it quickly becomes messy too.
IMO the visual wire/node paradigm of Max/MSP and Pure Data makes a lot of sense because it builds upon the "plug one box into another" interface that electronic music hardware follows, and because it can mirror electronic circuit layouts. I find it far easier to follow complex signal flows (especially with animated realtime diagrams showing numeric values in real time) in a visual layout vs. static text blocks.
Also more recent versions of Max/MSP have "mc" (multi-channel connections so you don't have to create separate wires/nodes for multiple identical signals) and text-based programming nodes with "~gen" and JavaScript.
All this "block programming languages" look promising, abstraction by black-boxing, doing boxes of boxes... I wonder if the implementations are bad, they are badly used, or the paradigm just does not work...
One thing to take into account, is that those things are typically used by people who have no idea how to program and abstract things. Maybe if somebody is good ad programming would not do a mess out of it; but then (s)he could just go ahead and write code. so.....
I must agree, LabView is terrible, not just because of that, but updates break everything, licensing, etc... just PITA
It takes a different mindset but clean and legible LabVIEW code can be written. There was a small community of professional LabVIEW developers who generally write very legible and good code. Different from what most people are used to but good.
I left that world years ago because the writing was on the wall, LabVIEW was going to die no matter what you could do with it.
I spent a lot of time in LabVIEW as well. I stopped with it way back when Active-X was thing and I got sick of always having to interface LabVIEW with Active-X controls.
LabVIEW is great for certain things, I think it has potential for others, but it's just too limited for general purpose computing.
Perhaps more important than anything is the fact that you can't just download it and use it like almost anything else these days. I don't think that has changed. It's not cheap either and they've switched to a subscription model.
I've been interested in graphical formal specifications since I first heard about Petri Nets like a decade ago. It always felt like engineers would be more likely to utilize formal methods if there was a graphical representation instead of a bunch of scary math notation and language associated with it. Sadly, every time I've tried showing Petri Nets to other engineers, they get pretty disinterested almost immediately.
Before I abandoned my PhD at University of York, I was working with something called "RoboChart" and RoboSim [1], which I actually think might be more approachable, but it's pretty tied into the robotics semantics. A pet project I've been working on has been trying to adapt and extend RoboSim to something a bit more useful for the network and server world.
Wow, I love this -- all the more so because it's implemented in Javascript! The purists are spinning in their beds/graves, but it clearly made the visualization and audio followup steps easier, at the very least. The visuals are killer, and the obvious next step is to somehow translate the higher-level structure of existing programs into this; I would imagine nerds would pay good money to get Djikstra's algorithm on their wall, or an ANN backprop algorithm.
I did find this part funny:
One interesting problem that I did not anticipate while imagining the language was that it turned out so purely functional and absolutely state-less, that it becomes impossible to implement a "print" statement, for to print is to change state, to expect some things to be printed in some particular order is to assume that some expressions will be evaluated in some order.
Isn't this just to say "not imperative"? Regardless, it does make me wonder how one would encode state... maybe introduce variables (icon + color?) and have individual statements ordered on one or both axes?
Reminds me of the 1987 “Wireworld”, of course Wikipedia has an article [1]. I’ve seen 8-bit counters implemented in wireworld, which is quite something, though this looks a bit more … succinct.
I find Zach(tronics)'s take on this in KOHCTPYKTOP much more pleasing somehow.
Of course, it's difficult to play now, since the webpage [1], and steam version relied on flash, and you have to fiddle with a 3rd party flash reimplementation.
But its implementation of semiconductor behaviour is much better than wireworld's.
Some other very visual programming environments/languages that I have found. They are different from other visual programming where you connect nodes with lines. These can be categorised differently but I don't what that will be.
I explored this idea a while ago
https://ouwi.org/
I wasn't able to get the perfect crystal I wanted but I think whatever works will need to be a lot more visually differentiated than the MIT version
Something that always struck me about this sort of thing, or in similar games, is that it is only 2D and so rapidly becomes incredibly crowded with lines going everywhere.
We code in a 2D nature (rows and columns) but the flow is non-euclidean I guess
This reminds me of Lukasa memory boards, analogous to written language as this is to traditional programming (or as a table is to a chart). It's amazing how the way information is encoded and presented can affect its interpretation.
Pffft, come back to me when these can all be auto-mapped to Factorio or Stardew Valley-esque metaphorical actions, then we'll talk
But no, seriously, this is super cool - I do honestly expect we're very close to diffusion-based image models being full programming suites (and compiling down to much more efficient representations, of course, but programming is abstracted for useful human understanding!)
The problem here, as always is that there isn't an agreed-upon answer for the question:
>What does an algorithm look like?
The problem is expressiveness of such a diagram is bounded by the size of a screen or a sheet of paper, and once one starts to scroll, or can't see the entire flow at a glance, things get complicated.
The node/wire programming folks have this a bit rougher to the point that there are sites such as:
I prefer to work visually, but not sure if that's actually valid --- unfortunately https://www.blockscad3d.com/editor/ doesn't support all of OpenSCAD and https://github.com/derkork/openscad-graph-editor has problems with a stylus (I have to leave the Windows Settings app open to toggle stylus behaviour which is enough friction that I don't use it as much as I would otherwise).
The problem is that while on text based languages folks quickly learn to use subroutines and modules/packages, apparently the same concept seems alien to anyone that hasn't done digital circuit design.
Most visual languages, support subroutines and modules/packages as well, no need to design a gigantic piece of spaghetti.
If anything, visual languages make it clear straight away when the code is a mess.
Yes, but if one uses subroutines/modules, then one ends up with the wall of text which one was presumably attempting to escape from --- just wrapped up in coloured boxes/connected with lines.
GraphSCAD at least affords an option to add an image to a module representation, preserving some of the visual aspect --- I believe OpenSCAD Graph Editor has that in the works (if it's not already done).
It's Unreal Engine 4 (the UE4 in the in-body title).. seems all or most of them are in the animations control flow editor. You can find a similar interface in Unity's Animation controller editor, too. Sometimes you'll find this interface in behavior tree editors and shader editors within both UE4 and Unity, also.
If you like this, you may find automation project engineer work fun... or at least familiar. Function block diagrams are quite like this: There function blocks are connected together with wires, and the order of operations is defined by block order. Blocks themselves are like builtin functions in the engine, or they can also be composites. The diagram is executed once per control cycle and generally (if no jump blocks exist), each block is always executed exactly once per control cycle regardless of if their inputs have changed or not.
And that is how control logic for anything from breweries to petrochemical plants is implemented! Fun stuff! I happen to work on the UI side of an FBD-based control system, so I float around this stuff day-to-day.
Like PLCs or something similar?
Yeah, exactly. I'm not too clear on how PLC, DCS (which is what I do), and others relate to each other but function block diagrams are used in both (according to Google anyway).
Ugh.... similar to BitGrid[1] (my own hobby horse), but not. I imagine bits marching in parallel across a grid in the ultimate simplification of an FPGA. It's an idea that either has supreme utility (Petaflops for the masses), or doesn't... it's all down to how much energy a DFF takes on an ASIC. (This is a pair of numbers I've been trying to find forever... static power, and energy to load a bit)
Oh... and the programming model, nobody likes plopping logic down on a grid, they try to abstract it away as fast as possible. I don't have sufficient focus to be able to do that bit.
[edit] Somewhere in exploring this, I came across Von Neumann cellular automaton[2] and Nobili cellular automata[3], which I've not encountered, despite being interested similar ideas for decades. It's frustrating just how little discoverability there is in this portion of computer science.
Of course both share the same insane foundation:
It's that one "simplification" that relegates them to the domain of code golf.[1] https://github.com/mikewarot/Bitgrid
[2] https://en.wikipedia.org/wiki/Von_Neumann_cellular_automaton
[3] https://en.wikipedia.org/wiki/Nobili_cellular_automata
pps: If anyone wants to run with the idea of a BitGrid, I'd appreciate it
> Technically the language is Turing complete at this point, but will be excruciatingly laborious to use, violating my design rule #2.
I stopped at step #1 with my Lambda Diagrams [1]. The bottom of that page links to all other graphical lambda calculus notations I know of (just added this one).
[1] https://tromp.github.io/cl/diagrams.html
of interest to this site, the Y combinator as a Lambda Diagram: https://tromp.github.io/img/cl/Y.logo.gif
BTW, Firefox' built in translation feature asked if I wanted to translate that page from Greek.
Which means you can now claim that your language made a browser say "It's all Greek to me!", which is a pretty cool achievement I think.
Excruciatingly laborious to read as well. The pixel font and line art is quaint but not ergonomic if you have to strain to read it or discern a wire shape. We left that stuff behind in the 90s when high res displays arrived.
Looks like Sumerian cuneiform to me, cool.
I think you missed "Alligator Eggs"!
https://worrydream.com/AlligatorEggs/
added...
These things have been done in Labview, and it's hard to get anywhere. It's also been done in sound/music generation programs, with Max [max] as a (the?) granddaddy. While you can get things done, it quickly becomes messy too.
Does it look good? I don't think so.
[max] https://en.wikipedia.org/wiki/Max_(software)
IMO the visual wire/node paradigm of Max/MSP and Pure Data makes a lot of sense because it builds upon the "plug one box into another" interface that electronic music hardware follows, and because it can mirror electronic circuit layouts. I find it far easier to follow complex signal flows (especially with animated realtime diagrams showing numeric values in real time) in a visual layout vs. static text blocks.
Also more recent versions of Max/MSP have "mc" (multi-channel connections so you don't have to create separate wires/nodes for multiple identical signals) and text-based programming nodes with "~gen" and JavaScript.
Simulink should be included in the list?
All this "block programming languages" look promising, abstraction by black-boxing, doing boxes of boxes... I wonder if the implementations are bad, they are badly used, or the paradigm just does not work...
One thing to take into account, is that those things are typically used by people who have no idea how to program and abstract things. Maybe if somebody is good ad programming would not do a mess out of it; but then (s)he could just go ahead and write code. so.....
I must agree, LabView is terrible, not just because of that, but updates break everything, licensing, etc... just PITA
It takes a different mindset but clean and legible LabVIEW code can be written. There was a small community of professional LabVIEW developers who generally write very legible and good code. Different from what most people are used to but good. I left that world years ago because the writing was on the wall, LabVIEW was going to die no matter what you could do with it.
I spent a lot of time in LabVIEW as well. I stopped with it way back when Active-X was thing and I got sick of always having to interface LabVIEW with Active-X controls.
LabVIEW is great for certain things, I think it has potential for others, but it's just too limited for general purpose computing.
Perhaps more important than anything is the fact that you can't just download it and use it like almost anything else these days. I don't think that has changed. It's not cheap either and they've switched to a subscription model.
LabVIEW is still used a lot in Aerospace. Definitely due for a replacement at some point.
I've been interested in graphical formal specifications since I first heard about Petri Nets like a decade ago. It always felt like engineers would be more likely to utilize formal methods if there was a graphical representation instead of a bunch of scary math notation and language associated with it. Sadly, every time I've tried showing Petri Nets to other engineers, they get pretty disinterested almost immediately.
Before I abandoned my PhD at University of York, I was working with something called "RoboChart" and RoboSim [1], which I actually think might be more approachable, but it's pretty tied into the robotics semantics. A pet project I've been working on has been trying to adapt and extend RoboSim to something a bit more useful for the network and server world.
[1] https://robostar.cs.york.ac.uk/robotool/
Wow, I love this -- all the more so because it's implemented in Javascript! The purists are spinning in their beds/graves, but it clearly made the visualization and audio followup steps easier, at the very least. The visuals are killer, and the obvious next step is to somehow translate the higher-level structure of existing programs into this; I would imagine nerds would pay good money to get Djikstra's algorithm on their wall, or an ANN backprop algorithm.
I did find this part funny:
Isn't this just to say "not imperative"? Regardless, it does make me wonder how one would encode state... maybe introduce variables (icon + color?) and have individual statements ordered on one or both axes?"The area of non-verbal programming languages has not been unexplored."
Starting out with the aggressive triple negative in sentence two!
And there is scratch right?
Scratch isn't non-verbal (or is it?)
Reminds me of the 1987 “Wireworld”, of course Wikipedia has an article [1]. I’ve seen 8-bit counters implemented in wireworld, which is quite something, though this looks a bit more … succinct.
[1]: https://en.wikipedia.org/wiki/Wireworld
I find Zach(tronics)'s take on this in KOHCTPYKTOP much more pleasing somehow.
Of course, it's difficult to play now, since the webpage [1], and steam version relied on flash, and you have to fiddle with a 3rd party flash reimplementation.
But its implementation of semiconductor behaviour is much better than wireworld's.
[1] https://www.zachtronics.com/kohctpyktop-engineer-of-the-peop...
There's a newer version of this in Last Call BBS called Chip Wizard. Much smaller grid makes for more puzzlyness.
Direct link to the online demo: https://l-2d.glitch.me/
Talk about burying the lede!
In terms of the programming paradigm this is not dissimilar to Funciton:
https://codeberg.org/Timwi/Funciton
https://esolangs.org/wiki/Funciton
Some other very visual programming environments/languages that I have found. They are different from other visual programming where you connect nodes with lines. These can be categorised differently but I don't what that will be.
Piet https://www.dangermouse.net/esoteric/piet.html
Turnstyle https://jaspervdj.be/turnstyle/ https://github.com/jaspervdj/turnstyle
Markovjunior https://github.com/mxgmn/MarkovJunior
Cellpond https://cellpond.cool/ https://github.com/TodePond/CellPond https://www.youtube.com/watch?v=xvlsJ3FqNYU
Imagegram https://zaratustra.itch.io/imagegram
Color Code http://colorcode.bananabanana.me/ https://www.youtube.com/watch?v=5M5hy9xsqKc Color Code 2 http://colorcode2.bananabanana.me/ https://www.youtube.com/watch?v=tTvvX4sjZWw Splaty Code http://splatycode.bananabanana.me/ https://www.youtube.com/watch?v=gd_e85lAKOs (By Muril Polese https://github.com/murilopolese/ http://gallery.bananabanana.me/)
Alchemy Online https://maxbittker.github.io/alchemy-online/ https://github.com/MaxBittker/alchemy-online
I explored this idea a while ago https://ouwi.org/ I wasn't able to get the perfect crystal I wanted but I think whatever works will need to be a lot more visually differentiated than the MIT version
The input reminds me a lot of the work pointed to here (good ole jart)[https://justine.lol/lambda/#diagrams]
Now if only I could get my head around it (shout out to the alligator eggs ref too)
Looks cool! I believe the demo would really benefit from
applied to all canvas elements.This will make the pixel art style rendering look much nicer, without the slight smoothing that makes the pixel edges a little blurry.
Takes me back to the good-old-days of block diagrams. Those went away with few complaints.
Beautifully executed. The animated run feature on the online demo is exciting to watch.
Something that always struck me about this sort of thing, or in similar games, is that it is only 2D and so rapidly becomes incredibly crowded with lines going everywhere.
We code in a 2D nature (rows and columns) but the flow is non-euclidean I guess
There's not enough space to represent code graphically, anything significant becomes crowded and messy.
Every project like this starts off extolling that we are visual creatures, but this is a type of visualization we're not well suited to.
It's a shame because in 3D you can do much much cleaner layout in general.
This reminds me of Lukasa memory boards, analogous to written language as this is to traditional programming (or as a table is to a chart). It's amazing how the way information is encoded and presented can affect its interpretation.
It's all way over my head, but this is amazing work! The 2 obfustication techniques are pretty insane.
Had some issues trying to upload my own png's, maybe too big(?)
Visual programming languages are very common.
Examples are game engines (Unreal and Unity), 3D art/effect tools (Houdini), Simulink etc.
unicode program note for people who share the curiosity I had:
the first letter in the title is Greek capital-lambda; the others I've included here for comparison are less than, greater than, and capital-vthe original article uses lowercase λ
Nice ideas. I like the notebook where can I get it ?
moleskine.com
Nobody gave a shout out to Robot Odyssey yet?
Looks unreadable and reminds me of Factorio.
That looks like a fun project to build!
Pffft, come back to me when these can all be auto-mapped to Factorio or Stardew Valley-esque metaphorical actions, then we'll talk
But no, seriously, this is super cool - I do honestly expect we're very close to diffusion-based image models being full programming suites (and compiling down to much more efficient representations, of course, but programming is abstracted for useful human understanding!)
See also: https://en.wikipedia.org/wiki/Carnage_Heart
Sure a fun project, but that neither looks good, nor is it easy to understand. Reminds me of Frege's notation on steroids.
I like the animations, though.
Why did it have to be pixelated in appearance? It would be far more attractive as anti-aliased vector lines and type.
The red highlighting reminds me of electricity in the classic circuit problem game _Rocky's Boots_ on the Apple ][.
As I've posted in similar discussions: https://news.ycombinator.com/item?id=42051536
The problem here, as always is that there isn't an agreed-upon answer for the question:
>What does an algorithm look like?
The problem is expressiveness of such a diagram is bounded by the size of a screen or a sheet of paper, and once one starts to scroll, or can't see the entire flow at a glance, things get complicated.
The node/wire programming folks have this a bit rougher to the point that there are sites such as:
https://blueprintsfromhell.tumblr.com/
https://scriptsofanotherdimension.tumblr.com/
I prefer to work visually, but not sure if that's actually valid --- unfortunately https://www.blockscad3d.com/editor/ doesn't support all of OpenSCAD and https://github.com/derkork/openscad-graph-editor has problems with a stylus (I have to leave the Windows Settings app open to toggle stylus behaviour which is enough friction that I don't use it as much as I would otherwise).
There are promising tools though: https://nodezator.com/ and https://ryven.org/ are very cool.
The problem is that while on text based languages folks quickly learn to use subroutines and modules/packages, apparently the same concept seems alien to anyone that hasn't done digital circuit design.
Most visual languages, support subroutines and modules/packages as well, no need to design a gigantic piece of spaghetti.
If anything, visual languages make it clear straight away when the code is a mess.
Yes, but if one uses subroutines/modules, then one ends up with the wall of text which one was presumably attempting to escape from --- just wrapped up in coloured boxes/connected with lines.
GraphSCAD at least affords an option to add an image to a module representation, preserving some of the visual aspect --- I believe OpenSCAD Graph Editor has that in the works (if it's not already done).
For this link you gave
https://blueprintsfromhell.tumblr.com/
What is link to some more background on the 'blueprint' app. I couldn't find it.
It's Unreal Engine 4 (the UE4 in the in-body title).. seems all or most of them are in the animations control flow editor. You can find a similar interface in Unity's Animation controller editor, too. Sometimes you'll find this interface in behavior tree editors and shader editors within both UE4 and Unity, also.