Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Λ-2D: An Exploration of Drawing as Programming Language

media.mit.edu

Post reply on HN
Print view View original

11–20 of 58 posts

Re: Λ-2D: An Exploration of Drawing as Programming Language

#11

Post by FrustratedMonky »

WillAdams wrote: post #5

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…

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.

Re: Λ-2D: An Exploration of Drawing as Programming Language

#13

Post by kevindamm »

FrustratedMonky wrote: post #11
WillAdams wrote: post #5

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…

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.

Re: Λ-2D: An Exploration of Drawing as Programming Language

#15

Post by bbor »

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?

Re: Λ-2D: An Exploration of Drawing as Programming Language

#17

Post by pjmlp »

WillAdams wrote: post #5

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…

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.

Re: Λ-2D: An Exploration of Drawing as Programming Language

#18

Post by NikkiA »

spacedcowboy wrote: post #14

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...

Re: Λ-2D: An Exploration of Drawing as Programming Language

#19

Post by aapoalas »

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.

Re: Λ-2D: An Exploration of Drawing as Programming Language

#20

Post by imglorp »

tromp wrote: post #2

> 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

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.
Post reply on HN