λ-2D: An exploration of drawing as programming language(media.mit.edu) |
λ-2D: An exploration of drawing as programming language(media.mit.edu) |
I've done that with the predecessor function in lambda diagram form:
┬──────────
┼─────┬────
┼─────┼─┬──
│ ──┬─┼ ┼ ┬
│ ┬─┼─┼ │ │
│ │ ├─┘ │ │
│ ├─┘ │ │
└─┤ │ │
└─────┤ │
└─┘https://commons.wikimedia.org/wiki/File:One_page_from_Frege%...
Bret Victor's The Future of Programming and other talks come to mind - https://youtu.be/8pTEmbeENF4
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.
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.
Your editor would become a convergence game.
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.
I love the honesty in this sentence so much.
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
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.)
Also, I thought it would be fairly well established by now that the De Bruijn notation for the untyped lambda calculus, with prefix function abstraction but postfix application, better reflects its underlying properties since it allows for an intuitive visual understanding of reduction, where applications can be directly matched up to abstractions.
I worked on this very same idea (a programming language without text) during my grad school years, and it's online here, if anyone is curious:
Here's an example of one creator's projects (definitely not me!):
However written languages convey not just what a program does, but also, through the names of things, what it means. Unfortunately there is no validation of (or other computation with) the meaning - so what it seems to mean may or may not have any bearing on what it actually means, either now or previously.
Thus a program is not just how humans talk to machines, but also (one of many ways) humans talk to humans.
It's true that there's no validation of comments. But there's also no validation that the name of a variable is what that variable actually means, or that the name of a function is what that function actually does.
There are already games that allows you to place electric components, each as a pixel on a screen, where these pixels are powerful enough to allow you to code arbitrary programs. I particularly like The Powder Toy, with enough components to make a fast calculator: https://powdertoy.co.uk/Browse/View.html?ID=1214884
The author arK created some of the most powerful electronic-based saves in The Powder Toy. He also made a SNAKE game which you should definitely check out. They are impressive.
Redstone in Minecraft should also fit into this category, but the world is too big, components are less powerful and game tick is slow, so writing programs in it is too clumsy.
[0] https://en.wikipedia.org/wiki/Shape_grammar
[1] https://shape.design.gatech.edu/index.html
[2] https://shape.design.gatech.edu/Machine/Projects/12_Circuits...
Obviously text is the most powerful and intuitive means of programming, but I wonder if it's the best? Perhaps more generally, is language as we know it really the best way to convey meaning?
I've no idea on such topics. My curiosity has just been roused by this ambitious project.
I also love the option to obfuscate the code in two separate ways. This project rules.
I think this is backwards. I think the lack of collaboration is exactly why graphical programming can't be used by most. It's so badly needed, that it's not even usable without it, for the majority of people.
The fractal tree and UTM examples are absolutely beautiful and mind-bogglingly simple.
[0] I only did a pharo MOOC and read some bits about smalltalk but considering the crowd, it's possible someone has an image with similar if not better ideas.
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.