A pretty radical take on the future of programming...
# thinking-together
k
A pretty radical take on the future of programming:

https://youtube.com/watch?v=I4flQ8XdvJM

❤️ 3
💡 3
👍 5
After recent conversations I find myself wondering what Forth running on this substrate would look like. This guy should try to collaborate with Chuck Moore on Green Arrays. cc @wtaysom @Garth Goldwater @fyr
g
will definite check it out! from the description it reminds me of this talk by one of the inventors of Self:

https://youtu.be/M-fX01R1Ky8

about nondeterminism + parallelism

https://youtu.be/helScS3coAE

extremely cool specific example for people with less time on their hands
y
Oh wow. This should be the next Zachtronics game, right here
❤️ 3
s
It is interesting. I think there was an earlier conversation about using spacial relationships for state mutation, MFM does that in a lot of ways
there isn't a lot of talk about cellular automata for general purpose programming here, but I think in some domains it'd be worth exploring
I wanted to pitch\prototype a cellular automata based VR programming environment (basically a hybrid of MFM and Minecraft redstone), but it seemed too radical, getting to the system I've implemented now has required hours of meetings and 100s of pages of documentations with engineering managers and directors, so I gave up even bringing up more "radical" ideas
g
hes such a clear speaker!

https://youtu.be/7hwO8Q_TyCA

