Tim Sweeney
speaker
640 appearances
1 recordings
1 series
first heard Apr 2025
last heard Apr 2025
Tim Sweeney’s voice in public audio — every appearance, attributed to the second.
Trend
recordings per month · last 12 monthsNo recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.
Appearances
But if you design a type system in a certain way, then your types can express theorems, like mathematical theorems. You know, the Pythagorean theorem is a cool one. But one theorem you might set up in a program is like the theorem that this function takes an array of integers and returns an array of the same integers, but the result is sorted.
If you express that as a theorem and you follow this system of type theory, then you can actually require that anybody who writes that sorting function to prove that it has actually sorted its result. And so you have types or theorems, and values constructed a certain way can be proofs of those theorems.
And nowadays in mathematical literature, you see more and more theorems are being proven mechanically. Mathematicians are proving theorems in a way that is verified by computer to be a correct proof. In the old days of math, people would write down language. If you look at all of Euclid's theorems, it was just language.
It was just writing in ancient Greek to say the steps of the proof to convince the reader that the thing is true. Starting in the 1930s, mathematicians moved towards rigorous formal proofs in which there's a series of steps that can be mechanically verified. They're proving things.
And when mathematicians say they've done a computer proof of a theorem, what they really mean is they've written the program in a proof language, like Lean is a theorem prover, COQ is a theorem prover, and there are several others. It means they've written a mechanical proof in that language that a computer has checked so that... It's impossible to lie.
If you say that you've proven a thing and the computer verifies it, then it's definitely true. And this is a feature of mathematical proof languages, but it's also an idea that's making its way into programming languages gradually over time. And our aim for Verse is to be the first mainstream programming language that fully adopts that approach and that technique.
And not only adopts it, but it adopts it in a way that's really user-friendly, so you don't have to do that. And the idea of this is that you want gradually more information to be incorporated in the types of variables. The property you want of a programming language is that if your compiler accepts your program and doesn't beep and tell you there is an error, then your program should work.
Now, there are all kinds of ways humans can make mistakes there, so that we'll never achieve that ideal. But we can get closer and closer to it by having more and more language features that enable the compiler to catch more human coding errors and tell the user what went wrong. And that becomes extremely important in the metaverse.
The cost of fixing a bug that's made it through to runtime and is in users' hands, the cost of fixing a bug in a shipping program is hundreds of times higher than fixing a bug that you've just observed as you're running your code yourself. When it's running on your computer, you just fix a line of code, and your bug's fixed. When you have to fix it live, you have to release a patch.
You have to release patch notes. You have to test the patch. You have to check for all the other bugs that might have been introduced, and everything becomes vastly, vastly more expensive. So, you know, the real aim of the verse program and approach is to catch all of these errors at compile time and make the metaverse a very reliable place.
proving things becomes combinatorially harder as they get larger, right? And so the really important thing about this whole field is that you should be able to adopt these capabilities gradually and apply it where you really need it. Like if you're writing something like a cryptography algorithm, that's a good place to prove stuff.
If you're writing a data decompressor that's going to be used by an entire ecosystem, like proving that that doesn't overrun memory is actually really important. And a lot of the reason that security vulnerabilities happen today is because in a different language, a compiler could have caught. We're not caught in C because it just doesn't have this feature.
But yeah, we shouldn't see this as scary. Everybody working in a typed language like C or C sharp or Java is proving theorems all the time, if you have a variable of type integer and you assign some value to it, you've proven to the compiler that that value was an integer, because otherwise it would have rejected it.
And so as we add more and more advanced proofs, we'll get compositional properties falling out of our systems that are easy to use and people prefer to use.
If we might think in a future where we have AI helping us write certain kinds of code, the big problem with AI is you ask it to do something, ask you to write a fragment of code that does something, it might give you a perfectly valid fragment of code that compiles but does the wrong thing.
And if we had languages where you could say, write a function that sorts this array and prove that it did that, it could actually write the proof. And If the compiler didn't beep with it, you could trust that it was actually sorting the array. And otherwise, you could go back to the AI and say, well, that didn't work.
But getting to the point where we know that our programs do what we say they're going to do or think they're going to do is a very important thing.
That's right. This is a result from the 1930s. It's one of the most important results of computer science that almost nobody knows about. But they did this rigorous breakdown of type systems and the 1930s formulation of programming and established that everything you can prove in mathematical logic, you can prove within a type system if it has certain features.
And, you know, if you break down what is a proof, well, a proof that integers exist is some integer. Like five is a proof that integers exist. So when you have, you know, something like var xint and you say x equals five, well, you're proving to the compiler that five is an integer. You know, that comes as a secondhand nature, but you can prove more advanced things.
If you want to prove that a pair of things are true, like theorem A is true and theorem B is true, then you need to provide a pair of values, one that proves theorem A and one that proves theorem B. And that's the conjunctive law of proofs. And there's a disjunctive law, too. And then there's an implication law for proofs. And it turns out that that's really satisfied by functions.
Showing 441–460 of 640 · page 23 of 32
← Previous
Next →