[HN Gopher] L-2D: An Exploration of Drawing as Programming Language
___________________________________________________________________
L-2D: An Exploration of Drawing as Programming Language
Author : threeme3
Score : 160 points
Date : 2024-11-08 08:30 UTC (14 hours ago)
(HTM) web link (www.media.mit.edu)
(TXT) w3m dump (www.media.mit.edu)
| tromp wrote:
| > 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
| 082349872349872 wrote:
| of interest to this site, the Y combinator as a Lambda Diagram:
| https://tromp.github.io/img/cl/Y.logo.gif
| imglorp wrote:
| 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.
| pyinstallwoes wrote:
| Looks like Sumerian cuneiform to me, cool.
| sans_souse wrote:
| 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(?)
| Instantnoodl wrote:
| That looks like a fun project to build!
| WillAdams wrote:
| 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.
| FrustratedMonky wrote:
| 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.
| kevindamm wrote:
| 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.
| pjmlp wrote:
| 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.
| WillAdams wrote:
| 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).
| auggierose wrote:
| Sure a fun project, but that neither looks good, nor is it easy
| to understand. Reminds me of Frege's notation on steroids.
| auggierose wrote:
| I like the animations, though.
| karmonhardan wrote:
| 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.
| igtztorrero wrote:
| Nice ideas. I like the notebook where can I get it ?
| varjag wrote:
| moleskine.com
| smusamashah wrote:
| 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
| spacedcowboy wrote:
| 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
| NikkiA wrote:
| 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...
| bbor wrote:
| 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?
| yboris wrote:
| Direct link to the _online demo_ : https://l-2d.glitch.me/
| aapoalas wrote:
| 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.
| aaronblohowiak wrote:
| Like PLCs or something similar?
| aapoalas wrote:
| 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).
| addaon wrote:
| "The area of non-verbal programming languages has not been
| unexplored."
|
| Starting out with the aggressive triple negative in sentence two!
| ersiees wrote:
| And there is scratch right?
| atlintots wrote:
| Scratch isn't non-verbal (or is it?)
| reportgunner wrote:
| Looks unreadable and reminds me of Factorio.
| mattlondon wrote:
| 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
| jasfi wrote:
| 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.
| 6gvONxR4sf7o wrote:
| It's a shame because in 3D you can do much much cleaner layout
| in general.
| 8bitsrule wrote:
| Takes me back to the good-old-days of block diagrams. Those went
| away with few complaints.
| tgv wrote:
| 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)
| f1shy wrote:
| 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
| fluorinerocket wrote:
| 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.
| redhed wrote:
| LabVIEW is still used a lot in Aerospace. Definitely due for
| a replacement at some point.
| crispyambulance wrote:
| 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.
| Optimal_Persona wrote:
| 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.
| sriram_malhar wrote:
| Beautifully executed. The animated run feature on the online demo
| is exciting to watch.
| tombert wrote:
| 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/
| mikewarot wrote:
| 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.
|
| [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
| fsckboy wrote:
| unicode program note for people who share the curiosity I had:
| L-2D < > V
|
| 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-v
|
| the original article uses lowercase l
| shove wrote:
| Nobody gave a shout out to Robot Odyssey yet?
| dogcomplex wrote:
| 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!)
| Timwi wrote:
| In terms of the programming paradigm this is not dissimilar to
| Funciton:
|
| https://codeberg.org/Timwi/Funciton
|
| https://esolangs.org/wiki/Funciton
___________________________________________________________________
(page generated 2024-11-08 23:00 UTC)