Awesome talk. Two of the best highlights to me are starting with the conclusion and the comparison slide at 11:47. Rich and simple and straight to the point and easy to intake and comprehend and hopefully sink in.
That was a great talk, as usual... :) I'm a computer science student from Brazil, and i'm a huge fan of your work... i hope to see it grow as a new standard for computation... cheers...
This is awesome, of course. I've seen the earlier videos demoing this stuff too. Sorry this wasn't around when we worked together back in the early naughts. My question here is, have you proven that this approach can, in fact, solve any required computation? Sure, it'll be robust, but is it actually Turing Complete? Do you know for a fact that it can, oh say, calculate a Fourier Transform of a signal, robustness aside, speed aside precision or accuracy aside. Do you know that it can even approximate the process of calculating an FT -- or a compression algorithm, or factoring, or whatever. How do w know, in advance, that any computation is somehow achievable? Second, do you have any thoughts on how we would go about designing complex algorithms in this system? You've shown examples of sorting, and here you showed a message switch. Do you have a "method" for constructing any arbitrary algorithm that might be requested? Great talk. Always nice to see how this work is progressing. Cheers!
+Keith Wiley This machine can simulate other Turing-complete automata (such as Rule 110), so therefore it is. I've been thinking about your second point for over a year now, and I'm not sure it's possible.
+Keith Wiley, +ajzaf : Thanks for the comments. Even if one puts 'robustness aside' (thus, of course, defeating the WHOLE POINT, grrr) --- the MFM is still asynchronous. So to ensure the MFM is mired in the Turing tarpit, one could start with a Nakamura/Toffoli/Nehaniv synchronization overlay, and then do GoL, Rule 110 or whatever pitifully fragile deterministic model one likes on top. Of course, since site transitions are actually only best-effort, and the synchronous layer locks up _everywhere_ at the first fault _anywhere_, this result is kind of worse than useless, but that's theory for you.
+Dave Ackley Yeah. I know. I'm totally on board with the robust approach. I was just curious if one could prove its generality, aside from all other considerations. Cool. Good luck!
Where are you know in the development of the robust first systems, what obstacles do you face ? Maybe, instead of doing those real life lectures you should do some inside videos more ?) i would really like to see more of the job you do, I am just a beginner in programming though I watch this, maybe you shouldn't teach an old dog a new thick, but rather find some young dogs, that know little to nothing?) once again, I appreciate what you do, keep it on.
+Robert Golosynsky It's still the early days. Could really use that rare programmer who's so thoroughly mastered deterministic computing they're looking to venture beyond it. But you're also right: Building teaching materials and a new generation is key for the long run --- just not enough hours in the day!
Great talk, love the idea. But what do you mean there is no global clock.. they all have to work in a same frequency right, if one is fasterthat one procesor will ussualy work same as the others, or others wouldnt be capable of reciving a new program.
+Djordje Mladenovic Thanks! Each tile has its own clock; there's no attempt to synchronize all clocks globally. Tiles interact pairwise by sending messages.
Thanks for the response! Quick question about security. I understand the basics of how this system would be less vulnerable and "trusting," however I think you should make a video that explains the explicit security advantages of robust-first and how it would be implemented in a network. I understand that because the ecosystem (particular ratio of "stuff") and physiology (particular configuration of that stuff) are going to be unique at any given time it would be basically impossible to purpose engineer exploits. How would such a system network with other systems and establish "trust," or do we need to rethink the idea of network "trust" altogether? This might be too much to answer in comments, but I would love to see a video on this topic!
+Joseph Thomason Indeed a 'security story' video is needed. There are no guarantees, but I see at least three key elements, and uniqueness or unpredictability, just as you say, is a big one. Another is redundancy: Trying to mess with results, say, by corrupting one demon horde sorter won't get very far with the rest of the horde covering. And the third one is locality: With no CPU and no global program counter to divert, the attacker's leverage is vastly reduced, and 'application level' attacks will have to go site by site and tile by tile. Thanks for the comments!
