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
In a functional logic language, an expression can produce zero, one, or multiple values. If it produces zero values, we might say it fails. If it produces one value, we say it succeeds. If it produces multiple values, it's kind of providing a set of values you could iterate over.
And so there are a bunch of features in today's programming languages that were defined in an ad hoc way without really thinking this through, this zero, one, or many values way. And that's the problem that functional logic languages address. The most basic example is an if statement in a programming language. If some condition holds, then do this thing. Otherwise, do that thing.
And in the language today, this is done with variables of type Boolean or expressions that produce Booleans. We have Boolean variables that are either true or false. We have expressions that evaluate to Booleans. And so you can express a condition as a bunch of these features together But you've lost any computation you've done in doing that Boolean expression evaluation.
So in a functional logic language, your condition wouldn't do that. It would either succeed and produce a value, or it would fail. If it succeeds, it goes to the then branch. Your operation succeeded, now you're running this one batch of code. And if your expression failed, then you go to the else branch.
But the exciting thing about that is your expression that succeeds or fails can produce values and bind variables that are then accessed by the then branch. So you can write a conditional where you can only get to the inside of the condition, the then, if a bunch of variables have successfully been bound to variables.
So it lets you test if some conditions hold and then use the results of those tests. And that gives you a much higher level of reliability. And then a for loop... In a traditional language, it's just a bunch of imperative code that's woven together to produce a bunch of values iteratively.
It's rather awkward to do complicated things in for loops, and so you often end up with the ever more complicated constructs built to work around that, like iterators and other things. The idea of functional logic languages is your for loop can just produce... multiple values.
And if it produces zero values, you got to reiterate zero iterations, and it produces a bunch of values, you got to do all those as your iterations.
Rather than having a bunch of nested loops, you can write arbitrary things that look like SQL queries in a condition or in a for loop that bind a bunch of variables, do a bunch of tests, produce a bunch of a series of results, and in some order that you're iterating over, and then you can handle all of them and produce result.
So you kind of gain the power of SQL queries, you know, large complex queries over data structures in a language that is much simpler in which your code is just performing simple iterative operations. And so kind of gives you the best of databases and of regular programming in a much more uniform way. And the power of this is now users can write functions that not only
produce a value, you can write functions that might fail. And so you can write a function that answers a question, the answer can be either yes, and my value is this or no. And you can combine these together into arbitrary And I feel like the funny thing is that this is not how C++ works.
And so when we have epic programmers moving over from C++ and writing their first verse code, they try to write C++ code in verse style, and it actually ends up being kind of convoluted code that's worse than good C++ or good verse. But after a few months, they get up to speed, and they're writing really awesome code that's tighter and more compact than before.
And with users who've never programmed before but are learning programming for the first time in the context of Fortnite, it's really fascinating. You see, these users are learning this kind of as... It becomes their intuition. They just assume programming works this way.
And they're writing way more advanced and interesting for loops and conditions than we're often writing internally because they've kind of grokked the core concepts.
Yeah, right. So the challenge with the metaverse is, first of all, that it's a huge base of code that's evolving over time and written by many authors. You might see every second a new module is updated somewhere, and you expect in this live, ever-running simulation that never shuts down, for everything to upgrade live in place. And so one critical component that is the ability to
release an update to something you've already published and be sure that it's backwards compatible with the one that you've already released. And that's essentially a type checking problem, checking that your new interface is backwards compatible with your old one. And that comes down to the type system of the language.
There's been a lot of very interesting research on type systems over the years, most of which hasn't ever made it into the C++ programming language, unfortunately. But you see several branches of that whole field.
One of the really interesting things that Java and C Sharp did in the early days, and then later abandoned and didn't bother update, was defining a very rigorous set of rules for if you publish a module... with one set of types today, then what changes can you make to that module for your future updates to it that don't break backwards compatibility? And that's a problem for type checking.
Say you have a function that promises to return some integer. Well, in the future, you could say that returns some natural number, because every natural number is an integer. So that's a backwards compatible change. But you can't say it returns a rational number, because some rational numbers are not integers. So the system ought to reject that kind of change.
But the much, much, much more interesting thing about type checking was the realization, it was actually made in the 1930s, that if you design a programming language type system in a very particular way, then it becomes not only useful for expressing types of variables. The traditional thing every type system does is say, like, variable X is of type integer.
Showing 421–440 of 640 · page 22 of 32
← Previous
Next →