here's an interesting pro-bubble sort argument he makes based on when you interact with basically buggy systems — I think this attitude in general is a really interesting take on how to build systems when you can't write other people's type systems for them lol
s
didn't help that in 3D occlusion is a major problem (although it could be 2.5D or 2D) and none of the environments I was targeting were voxel or grid based
g
it's interesting that when error is guaranteed you lean towards systems that can be explained visually, are interactive, etc. I think this might represent a generalization of the inventing the future thesis: where Bret Victor does great designs for systems where humans can't fit a whole compiler in their head, you can fix human errors by breaking computation out and representing it in smaller, more visual and interactive pieces. if you generalize that to errors can come from anywhere (including hardware) you end up with these cellular systems. also reminds me of goal-directed programming and Alan Kay talking about programs that can "communicate with aliens"
from the design system front eg with the VR environment example it seems like him working on it mostly alone has lead to way more productivity because he starts with super small pieces and just aims to figure out eg the two or three automata that could work together to sort rather than having to promise success and productivity within the next 3 years or whatever
👍 1
k
This CA model gives us a very crisp definition for glue code: anything that controls the initial placement of atoms is glue code.
g
for the forth implementation I suspect you'd have a stack for each direction—north south east west. unclear how it would work. maybe not even a stack–just a positional register at which point I guess it wouldnt really be point free anymore. unless it was like a conceptually lazy stack that only extended 4 in any direction. OK I've convinced myself that it's worth thinking about a little harder
lol you're right about the glue code-it glues new code into the spaces (which compose your infrastructure)
this is kind of like eventual consistency for behavior instead of data now that I think about it
❤️ 1
💡 3
f
I am reminded of a post that made the case that there are two lineages to computing: realtime fire control computers for artillery, which evolved into rocketry and PIDs and so on, and mainframes, which evolved into most consumer devices we directly interact with. The former are a lot more tolerant of error by virtue of being continuous: useful when the enemy won't stop blowing holes in your ship, impacting alignment and such.
💡 6
Not sure you can run something bit-oriented on ulam exactly, short of reintroducing nand gates as discussed in the youtube comments. You could go slightly less far and represent the stack as a physically linked list of constellations of atoms, but that still seems like it's going against the intended massively distributed diffusion model, if that makes any sense.
y
Also hugely reminiscent of Core War ( https://crypto.stanford.edu/~blynn/play/redcode.html ), though the aim there (AFAIR) wasn’t actual computation, just survival and dominance. (I never actually played/wrote any Core War, but loved the idea.)
3
f
Right, I'm definitely also skeptical of the security claims: one thing that "consistency" buys you is clear security boundaries, while at first glance networking a ulam system seems like it would render it susceptible to griefing. The obvious solution there is "well then don't let any random atoms wander into your chip", which raises the question of out-of-band control over what "colors" of particles are allowed to exist(and also concerns like substrate resets); I can imagine some cute interfaces based on assembling arcane sigils which could limit the degree to which this is out of band, but it still feels like a layer violation.
y
But that sounds like it’s in keeping with the overall philosophy: you can’t passively assume any level of reliability about the system, including security boundaries. You have to actively defend. In forcing you to do that work, you end up with a system that may be more secure than one with supposedly-solid security boundaries which falls apart once holes are discovered.
I say “_may_” there because it also forces every programmer working at this level to rewrite security & reliability features for every project, rather than relying on existing components that gain maturity and thus trustworthiness.
🤔 1
j
I love Dave Ackley's work and glad it's getting shared here! He is a great speaker and motivator.
f
Ah okay, I was parsing "robustness" as "robust against minor stochastic errors, will still give approximately correct results" not "robust against a motivated attacker which knows the details of the system". My intuition there is for the latter, i.e. not being exploitable by accumulating individually-inconsequential errors(micro-scale social engineering?), you need actual mathematics - conventionally cryptography. Has Dave published/filmed anything on the topic of ulaf beating determinism at security?
d
I just sent an email inviting him to this slack group, so I hope he can join us and answer that and, I'm sure, many other questions.
❤️ 4
g
on the forth front I wasn't thinking in terms of stacks as much as eliminating as many parameters as possible to emphasis function composition over function application. kind of an irrelevant obsession of mine, mostly unrelated to the primary goals of ulam
❤️ 1
I don't think Dave has published much about security as he seems to repeatedly emphasize how enormously early the theory is. in one video he presents a process (cell? actor? idk what to call them) that repeatedly forks itself being defeated by a faster-forking protector/immune cell. totally unclear how you could guarantee your defenses would fork faster than a malicious actor. seems like yo prove that you'd have to start enforcing some invariants about things that enter your chip vs things you create yourself which seems like it would open some serious holes in the theory—but I suspect there are holes in every theory, the trick is the size of the tradeoffs (in this case, unknown)
k
A hundred years from now we may well all sit around reading parchments about the enormous effort earlier generations spent on software and automatic reasoning without being able to make it trustworthy.
📜 4
g
may we all live another hundred years because the scientists were given the tools to solve climate change and aging simultaneously 😉
k
@Garth Goldwater
for the forth implementation I suspect you'd have a stack for each direction—north south east west. unclear how it would work. maybe... a conceptually lazy stack that only extended 4 in any direction.
Could separate the 96 bits of persistent storage from volatile internal storage. Imagine words to read/write to persistent storage the way Forth can currently write to memory with
@
and
!
. Internally imagine any stack capacity you like.
e
Mr. Ackley makes some great points. I agree wholeheartedly that robustness and transferability are the two most important issues in commercial software development. You want the product to work reliably, and you want it to stay reliable even after transfer from the original author to a new programmer. One can see in the big companies like Apple where the newbies are given the least desirable areas to work on like printer drivers, that each new round of OSX breaks printing for several releases, because the new guys don't realize they are breaking something with their supposedly minor fixes.
c
really interesting, thank you for sharing!
What do you think about his stance on determinism and scale?
its also interesting to see how much of his systems seems to me like a mechanism to describe constrains, at one point he speaks about degrees of an angle, its to bad that you have to describe the box in such a clumsy way
(by not using degrees that is)
maybe that is needed to get "robust-first" still I think there is improvement in the expression of this robustness
f
Answering my own question:

https://youtu.be/OP6sJfxNFDc

has some thoughts on countering fork bombs without top-down OOM killer privileges (and

https://youtu.be/YJRRu4dJnTI

has discussion on the spread patterns of computer viruses through modern systems, though not really mitigation)
💡 3
d
Re fyr's question about security of robust-first MFM style computation: We don't and can't offer traditional logic-based security proofs, since such proofs presume deterministic execution. And of course nearly all such proofs go poof the instant determinism fails. For program behavior generally we use statistical reasoning rather than logical, and a significant part of the MFM security story is about avoiding low level universal programmability. We make a big distinction between the 'laws of physics' underlying the cellular automata level, and anything programmed using those laws. The laws of physics are expected to change slowly at best -- in a fully mature system in fact they would be burned in hardware and optimized nine ways to Sunday. For research purposes, the T2 tile does support modifiable physics, and it totally uses conventional crypto to harden that update path as best it can. One totally can implement universal computation at and above the CA level, but that's all necessarily within the 'vetted' physics.
Re fyr's comment on the two lineages of computing: Yes exactly! A good way to think of this 'computational stack redesign exercise' is as bringing real time dynamical system control principles to modifiable, programmable, 'cognitive' systems.
Re Garth Goldwater's thought about inherent error->visual explanations. I think the key link is physically spatialized computations. You share work with your spatial neighbors, you ask your neighbors to cover for you when things go wrong, and so forth. RAM destroyed space, that's it convenience and it's sin. Respatializing computation is a basis for robustness AND visualization.
Re fyr comment about network griefing: At the moment the T2 tiles are designed not even to connect at the CA level unless they're using the same laws of physics. So fork bombs, say, can't come from up the net unless they were already possible locally.
👍 2
f
Ah okay, so "laws of physics" includes not only the rules of the MFM, but also the code of allowed atoms; are novel atoms not expected to be frequently useful?
d
The goal is to get to useful and novel constellations / molecules made of existing elements. And changing laws of physics -- aka 'magic' -- would be an increasingly rare event.
g
ah I get it a lot better now I think—if infinite scalability imposes a spatial constraint (eg, you only have the chips that are "close" to you) then spatial feedback falls out. it's amazing to have you here Dave! feels like there are few spaces on the net where you can talk directly to the person who invented the thing you're thinking about
k
I didn't follow your comment, @Garth Goldwater.
g
trying to type an explanation but almost certain there's a video that explains it better so poking around YouTube
👍 1
incidentally @Dave Ackley what do you use for presentation software? I feel like your videos end up having a super conversational feel as a result of their style
or video editing—unclear
still looking but this is my late night explanation so far (probably not fully helpful): if you are serious about being able to scale a system indefinitely, you run into synchronization problems. you can think of this as like the asynchrony introduced when you start having multiple servers in multiple physical places. physical constraints mean you have latency, and so you can only reconstruct an artificial notion of absolute time by having some kind of reconciliation mechanism that resolves things like timing by way of a construction which is a leaky abstraction. so instead what you need is some form of relative time. that means you don't have a universal clock anywhere. you can't ask "what happened after 8:05 AM?" so you have to start asking your neighbors whether they observed you doing something after you observed them doing something. and if you need to ask neighbors, you need to know who your neighbors are, which is a spatial question so then instead of asking a traditional stepping debugger question like "which function created this value?" you have to ask questions like "which neighbor gave me this value? and why?" and the "and why" part of that question boils down to "well MY neighbor told me this value and I transformed it this way" and then chasing that value down becomes a spatial question and it's clear your tools will have to display data that way
I may wake up tomorrow and be certain I came off as a crazy person for explaining it that way
also I'm on my phone so sensible edits like "is this paragraph clear?" are like 10x as hard for me at the moment
d
@Garth Goldwater Java + ffmpeg for screen cap + kdenlive to composite in post.
d
And those expanding little icons near the text?
And how did you implement the card sorter? 😊
d
More Java? Not 100% certain which expanding little icons..
d
Some image I think, it was an inch across then expanded and then went back again
d
Ah yeah, just more Java.
d
Nice
They're very watchable videos!
👍 4
d
Thanks!
a
Hi there! Love this thread. @Dave Ackley mentioned this slack on today's T2 Tile update and wanted to have a look. I've been following his work for a while and have created a web-based version of an MFM simulator. You can find it at https://mfm.rocks and https://github.com/walpolea/MFM-JS/. Development happens in fits and starts, but if there are any web-folk interested in hacking on it, would be happy to have you! The eventual goal is to provide a hands-on way to expose folks to the MFM, by being able to write elements and deploy them at runtime, possibly save and share them as well. But for now there are just a bunch of my own element experiments up there.
👏 5
1
❤️ 3
j
@Andrew Walpole fantastic work, I had no idea this existed!
👍 1
f
I suppose I should also mention that this project, or rather its previous Illuminatio X Machina form factor, has inspired me to get a pile of sub-$1 arduinoish development boards to see if I could network together something interesting. (Now as a software guy, "network" here refers to "solder together gpio pins pairwise" - I'm sure it'll be noisy as all tarnation but hopefully a few kilobits can squeeze through). The nominal goal is to reach T2 ULAM parity(in the current 60*40 configuration, 1 atom updating 20x/second per 5¢ BOM) without half a year of lead time designing and assembling PCBs - I don't expect to meet it exactly but I'll sure learn a lot about UARTs and the like!
👏 3
k
A friend of mine has been ploughing through all the videos and surfaced this amazing one:

https://www.youtube.com/watch?v=XkSXERxucPc

. Paper: https://www.cs.unm.edu/~ackley/papers/paper_tsmall1_11_24.pdf
😮 1
🤯 1
👍 1
Key figure from the paper.
s
That example really sold me on MFM
k
Interesting corollary: cars don't route themselves. Sidewalks route cars.
This is a more strident introduction:

https://www.youtube.com/watch?v=W7qMZtta9to

. I like it. Bottom up engineering: when you have intention but don't have a way to specify it directly.
👍 1
c
Indeed this talk is too good to be ignored
👍 1
I don't know how to proceed from here but we are now at ~ 60 answers in this thread, could someone (@stevekrouse? ) please create a permanent public "robust-computing" channel?
✔️ 1
funnyly enough Dave mentions the exact same reference ( von neumann) in the above talk