I love this concept but I feel it is hamstrung by the need to write it using a text editor. If the rectangles were defined by actual graphical shapes it would be a lot easier to read and understand.
Also I wonder if positional parameters would need to be replaced by named arguments.
Has this paradigm been explored as a basis for visual programming languages? It seems like it could do a better job of handling the “density” of a program, which is often a problem in VPLs.
Truly interesting read! @mhagiwara The article reads very well.
With the bandwidth left from parsing all that new information, all I can say is this is something. I know there's still a whole lot of figuring out to do.
(I imagine if there were peeps from other-than-earth, they'd probably communicate in a manner as this - depicted in the "Arrival" movie)
Thanks for sharing. I'll be donating a star on github and keeping watch-O
Having only the corners marked out with weird markers makes it hard to visualize the rectangles. It would be nicer to have the entire rectangle laid out of Unicode box drawing characters.
create x = 10;
time point;
print x; //prints 10 in first timeline, and 20 in the next
create traveler = 20;
traveler warps point{
x = traveler;
traveler kills traveler;
};
It's worth mentioning Orca[0] by Hundredrabbits, a 2-dimensional esolang which does incorporate time (and thus distance) and so is really 3-dimensional.
It's also worth checking out Extempore[1] by Andrew Sorensen and Ben Swift, which grants you have incredibly precise timing semantics at the sample level.
"Each extempore process has a scheduling engine built-in, allowing tasks to be scheduled for execution at a precise time in the future. Unlike threading constructs such as sleep() or wait(), which don’t provide strong guarantees about temporal accuracy (i.e. the time they’ll sleep/wait for), Extempore's scheduling engine is guaranteed to execute its tasks at the requested time (the number of audio samples since Extempore was started). This temporal guarantee is significant for time critical domains such as audio and graphic, and real-time systems programming."
What's cool about this is that you're able to modify the program while it's running, and only update sections of it at a time, using the editor as a scratchpad, and it supports networking so you can precisely synchronize a herd of non-local devices and do things you'd have an extremely hard time doing in other languages. The applications extend far beyond just audio and visual programming.
What both of these languages have in common is that they are designed for live coding, or as Sorensen says, cyberphysical programming. I am very interested in the marriage of these technologies and recent transformer models.
Maybe not exactly, but there was one task[1] in ICFPc 2024[2] where you create programs that are laid out in 2D, and there is a special operator that causes the control flow to travel back in time. It was super fun.
Besides Orca, Befunge, etc.. the McCulloch-Pitts Neuron is a graphical language with a discrete timestep, it solves some of the shortcomings of Orca and Recto where the evaluation has to do a lot of walking to traverse space.
I started thinking about Ven diagrams too and how that might be a useful flow control mechanism. It feels like there is a disconnect somewhere, and im not sure what it is.
I love this concept but I feel it is hamstrung by the need to write it using a text editor. If the rectangles were defined by actual graphical shapes it would be a lot easier to read and understand.
Also I wonder if positional parameters would need to be replaced by named arguments.
I consider Unreal Blueprints to be essentially a 2D language with the data flow and the execution flow modelled in separate dimensions.
Has this paradigm been explored as a basis for visual programming languages? It seems like it could do a better job of handling the “density” of a program, which is often a problem in VPLs.
Truly interesting read! @mhagiwara The article reads very well.
With the bandwidth left from parsing all that new information, all I can say is this is something. I know there's still a whole lot of figuring out to do.
(I imagine if there were peeps from other-than-earth, they'd probably communicate in a manner as this - depicted in the "Arrival" movie)
Thanks for sharing. I'll be donating a star on github and keeping watch-O
Hexagony is another 2d language: https://esolangs.org/wiki/Hexagony
There is also thje 2D dialect of Racket: https://docs.racket-lang.org/2d/
Having only the corners marked out with weird markers makes it hard to visualize the rectangles. It would be nicer to have the entire rectangle laid out of Unicode box drawing characters.
There is a whole category of multiple dimension languages on esolang [1]... Nothing you'd really want to use other than to impress someone.
No languages captures time as a dimension, yet.
[1] https://esolangs.org/wiki/Esolang:Categorization#Dimensions
I think emiT [1] comes quite close!
A time paradox from [2]:
[1] https://esolangs.org/wiki/EmiT, https://github.com/nimrag-b/emiT-C[2] https://www.reddit.com/r/ProgrammingLanguages/comments/1golf...
It's worth mentioning Orca[0] by Hundredrabbits, a 2-dimensional esolang which does incorporate time (and thus distance) and so is really 3-dimensional.
It's also worth checking out Extempore[1] by Andrew Sorensen and Ben Swift, which grants you have incredibly precise timing semantics at the sample level.
"Each extempore process has a scheduling engine built-in, allowing tasks to be scheduled for execution at a precise time in the future. Unlike threading constructs such as sleep() or wait(), which don’t provide strong guarantees about temporal accuracy (i.e. the time they’ll sleep/wait for), Extempore's scheduling engine is guaranteed to execute its tasks at the requested time (the number of audio samples since Extempore was started). This temporal guarantee is significant for time critical domains such as audio and graphic, and real-time systems programming."
What's cool about this is that you're able to modify the program while it's running, and only update sections of it at a time, using the editor as a scratchpad, and it supports networking so you can precisely synchronize a herd of non-local devices and do things you'd have an extremely hard time doing in other languages. The applications extend far beyond just audio and visual programming.
What both of these languages have in common is that they are designed for live coding, or as Sorensen says, cyberphysical programming. I am very interested in the marriage of these technologies and recent transformer models.
[0] https://100r.co/site/orca.html
[1] https://extemporelang.github.io/docs/overview/time/
> No languages captures time as a dimension, yet.
Maybe not exactly, but there was one task[1] in ICFPc 2024[2] where you create programs that are laid out in 2D, and there is a special operator that causes the control flow to travel back in time. It was super fun.
[1] https://github.com/icfpcontest2024/icfpc2024/blob/main/stati...
[2] https://icfpcontest2024.github.io/
Besides Orca, Befunge, etc.. the McCulloch-Pitts Neuron is a graphical language with a discrete timestep, it solves some of the shortcomings of Orca and Recto where the evaluation has to do a lot of walking to traverse space.
https://www.i-programmer.info/babbages-bag/325-mcculloch-pit...
It does so by creating instant connection between events across large distances.
Its inerrant parallalelism makes it also possible to do pretty complex evaluation on large canvases.
I'm guessing the author doesn't speak Spanish. :)
I thought the name was intentional. :)
My thoughts exactly lol
Isn't this just braces/parens with extra steps?
I started to think the same thing when it got down to the for-loop example. Is Python 2-d because it uses indentation for blocks?
Does Recto support something like this:
https://i.redd.it/tfd086olfoif1.jpeg
I started thinking about Ven diagrams too and how that might be a useful flow control mechanism. It feels like there is a disconnect somewhere, and im not sure what it is.
Why the tight limit of only 2 dimensions? Seems unnecessary. A more general approach would be to support an arbitrary amount of dimensions
Three cheers for the language that naturally requires a VR headset to visualize 5D tensor logic.
Yes, we should store text in string tensors.
I really enjoyed this read! Sending you support, strength and comfort to you for the days ahead