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

41–50 of 59 posts

Re: λ-2D: An exploration of drawing as programming language

#41

Post by kmill »

I've messed around with this same graphical language, though only on paper. As I understand it, the lambda/apply nodes are the two morphisms for reflexive objects[1], and these are something like string diagrams for them -- though I haven't fully understood how to interpret oriented wires from this point of view...

There a paper referenced by [2] (a project shared on HN in the last couple months) that goes into a graphical language for lambda calculus with the same apply/lambda nodes, but with explicit copying and dropping. The paper is Lafont, "Interaction Combinators" from 1997. (You have to squint to see why it's got anything to do with the lambda calculus.) A similar graphical language is Chemlambda by Buliga, which uses graph rewrite rules with very similar node types.

Programming by drawing things in 2D on a fixed grid is an interesting idea I've wanted to experiment with. (I'd imagined a more Factorio-like Puredata or Max/MSP. It's something that came to mind from having read about [3].)

[1] https://ncatlab.org/nlab/show/reflexive+object [2] https://github.com/Kindelia/HVM/blob/master/HOW.md [3] https://100r.co/site/orca.html

Re: λ-2D: An exploration of drawing as programming language

#44

Post by trenchgun »

IIAOPSW wrote: post #37
tromp wrote: post #5

> To be able to draw programs that look visually appealing themselves, such that someone would want to put a frame around them and hang them on the wall. I've done that with the predecessor function in lambda diagram form: ┬────────── ┼─────┬──── ┼─────┼─┬── │ ──┬─┼ ┼ ┬ │ ┬─┼─┼ │ │ │ │ ├─┘ │ │ │ ├─┘ │ │ └─┤ │ │ └─────┤ │ └─┘ Lambda diagrams [1] are just a graphical output format for the pure lambda calculus though, a…

You could easily repurpose that code for drawing Quantum Circuits and thus representing quantum computations. I'm tempted to make a pull request this instant and do it myself.

That would be very nice.

Re: λ-2D: An exploration of drawing as programming language

#45

Post by progre »

LichenStone wrote: post #2

This is very cool. I've always been very disappointed that programming is so utterly dominated by the linear text format. It feels like so much potential for expression and feedback is getting left on the table, making use of our capacity to understand and work with spatialisation, patterns, sounds, colours, dynamics, etc would make a lot of sense. Bret Victor's The Future of Programming and other talks come to mind…

As someone who has done thousands of hours of programming in a visual language (IAR Visual State), I hate it. The promise of an easy visual overview quickly drowns in a sea of edge cases.

A picture says a thousand words, sure, but precicely what those words are turns out to be important. We use text for programming because it allows us to express ourselves unambigously.

I sure would like to see more visual representations of text programs though, this seems like the best of both worlds to me.

Re: λ-2D: An exploration of drawing as programming language

#46

Post by DoingIsLearning »

progre wrote: post #45
LichenStone wrote: post #2

This is very cool. I've always been very disappointed that programming is so utterly dominated by the linear text format. It feels like so much potential for expression and feedback is getting left on the table, making use of our capacity to understand and work with spatialisation, patterns, sounds, colours, dynamics, etc would make a lot of sense. Bret Victor's The Future of Programming and other talks come to mind…

As someone who has done thousands of hours of programming in a visual language (IAR Visual State), I hate it. The promise of an easy visual overview quickly drowns in a sea of edge cases. A picture says a thousand words, sure, but precicely what those words are turns out to be important. We use text for programming because it allows us to express ourselves unambigously. I sure would like to see more visual representa…

I've also had clients that used Simulink/StateFlow modeling for embedded state machines and to me it works up to a certain degree of complexity.

It works really well for a quick prototype, but for anything more envolved I find the cognitive fatigue of a complex visual model is much greater than keeping a mental model and looking at a narrow scope piece of text.

Re: λ-2D: An exploration of drawing as programming language

#47

Post by graderjs »

This guy is such a genius. I'm continuously blown away by his stuff. His work just keeps getting better and better. It's mind-boggling. He's also the author of all this stuff on GitHub which is incredible:

https://github.com/LingDong-

His work is timeless. to me it has this sort of timeless quality to it: people will look at it in like a hundred years or 400 years and be like yeah this person was a genius, they were doing like 2022-Renaissance level stuff at this time. That's what I think... And obviously there's incredible groups like what openai just did with the drawing technology. But as an individual contributor this person's incredible.

Also I love the relentless exploration of code as an artistic medium.

Re: λ-2D: An exploration of drawing as programming language

#48

Post by zozbot234 »

kmill wrote: post #41

I've messed around with this same graphical language, though only on paper. As I understand it, the lambda/apply nodes are the two morphisms for reflexive objects[1], and these are something like string diagrams for them -- though I haven't fully understood how to interpret oriented wires from this point of view... There a paper referenced by [2] (a project shared on HN in the last couple months) that goes into a gra…

> I've messed around with this same graphical language, though only on paper. As I understand it, the lambda/apply nodes are the two morphisms for reflexive objects[ https://ncatlab.org/nlab/show/reflexive+object ]

That's a useful pointer. It's interesting that the nLab folks seem to specifically point out higher-order abstract syntax as the underlying intuition behind these 'lam' and 'app' morphisms. So if actual string diagrams exist for these, the same sort of graphical representation may well be applicable beyond the untyped lambda calculus itself, to any syntax that has some equivalent to "variables" that can be used for substitution as in beta-reduction. (Note that the graphical representation of a typed lambda calculus is fairly obvious and intuitive, but only because functions then get different types based on their arity, etc. and this is directly reflected in the visual syntax. Once you go untyped, it doesn't seem that this can be true.)

Re: λ-2D: An exploration of drawing as programming language

#50

Post by nek28 »

tromp wrote: post #5

> To be able to draw programs that look visually appealing themselves, such that someone would want to put a frame around them and hang them on the wall. I've done that with the predecessor function in lambda diagram form: ┬────────── ┼─────┬──── ┼─────┼─┬── │ ──┬─┼ ┼ ┬ │ ┬─┼─┼ │ │ │ │ ├─┘ │ │ │ ├─┘ │ │ └─┤ │ │ └─────┤ │ └─┘ Lambda diagrams [1] are just a graphical output format for the pure lambda calculus though, a…

This reminds me of Frege's Begriffschrifft

https://commons.wikimedia.org/wiki/File:One_page_from_Frege%...

Post reply on HN