History of Science and Technology Q&A (August 21, 2024)

Hello there. Welcome to another episode of Q and A about history of science and technology. Let's see. I see a bunch of questions saved up here. You know, I've been sort of thinking a bit about history for a couple of reasons. One, because I'm in the middle of a big history project which I'll perhaps described to you. And the other because I have a big birthday coming up. And I realized that five years ago on my birthday. I kind of talked about things that I was planning to do and so on. And actually things have worked out vastly better than I ever expected. It's really kind of cool. Sort of probably most productive five years of my life, at least. But I was thinking of writing something about that. And that led me to try and write a little bit about the history of how the things that I've done in the last five years have come to be done. Because it's sort of a big tower of circumstances that have made it possible to do these things. And I was kind of thinking through some of my own history of why was this possible, why did I think of doing this, et cetera. And one of the things that's really striking to me is how much of a kind of detective challenge it is to figure those things out. And I've done a lot of history of other people. And I've occasionally tried to write some history of my own efforts. But it's always remarkable that you live through these things and you just do what you do. And you don't realize, oh, the reason I was able to do that is because I had done this other thing 10 years earlier. Or because these tools that I had had been built to this point and so on. And so I've been really, really struck by the fact that as I always find with writing kind of scientific biography kinds of things. Often the kind of storybook ver is, oh, on this particular day an apple fell on somebody's head and they figured everything out. Well, it never is that way. There's usually a 10 year kind of prodrome, a 10 year buildup to that point where you're really trying to sort of. Where sort of the conceptual framework is being built. A lot of technical capabilities are being built. And then maybe finally there's an aha moment when things really come together. And when you really understand how you can explain some particular phenomenon or whatever else. But it's quite striking when you're actually living through these things. That it's just like, well, you do the next thing, you take the next step, et cetera. It's not obvious what these sort of bigger arcs of progress look like. And so I was having sort of an interesting time trying to track some of those down. I mean, I'll give you a few examples from my own life that are sort of examples of things that, in a sense, things just happened as they happened. And it was only decades later that I kind of understood something about why they were able to happen that way. Give you one example, When I started studying kind of simple programs and kind of the computational universe of possible programs and really thinking about sort of the computational paradigm for understanding nature, that was the beginning of the 1980s. And I had. Before that, I'd been doing particle physics and cosmology and so on. And I'd been doing it in sort of a fairly traditional way of doing physics, which was, the world is as it is, and it is up to us to kind of reverse engineer that and figure out the elements from which it's built. That was kind of the mode of doing physics that I was operating in. Well, then when I came to start studying sort of the computational universe of possible programs, the mode of doing that kind of science is different. It has to do with let's enumerate all these possible programs and see what they do, rather than let's take what nature has dealt us and try and sort of reverse engineer what programs were being used by nature. So the question is, how did I come to have that approach? Because it was very different from the approach that one would have usually in natural science or in physics or whatever. And I realized, well, actually, there was an important piece of personal biography, which was that in late 1979, I kind of started working on this system called SMP, which is a forerunner of Mathematica or Morphin language, my first big computer system. And in building a computer system, you're doing the opposite from what you do in natural science. In natural science, you start from nature and you kind of try and drill down and find the elements in building kind of a computer language, computational system, whatever. You're starting with these primitive elements that you just invent, and then from that you're building things up, and then you hope that people can do good things with that. So it's very much a synthesis rather than analysis kind of approach to building things up. And I realized many years after the fact that that's sort of why it was kind of obvious to me, yes, you can just build programs and see what they do, rather than you have to take what nature gives you and sort of analyze from there and so the fact that sort of I had the idea of let's just enumerate cellular automata, see what they do, was really a consequence of the fact that I'd spent several years right before that sort of building this computer language, by the way, in terms of building that computer language. That was again, something where what I ended up doing in building what's now sort of emerged into Wolfram language decades later, is sort of a different approach from thinking about how to build a computer language, what I would now think of as a computational language than people had had before. And my different approach had to do with saying, let's take the computations people might think about doing and, and let's imagine sort of drilling down from there to see what the fundamental elements are. Now, that's not something that people would usually think of doing when you're sort of engineering a computer language. Why did I think of doing that? Well, because I just spent a bunch of years doing physics where that's the methodology where you're trying to find the elementary particles, the atoms, the constituents and so on. So that was the obvious thing for me to do when it came to studying something computational like that. So in any case, I could go through many of these and perhaps if people are interested, I can of sort of. How did it end up being the case that, yes, I thought of doing this? Well, it wasn't just because I was able to be incredibly creative and so on. It was because there was a whole chain of things that happened. Sometimes those things happen for very practical reasons. I mean, sometimes in more recent times, I don't know, the fact that we had developed kind of good graph theoretic capabilities in Wolfram language was an important piece of what led it to be possible to do things like our physics project that deeply depends on kind of all sorts of things with hypergraphy, writing and so on. That was the fact that that was something that one could sort of effortlessly do was a result of the fact that a decade earlier we had built a bunch of capability in Wolfram language for doing graph theoretic kinds of things. But there are just so many of these things. I mean, one thing I've been really struck by recently, I've just been working on kind of the foundations of machine learning. And I've been studying some very simple models that sort of seem to capture the essence of machine learning. And what's a bit shocking about them is that I studied models incredibly close to these in 1985, and it wasn't like the questions I was asking there were really that different from the questions I'm asking today. But I didn't make the right conclusions in 1985. I wasn't able to get very far with these questions. They're questions about sort of why is machine learning possible? And so on. It wasn't called machine learning yet in those days, but there were neural nets and so on in those days. And I had sort of a simplified model of these things, as I do now. And the thing is, what sort of changed in that period of time is sort of intuition that I got from doing very practical things with neural nets and machine learning and so on, and the fact that I've been fairly deeply involved in actually making use of machine learning and AI and so on and building sort of things into our computational language based on that, writing books about how ChatGPT works, things like this. But that's what sort of has led me to the point where my intuition has developed so that I can go back to what I almost did in 1985 and actually figure out how to make it work and actually realize that I should push hard enough to get over various bumps because my intuition said it's going to work in some way. So it's something where again, the reason that was possible was because I'd been involved in very practical things with machine learning and AI and so on, which. And if it's sort of in a straight line from the theory to the theory, I don't think one would have got there. Let's see. Gosh, there are a couple of questions here that relate to what I was just saying and maybe I'll say a few more things and then come to some of the other questions that were saved up here. Test is asking, was SMP or Mathematica inspired by lisp? What are the pros and cons of Lisp like languages? I think I've talked about this before, actually. So when I started building SMP in 1979, I was certainly very well aware of LISP. And in fact, several systems that I'd used that were sort of experimental computer algebra systems and so on were written in lisp. Some were written in quite other languages. LISP had been developed by John McCarthy in the 1950s initially as a kind of theoretical language that was sort of deeply involved with lambda calculus and so on. I have to say that a number of people I know who were involved in sort of theoretical computation made all these comments. You know, John McCarthy didn't really understand lambda expressions properly when he did a list of things like this. I'm not sure how fair that is. I knew John McCarthy. We didn't always see eye to eye for reasons that I might actually explain. I think that when John McCarthy wrote a very nice paper about sort of outlining the theoretical idea of Lisp, that was in 1956, maybe seven, something eight, sometime around then, then people started actually trying to implement Lisp and originally in machine language for I think the IBM 704 computer. And that led to functions in Lisp like CAR and cutter, which are basically machine instructions on that particular machine. Well, sort of people had managed to implement a certain amount of Lisp, but it wasn't something where it was a good framework on which to build things because it was really right at the limit of what computers at the time could sort of support. And if you wanted to build something that was going to be efficient, and particularly wave one's model of computation was something that wasn't specifically, exactly the Lisp model. It wasn't going to be a good implementation framework. So one of the things that I did in SMP and now in Wolfram language and so on is the core idea is transformations on symbolic expressions. To have the notion that everything is a symbolic expression which has kind of a head and arguments. I used to call it, gosh, a projection and that was an smp and it was filters, which were what we now might call arguments, and a projector which is what we would now call the head. Is it conceptually similar to having lists in Lisp? Yeah, it is. Although our functions are not, if you looked at the internal in memory version of them, they're not linked lists, they're just blobs of memory, essentially arrays. And this idea of everything sort of has a head is a useful idea. The lists in Wolfram language are just functions whose head is the object list. And that turns out to be a pretty powerful way to think about things. It's very helpful to always sort of have this head which sort of has its own. Can have its own structure. It can have its own sort of higher order structure and then these arguments. So that's sort of a bit different from the way that Lisp sort of presents itself and the way that the pattern matching mechanism of SMP and now Wolfram language is really different. I say it's different, but in the end all these systems are universal computation systems, so you can always write in anything. Basically the issue is which of these things gives one sort of the best conceptual clarity. Which thing is the thing that when people look at it, they understand what's going on in the best possible way. And so this idea of you have these symbolic expressions, they have these heads and arguments and so on, sometimes they're formatted in special ways. And then you say what's going on in the language is a transformation of symbolic expressions that look like this to symbolic expressions that look like that. That turns out to be a very intuitive way for people to think about things. And I came up with that kind of way of doing things back in 1979, and I sort of based it on my simplification of what had been done in mathematical logic and term rewriting in the 1920s, 1930s and so on. And although a lot of that gets very ornate and things like combinators that I certainly knew about at that time have sort of were invented in 1920 and are still hard to understand 104 years later. So it's, you know, my effort was to try and make a human understandable version of that. That would be something that would be sort of the natural thing on which to build our computational language. And I think it's worked, actually, I have to say, spectacularly well. I mean, I would not, if you'd asked me back in 1979, is this going to work so well, I would have given arguments for why this was a reasonable way to do things, but I certainly couldn't have explained why it would work as well as it has as we've gone. And first we were thinking about mathematical expressions, programs, later on, kind of notebook documents, graphical user interfaces, all these different kinds of things that can all be very nicely represented as these symbolic expressions and transformations on symbolic expressions. The emphasis of Lisp is different. It's all about lists. It's all about certain operations on lists and so on. And certainly in Wolfram language we have those operations, and those operations were sometimes even in name, inspired by the ones in Lisp. But it's kind of not the whole story, and it's not kind of the main focal point of how one thinks about kind of structures in Wolfram language. I mean, for me, another language that was an important sort of data point was apl. That is an array processing language, a very elegant language, not particularly successfully practically deployed, not least because in the 60s, for example, it had the idea of sort of making a notation for computation and inventing a bunch of actual notation, like weird triangles with bars through them and so on, as sort of the. This is the new plus sign, so to speak, but representing computation, that was a mistake. What we've been able to do in Wolfram language, where we have kind of English words to represent kind of the primitive operations is much more successful because it kind of keys into what people already know about. Now I have to say, even when we were first building smp, SMP had very short command names. And that was an important thing because back in 1980, 1981, the typical techie person didn't know how to type and so didn't know how to type with 10 fingers. And so it was something that was, I shouldn't say techie person, the typical sort of scientist type person didn't know that they were handwriting out papers and people were typing them for them and things like that on typewriter. And so typing wasn't a thing people knew about. So it was actually important. And there wasn't anything like autocomplete. And so it was important that you don't have to hit too many keys to get that command in. That became much less important by 1988 when we were releasing Mathematica. And I realized that the value of being able to read the code so far exceeded the extra time to type it when you typed it in. That one should never go with this kind of sort of make everything short like UNIX type thing. So just in terms of the history, when I came to write smp, I was sort of a question what language is going to be implanted in. And Lisp was a possibility. There was this newfangled language on the block which was C, which had been used by, in the Unix operating system, the implementation of the Unix operating system. And one person who was a big enthusiast was a person who was a student with me, actually worked with me, named Rob pike. And this was at Caltech in probably. When was that? Probably 1978, 1979. And Rob was a big enthusiast of C and I think he was one of the important people who sort of convinced me, yeah, pay attention to C. Now subsequently, actually partly at my encouragement, Rob went off to work at Bell Labs, did many things, wrote a well known book about C, Kernighan and Pike, then went off and did another language called GO more recently. But in any case that was sort of. I was primed to know about C. And at the time most kind of sort of everyday scientific computational work was done in Fortran. Fortran would have been a horrifying choice to write smp. Fortran, for example, didn't have recursion at the time and Fortran didn't have lots of things that one really needed to have sort of clean implementation. And C did. And the Lisp was just not practical because the things we wanted to implement were kind of this new idea for how to think about computation. And Lisp had its idea and even that hadn't been implemented very solidly. In fact, at the time there were two companies, lmi, Lisp Machine Incorporated and another company called Symbolics, which were both trying to really get Lisp to be mainstream, useful. And the way they were doing it was they were building machines that were, from the hardware, were hardware constructed to be able to run Lisp. And so that meant that if one was thinking about, oh, well, let's run Lisp efficiently, well, it was really a question of, well, then you had to buy this hardware and that was expensive and it was complicated and you couldn't do it on a general purpose computer, et cetera, et cetera, et cetera. So there wasn't a lot of choice. John McCarthy was not happy because John McCarthy had seen LISP as being kind of the language for artificial intelligence. And at the time, 1979, something like SMP, that was doing things like mathematical symbolic computation and so on, was sort of the quintessential example of an AI thing of its time. I'm not sure we necessarily call it AI today. The meaning of the term has shifted a bit. The term AI had been invented actually by John McCarthy in 1956. But John McCarthy was, I don't think he ever forgave me for the fact that SMP was not written in Lisp because he saw that as sort of a denunciation of Lisp as the only language, so to speak, for quotes, AI. Now, at the time, going into that, the early 1980s was the time of expert systems, the time when people believed kind of AI would happen through having these sort of rule based systems. By the way, the kind of symbolic transformation rules that I'd come up with were very independent of that sort of tradition of expert systems. Although expert systems could have used the stuff I came up with a lot better than they did. The expert systems tradition was a bit shrouded in mystery. I mean, there were sort of these companies that had, yes, we can make an expert system and it all happens sort of behind the scenes. The company that I originally started, originally called Computer Mathematics Corporation, eventually merged into a company that was eventually called Inference Corporation, one of whose big objectives was sort of AI. Any way you do it, this is 1982 or something, and expert systems were a big thing. And the other folks involved with the company were very keen to build sort of an expert system shell, which I have to admit I never understood. It just always seemed like a Terrible design and, you know, just a lot of hackery. And I didn't understand, you know, I didn't understand sort of the bigger picture of it. And perhaps, you know, by, by that point, the, the, the, the kind of business history of that company was such that I was kind of going off and going back to doing basic science and so on. And the company, many years later, went public in a rather undistinguished ipo, but that's a different story. But in any case, in those days, I think even the, now that I think about it, even those expert system shells were not written in Lisp, I think mostly. So I think this, even at that time, with the sort of expert systems tradition, it wasn't a story of that being used. Now, you know, the lambda expressions, things like this, you know, these are all kind of a fine piece of sort of the structure of computation. I'm not sure that they are the best and only thing to use for humans to understand computation. I'll tell you one thing about Wolfram language. So people start using it, they do all kinds of things with it. It has 7,000 functions in it. They start learning some of those. It's kind of like a big vocabulary, but they work in a very consistent way. That's been kind of the big effort of my life over the last four decades, has been trying to make that consistency of design. So here's an interesting fact that we have this thing, the function function, which is essentially a lambda expression. That is the kind of the core thing that would be something that you would use in something like Lisp and so on. And here's an interesting thing. When people start using Wolfram language, they don't understand that at first. In fact, it takes a while using just, hey, here's a function. I can use it, I can use it, I can use this thing, et cetera, et cetera, et cetera, before eventually you can get them to say, wait a minute, you are doing things which we've much more efficiently done. If you were to use this function function, maybe you should understand how pure functions work. And finally then they understand it, having seen a great many examples that don't require that sort of level of abstraction. And so I think, as I think about it, one of the things in a language like Lisp is it's kind of like you've got to understand that immediately. And I think that's difficult for people. And I think that that means that sort of a while the core ideas are elegant and relevant, that means that there's sort of A barrier to being able to understand that, which I would like to think we've very successfully kind of broken down. And by the way, as we built WolframAlpha, which is natural language understanding on top of Wolfram language, and as we now have LLMs and so on, able to write Wolfram language, we've sort of broken down that barrier even more. Let's see, Let's see. There's a question here about Carl Hewitt's actor model, and I really don't know enough about it. So let's see. Gosh, gosh, gosh. Many different questions. Mathematical musing gospel. Is the decision to have Mathematica untyped, unlike something like proof checkers like Lean, a good decision for usability, or would I do it differently today? Oh, my gosh, I would do it exactly the same today. It is exactly the right decision. And every time I'm exposed to things that are heavily typed, I'm like, oh, my gosh, this is horrible. Now, I have to say, if you, you know, when people think about things, yes. They sometimes need to know what kind of a thing it is. That's what's represented by the head of a symbolic expression. But you don't have to be locked into. There's only one thing you can do with the expression of this type. You can just make it be something where the head of the expression is part of the pattern. You define for what transformations can happen on that expression, and maybe you want to abuse it and do something a bit different from what sort of you originally imagined when you kind of set out, oh, there's going to be this kind of head for this expression. So sort of the flexibility and coherence that you can get by having the. Not having sort of the rigidity of. It's got to be this type. It's that type or nothing is fantastic. I mean, it is really a critical conceptual piece of the whole story of being able to do sort of smooth symbolic expression manipulation. Now, you know, when you look at the compiler for Wolfram language, it's got to fit itself into the particular things that the hardware of computers support, like integers, real numbers, 32 bit real numbers, 64 bit real numbers, et cetera. And so it has type specifications and you can kind of decorate code, a Wolfram language code with typed specifications. It's kind of a mess. Some of that we can do automatically. More and more of that we can do automatically. And, but. And that's what you need in order to kind of be able to as efficiently as possible kind of stuff. It into the raw hardware that exists. But it is definitely a decoration, a constraint and something kind of annoying to work with now, you know, when it comes to sort of a system where one of the proof checkers, for example, those are not. I mean, if you just want to get your work done, that's not the thing to use. The thing you want to use, I hope our computational language system, Wolfram language, just go through and I want to compute this, I want to get the answer, I want to figure it out, I want to build this thing, I want to do something that's that flow of work that's different from the flow of work that says, I'm trying to make this chain of validatable things that gives this answer. That's a different type of work. Now, actually, there's an interesting history to this because the beginning of the 20th century there had been sort of this wave of formalization that had happened starting in the 1830s with people before that time had thought of math as just sort of a description of the world. And it's obvious, oh, you can have addition, subtraction powers. These are all things that sort of in some sense apply to things in the world. Then in the 1830s, things started to happen that were sort of generalizing that idea. There were several things came at similar times. I mean, there was Lobachevsky's idea of curved space. Space that wasn't Euclidean, didn't have the same sort of structure that seemed like the obvious kind of. This is our experience of space type structure. There was Galois introduction of groups, group theory. It sort of is a bit like algebra and multiplication, but it's group multiplication which isn't like ordinary multiplication. Then there was Boolean algebra, George Boole kind of saying, oh, we can take logic and we can think of that as like multiplication addition, but it's got slightly different rules. And then there was also Quaternions from Hamilton, William Rowe and Hamilton, which were sort of. I think it was 1847, if I remember right. Might have that wrong. But there was where again it was they're kind of like numbers or like a sort of generalization of complex numbers, but they aren't commutative. It isn't true that X times Y is equal to Y times X always, et cetera, et cetera, et cetera. So there was sort of a generalization from the idea of math that we thought was sort of intuitive. This was a more formalized generalization of that. And that really developed quite a lot, particularly in 1870s, 1880s. People like, well, Frege Got Lob Frege, who was more a philosopher than anything else, trying to say what really is math? And you know, is math really a derivative of logic? Can you just build all of math by thinking about things in terms of logic Then? Well then there was Giuseppe Piano who tried to kind of make a really formalize what are we talking about when we talk about math? What are the axioms from which we can build everything? Euclid back in antiquity had come up with these essentially axioms for geometry. Things like two parallel lines will never meet and so on, had written down about, what is it, 10, 10 sort of common notions and things. And from that had derived about 500 theorems in his elements. And that was kind of a model for a deductive system of reasoning where you start with axioms and then you go from there. But that hadn't been done for things like arithmetic, it hadn't been done for algebra. Those were still things which were kind of like, well you know it when you see it type thing. But Peano in particular and Frege to some extent before him had tried to axiomatize these things. And Peano wrote, wrote some very elegant axiomatization. And some of our modern notation comes from Peano. It sort of didn't help his cause perhaps that he wanted to kind of have a sort of perfectly defined thing all the way down, including the textual description of what he was doing. So he invented a language called interlingua, which was kind of a little bit of a derivative of Latin, which was his own kind of invented conlang constructed language to write the description of what he was doing. And that obviously reduced its readership. But then there had also been sort of a separate branch from David Hilbert. David Hilbert was a well Prussian German mathematician who had a sort of big break in being able to prove a theorem non constructively. Usually people, when they will prove a theorem this is true, would be able to say this is true and here's how you make a thing that works this way. But what Hilbert did was he proved a theorem where he said this is true but this theorem doesn't tell you how to make a thing like that. And so that kind of led to a more formal approach to mathematics. And Hilbert would eventually come to sort of define his program of just write down your axioms and then derive mathematics from those axioms. And he famously would say things like the axioms could be about tables and chairs and the mathematics would then be the derivation of things from those axioms. Well meanwhile, 1900 or so Bertrand Russell was, I Think he met Peano at a train station in Paris, if I remember the story correctly, right around the time when Hilbert was enunciating Hilbert's problems at the International Congress of Mathematicians in Paris there. So anyway, Peano had come up with this kind of axiomatization of mathematics or of things like arithmetic. Like Peano arithmetic, meanwhile. Well, another game in town was Georg Cantor, who had come up with set theory. And originally Cantor had been trying to do very practical things about the convergence of trigonometric theories. You take sums of sine functions, you ask the question, if you take an infinite sum of those sine functions, will it converge to a definite value or not? And he'd been trying to answer that, and he found that it was very complicated to describe in what region of values the thing would converge and not converge, and so on. And for that he ended up inventing set theory as a way to define the set of points effectively, where the thing would converge and wouldn't converge and so on. Then he very much generalized set theory and also transfinite numbers, which were deeply connected into set theory and sort of set theory. Eventually, amusingly enough, by the 1960s, although set theory had come out of this very abstruse question in mathematics, the idea of at least finite sets, if you have a set of objects, you take two sets. What's the union of objects in the sets? What's the intersection of objects in the set? These kinds of things, those were made simple enough that when the kind of new math was introduced in the early 1960s, a bunch of fancy mathematicians in the US kind of defined this is what, this is what school kids should learn when they learn basic math. Set theory made it into that. Now, some people get confused sometimes because that's the theory of finite sets, the theory of sets that have only a finite number of elements. What Cantor was very involved with was transfinite sets, sets with infinite numbers of elements and so on, and the much finer mathematical issues associated with questions about whether infinite sets contain themselves and so on. Well, anyway, Bertrand Russell, philosopher, gets all excited about sort of foundations of math and Peano's work and so on, and goes off and says, okay, I'm going to follow up. Well, he'd also been interested in Frege's work on deriving mathematics from logic, but had had sort of with triumphantly pointed out to Frege that Frege's system, Frege's sort of axiomatic system for deriving mathematics from logic had a kind of fatal flaw. It had an inconsistency and Russell was sort of all excited about that and said, we got to fix this. Why am I telling you all this? We're talking about types. I'm telling you where types came from. Types came from Russell trying to fix that particular thing by a hack. Essentially, it's, let's see, the, the issue is, is the set of all sets a member of itself? And that gets you all kinds of paradoxical issues. And in order to break out of that, you kind of have to say, well, there's a type that is the set and there's a different type that's the set of sets and so on. And you have to build this sort of hierarchy as a way of getting out of these kind of paradoxes. And that was why Russell introduced types. And it was sort of introduced as a hack. But Russell did another thing, which was he got Alfred North Whitehead, who was sort of more of a mathematician, I would say, who'd worked on this thing called universal algebra, which is sort of a generalization of all these different approaches, Boolean algebra and quaternions, all these kinds of things. Gaua work on groups and so on, sort of generalizing all of that to what was called universal algebra, which is essentially an algebra where you just write down a bunch of relations between elements and say things are put together according to these relations. You don't really discuss so much what the thing is as much as you discuss what relations there are and how they imply things and so on. So anyway, Whitehead had done that. Russell sort of recruited him to work on the grand project to construct mathematics from logic. And so they wrote these books, Principia Mathematica, three volumes, where they famously, you know, it's incredibly abstruse notation, rather bad notation in retrospect. And they famously, you know, derive that one plus one equals two by page 100 or something. A very abstruse notation. And I think that was partly kind of a yes, you can get sort of something from really low level stuff. But also it was kind of a show off thing that it took so much trouble. So it was so difficult to derive one plus one equals two. But any case, one of the things that Whitehead and Russell did wrong in a sense is they sort of imagined that what they were doing was modeling what mathematicians do, but they really weren't. They were making this kind of axiomatic system a bit like a proof checker. They were imagining that what mathematics consists of is kind of axiomatically writing down proofs. That's not what practical mathematics, as mathematicians, most mathematicians practice it that's not normally what they do. It's more kind of intuition from this structure maps onto this structure and you see these kind of correspondences and so on. And then maybe you have to go in and sort of do the paperwork, so to speak, and write down some sort of somewhat formalized proof. And there are cases where it's probably useful to make sure you're right by running it on a proof checker. Maybe the problem is you often get something that's kind of machine code like. And it's like, well, why is this true? And it's like one of the values of a proof, a human written proof is often it explains why it's true. You say, aha, now I understand something about the structure of this problem. It's kind of interesting when we look at WolframAlpha for example, and we have our step by step solutions, that mechanism for math and chemistry and other kinds of things, those are intended for the human to understand why this is true. And it's all kinds of work to make something which is a human narrative that explains why it's true. It's kind of interesting to feed that to AIs as well. People seem very enthusiastic about doing some of that to kind of show AIs how reasoning can be done. And just like In a sense, LLMs, I think sort of learnt logic by seeing lots of examples of logical arguments in the same way that Aristotle probably deduced logic in the same way. So one might hope that by seeing a lot of examples of kind of mathematical reasoning that that might improve kind of the general reasoning patterns of LLMs. But in any case, the thing that is, you know, this kind of idea of it's all about making proofs, well, it's mostly really not about making proofs. And for example, well, famously the one example of sort of automated theorem proving discovering something that wasn't already suspected to be true was a thing I did back in the year 2000, finding the simplest axiom system for Boolean algebra, which people had sort of been wondering about for, oh, I don't know, at least 80 years or so and a bit longer than that in some measures. But any case, I found it by doing sort of the crazy thing of just searching all possible simple axiom systems, because I'd by that point developed the intuition that there should be a really simple one, so you should be able to find it by searching. Indeed, I found it and proved it with automated theorem proving. And that proof, 100 and something steps long has remained incomprehensible to humans. So we have a proof, we know it's true, you can validate it, but it's useless. And in a sense, that's a lot of what ends up happening, is you grind down proofs to this sort of very lawyered machine code, so to speak, of kind of papering the proof, so to speak, in a proof checker. And I think that's. I mean, those things are perhaps more useful in validating things like protocols than they are in validating mathematics. I'm not sure, because I think mathematics is a bit more of a kind of human narrative understanding enterprise. But in any case, part of what's been done in the world of proof assistants and so on is to make use of the idea that types can be everything. So when Russell invented types, he invented them as a way to get out of certain paradoxes. And they were kind of just this sort of add on. Oh, yeah, there are types. And you can kind of use that to deal with sort of these corner cases and such. Like, I mean, famously, when Godel wrote Godel's theorem in 1931, he was kind of trying to wonder how human minds might not be subject to the limitations that he enunciated in Godel's Theorem. And he has this bizarre footnote where he talks about how maybe in the case of human minds, we have this whole hierarchy of types ramified into the transfinite that will sort of escape the constraints of Godel's Theorem on sort of the ability to figure things out that were implied for sort of the ordinary types, so to speak. So he was kind of using types as an escape valve, at least ramified into the transfinite as an escape valve, away from kind of what one would do with sort of ordinary axiomatic systems. But types kind of languished as this sort of somewhat obscure thing. They came into the use in computer systems. But because when people built computer hardware, they wanted to do things like have a register that would have an operation, an opcode, an instruction that would operate on integers, another one that would operate on real numbers, and so on. And so when you wrote programs, let's say in Fortran or in Algol, or Algol, like languages or whatever, it was always important to know the type of that variable X because that would determine how it was stored. It would determine what opcode to use. When you say X plus X or X plus Y, if X and Y are both integers, use opcode number 17 or something. And if they're both real numbers, use opcode number 23 or something like this. A different piece of the alu of the arithmetic logic unit of your computer is what's used. So types were important there for kind of distinguishing sort of how you can make your program actually be executed in the hardware of your computer. And then to some extent, types were in retrospect also useful for sort of making sure your program was right. As in, if the types don't match, then there's obviously something wrong. If you have some function F of X and the function F of X expects X to be an integer, but you feed in this array of floating point numbers, for example, you can be pretty certain it's not going to do the right thing. Worse than that, in most low level languages it's going to put on the stack when it calls the function F this blob of stuff, and it's not even going to line up with the piece that the function F takes off the stack. So it's going to be totally broken unless the types match correctly. So that was sort of another piece is type checking as a practical way to sort of get some indication your program is not wrong. Now, a program could say it's an integer, okay, but turns out it will only work. The code will only work if it's a prime integer. But you don't have a type that says X is a prime. You say just X is an integer. That's what's useful for kind of grinding through the innards of your machine and so on. Well then, sometime, must have been 1990s, perhaps, in the sort of formal computer science world, types began to be more noticed because in particular this thing called the Curry Howard correspondence was discovered. And that was a thing that kind of related kind of the types and proofs and program execution. And essentially if you can make an elaborate enough type of just knowing that there is a thing that can be of that type is effectively a proof. And what you're saying is so called whether the type can be inhabited. That is, if you say I'm defining this thing and it's defined to be this object that has to have these properties and those properties and those properties and so on. Then if you simply ask is there a thing that has those properties? You effectively rippling through those properties and saying, can you knit those things together? And that's effectively a proof. So this idea of sort of types and proofs and programs, programs as the same kind of thing, that was an idea that I think came maybe in the early 2000s that came into real prominence and that led to, well, lots of different things, but that really led to a higher enthusiasm for sort of types as something fundamental. And in fact in mathematics, in some sense people think of mathematics as just, well, there's math and there's all these constructs like spaces and mappings between spaces and all these kinds of things. But then you've got to kind of build a computational structure around that. And types are sort of a way for. In a sense, if you start from the math, they're a way to sort of decorate it with something that's like computation. I don't think it's the right way to do it. I think it's much better to just say, okay, we're going to start with computation and build up from there. That's what I've concentrated on. Rather than let's have this sort of free floating thing that's out there and then let's start putting constraints on it to define how it works, which is more of the sort of type oriented approach. So I think in, I mean, what's happened more recently in type theory and so on is this thing called homotopy type theory, which has been closely connected to category theory. And homotopy type theory is kind of a way of thinking about the axiomatization of mathematics that's a little different as category theory is also a little bit of a different way of thinking about the axiomatization of mathematics than the kind of traditional sort of Hilbert style axiomatic structure for mathematics. And maybe I shouldn't get into this, this is sort of a different topic to talk about these types of things. But that's led to sort of a theoretical structure around types that doesn't really make them any more practically useful, but it's interesting in its own right and actually has a bunch of relations to our physics project and so on. I mean, just to say in like homotopy type theory, the key axiom is the, well, it's the axiom equivalent, what is it called? Equivalence axiom. And the key thing is that which is equivalent should be considered the same. What does that mean? It means if there are two different ways to derive something thing and they both involve sort of valid derivations, but they're different derivations. But in a sense then the things you end up with are in some sense can be viewed as the same. So if you said I've got one plus one and I've got two minus three minus one or something and they're both, you can show that they're equivalent by going by doing various steps, then you say, yes, if I can show their Equivalence then I can consider them the same. It's kind of a thing actually closely related to a bunch of ideas in my observer theory and the theory of equivalence classes and observer theory and so on. It's got a long complicated tail that goes far, far down, so to speak. Let's see. Oh gosh, so many questions here. Ah, oh my, you guys are asking such interesting questions. It's very hard to, to pick here. Harry is commenting. Type checking felt like dimensional analysis. Yeah, there's a good analogy there. I mean I think the concept of units is another interesting thing that emerged very separately from the concept of types. Types were a story of pure mathematics and so on. Units. The concept that you would sort of tag a thing with units. Well, the idea of units came from ancient Babylon actually when people started standardizing weights and measures and things like this and time. And they did that when there started to be cities and so on and people. It mattered that you could, you know, trade barley from one person to another and know that, you know, for this amount of money you were getting the same amount of barley. And it really was a standardized measure. And there's a whole infrastructure of, you know, this is a standardized weight and you compare it with this other one and it's the same and, and it kind of, you know, it sort of propagates through to know what, what the standards of, of of measurement are. That. But then the whole story of, of units and measure measures of things, it's pretty complicated. I mean back in, oh still 1700s, you know, different cities would have different kinds of inches, different, you know, how you measure apples versus oranges would be different units. The sort of volume measures for different kinds of things would be different and so on. This didn't really get standardized. I mean the metric system and Napoleon was big in pushing the metric system that sort of I think started to simplify and standardize some kinds of units and so on. But the idea that the sort of the, the. Oh well, we'll have a unit for that. We'll have a, you know, a thing that measures that thing and then how do they all interconvert? That was a quite late stage thing. So, so for example, in. Well let's see, there are about, in, in modern times there are about 10,000 kinds of units that are in common use. I know that because, because we've implemented all of them in wolframar language and we had to curate all of these things and some of the more they're very obscure units. I mean one of my favorite obscure units is the unit of moles per acre, which you might think was. You put fertilizer on a field and you're looking how many moles, how many clumps of 6 times 10 to the 23 molecules are you putting on your field? But no, it's not that. It's the number of little moles that are digging up the soil and aerating it per acre. But in any case, there are lots of kinds of units and some of them are more convertible into each other than others because moles per acre isn't terribly convertible. It's not convertible into gophers per acre or something like this. And there are plenty of scales that are really tricky to talk about. I mean, scales, I don't know, international units for, I don't know, take your vitamin D or something. It's such and such a number of international units. What does that mean? Is that a mass? Is that this? Well, it has to do with activity. And it's a kind of difficult to define thing or units of smell, for example. There are all kinds of units that are very hard to interconvert. But a large clump of units were interconvertible. And the thing, the SI system, international, pardon my French, was introduced I think in the 1950s, if I remember correctly. And that was sort of a standardization where, well, let's see, it must have been in the early part of the 20th century. People were thinking a bunch about units for electromagnetism. Electromagnetism is a particularly awkward place it comes to dealing with units because, well, there's electric charge and electric current and electric field and all these kinds of things. And there are so called rationalized units and non rationalized units. If you know, you know, if you're into the technical stuff of this, it's divergence of the electric field is 4pi rho over ε 0. Rho is the charge density. Ε 0 is this weird thing that's the permittivity of free space. It's this weird thing that really should just be a number in some sense, except that it can't be because the units don't match. And it's a big complicated shell game of where do you put this unit and that unit? And I have to say I know that system, which was the system that was kind of the modern system in the 1960s. And I learned that system. And I think if you showed me Maxwell's equations in the other system, I would just be confused. And it's, you know, I would use Wolm language to untangle it because we know about all These different systems. But it's a complicated, messy thing of where do you. What's a pure number versus what's got an ε 0 versus et cetera, et cetera, et cetera. But that whole awareness of that complexity, I think must have dated from. Must have already been known when Maxwell was writing his textbook on electromagnetism in the 1880s or so. And I think. But sort of the. The. We can put all these units together and have a certain set of base units. I think that's a thing of maybe the 1950s. And there were for a long time these two, you know, rabidly competing systems, the MKS system and the CGS system. MKS is meter kilogram second. CGS is centimeter gram second. And so in the U.S. well, by the 1970s, the U.S. was still very much a CGS country. Europe was very much an MKS country. The SI system, which originated in Europe, was an MKS case. But that all depended on the sort of standardization of what were the quantities you had to define units for mass, length, time. Okay, those are obvious. And amount of substance, electric charge, luminous intensity. You know, what are those. Some of those things, I mean, mass, length, time, those are sort of features of. Well, length and time are initially features of space. Mass through general relativity becomes a feature of space. Then there's sort of amount of substance that's counting the number of atoms. Luminous intensity, that's counting the number of photons, electric charge, that's basically counting the number of electrons. Those are other kinds of units. And the idea that those were base units, I mean, it's kind of like moles per acre. You could have a base unit of the number of moles, but that's not terribly useful. But it is useful to have a base unit of the charge on electrons or the number of atoms or something. That's the base unit that leads to the other kind of molecule. Is counting the number of atoms the thing. Then there's a question of, okay, what about sound? Are there separate units for sound? Well, in sounds, there's decibels, there's fons, there's a bunch of different things. Some units of sound are very physical. Just the pressure of the sound wave is. The overpressure of the sound wave gives you the intensity. But some units, as I recall, it's fons are units that depend on the perception of sound by humans. And that has to have an additional piece that isn't purely sort of physics. Another unit is temperature, by the way, Another base unit is temperature. That's another messy kind of unit because many units like mass, length, time and so on, you can just multiply those units together. With wild abandoned with temperature it's a bit trickier because temperature has an absolute zero. It has, it's a scale. And this idea that you can kind of multiply temperature differences and this question of when can you, you know, you have to have this absolute temperature, that's something that you can multiply, but it has to be relative to absolute zero. And so, you know, if you take a temperature in centigrade, 20 degrees centigrade, for example, good luck multiplying that by another temperature in centigrade, you can multiply temperature differences, but not temperatures and so on. Anyway, that whole story got sort of untangled when SI system got developed. That was sort of pretty untangled. Now dimensional analysis is things like, okay, let's understand something like when we have fluid flow, we say, okay, we've got a bigger, we've got our model boat and we've got our actual boat. Is there a scaling of the speed of the flow in the model boat basin or something relative to the speed of flow of the actual boat in an ocean that will cause the structure of the flow to be the same. So it turns out there's this thing called Reynolds number that was originally suggested by Oswald Reynolds in the 18, oh I don't know, 1860s, give or take. I think that was a similarity of flows. So what he said was if these flows, if the characteristic length times the velocity divided by, well, the so called kinematic viscosity, essentially how it's a combination of how much the fluid kind of dissipates sort of motion, how easily the fluid kind of runs and the density of the fluid. So he said if the Reynolds number is the same, the pattern of flow will be the same even if the size of the object is quite different. So when you see a photograph of a ship, of the wake of a ship, it can look exactly the same as a little tiny model ship that is going much more slowly. So I mean, in the end Reynolds number got understood as it's kind of the ratio of the inertial features of fluid motion that is just sort of eddies of fluid that just keep going by angular momentum versus the frictional effect of of sort of the molecules kind of dissipating sort of that motion into heat. It's the ratio of those effects is essentially the Reynolds number. But anyway, Reynolds number is an example of a dimensionless quantity that sort of dimensional analysis tells you if you've got, you know, length Speed, viscosity, density. There's only a certain combination of those quantities that you can put together to make something dimensionless, which will be the thing you would have to have if you want to compare a thing of one scale of length to a thing of another scale of length. So there are a bunch of these numbers, they're a bunch of fluid flow. What is it? Prandtl numbers, Knudsen numbers, All kinds of numbers, mostly I think dating from the 19, most of those ones I think date from the early part of the 20th century. And they discuss different aspects of. Oh, and Mach number, that's a very famous one. Mach number is the ratio of your speed to the speed of sound. So there are these things and that's sort of the story of dimensional analysis is things like if you've got these quantities then something which can only. If you have something which sort of scales with those quantities, it can only depend on this particular combination of quantities. I have to say there's a famous story of a person called GI Taylor, well known British fluid dynamicist who was involved with the Manhattan Project. And one of the big questions when the first bomb test was being done was if you ignite a nuclear explosion in the Earth's atmosphere, would it ignite the atmosphere? Would it cause a sort of chain reaction of oxidation in the atmosphere by would basically make all the oxygen in the atmosphere start to burn in effect. And clearly that would have been bad. And so the question was was that going to happen? Or not? And oh, actually. And so that was sort of all entangled with questions about could you tell sort of how intense the blast was from this or that thing? Anyway, I'm forgetting all the details of this, but GI Taylor was, was much involved in this. Would it ignite the atmosphere? And coming up with some dimensional analysis argument for why that wouldn't happen. And also in the end I think coming up with a way of estimating the actual TNT equivalent, the explosive power of the first nuclear explosion based on I guess pressure measurements and things like that with the shock wave or maybe to do with the size of, of the, of the shock front and things like this, I'm not sure. But anyway it's a, it's a, it's a nice example of kind of real time science where you know, dimensional analysis is sort of solid enough that without ever actually calculating anything by a sort of constructive theory, you're just saying the dimensions work out and so the explosion won't ignite the atmosphere and it's all good. A little bit of a gutsy thing to do, I would say, in any case. Yes. I think, I mean, dimensional analysis is a weird business. It's always sort of one of those side things that sort of is discussed in a footnote type thing. It's something where in the cases where it's useful, in the cases where the sort of units you're dealing with are disparate enough, there's only one way to fit them together to, for example, make a dimensionless quantity. It's like a magic bullet to tell you the answer. I think that's a little bit more impressive sometimes than type checking. But in any case, let's see, Let's see. Nathaniel asks, was my idea about using transformations on symbolic expressions sort of a sudden insight into, after reading Schoenfinkel, for example, or did it follow from working out sort of atoms of computation? So really what it was was I was really mostly using computation. Well, I used it to do simulation, but I also used it to do mathematical algebraic computation. And so in a sense, what I was doing was my first step was what do humans do when they do algebraic computation? And. And humans essentially make transformations on algebraic expressions. And so that was one kind of inspiration. The other one was to think about, well, what was the sort of more formalized way of doing something like that? And I knew about mathematical logic and so on. Combinators. I knew about combinators, but I did not deeply understand combinators, as I think very few people have ever deeply understood combinators. I wrote a book a couple of years ago now about combinators, and I finally felt I was sort of more or less on top of, let's say, the natural history of combinators. I can't necessarily tell you if, you know, if a combinator comes and says hello and I try to figure out, what's the combinator going to do next? I don't think I could tell you. That's not something I can run in my brain. But I certainly know now a lot about sort of the natural history of how combinators typically carry themselves, so to speak. So for me, it was sort of in part an imitation of what I saw humans doing in sort of doing mathematical style computation, in part a realization that there was sort of an idealization of that from term rewriting and so on in mathematical logic and sort of bringing those together and saying, well, what was kind of the. What was the. What was the most straightforward to describe way to do these kinds of things? And that's how I ended up with transformations on symbolic expressions. Now, when I was designing smp, I tried to do my homework and sort of talk to everybody who'd built sort of previous systems that had tried to do things like mathematical computation wasn't as useful as I'd hoped. But one person who had very definite views, I was at Caltech at this point and one person I knew quite well was Dick Feynman, well known physicist. And Dick Feynman, one of his great features was he was a great human calculator. I think that the typical sort of Feynman trick was do this incredibly complicated calculation, actually get the right answer and then say, well, why is this answer right? And come up with this kind of wonderful intuitive explanation for why it's obvious that that answer has to be right. Then not tell anybody about any of the calculation for went into getting that answer, only tell people the intuitive argument and leaving people sort of saying, wow, that intuition is amazing. How did you know it was going to work out that way? Well, he knew it was going to work out that way because he actually did the calculation. And what for me was always the most impressive was that he could get the right answer in those calculations. For him, that wasn't impressive at all. He thought that was easy. He thought the hard part was doing the intuition stuff. I always thought that was pretty easy, but the calculation was really hard. And that was kind of why I got into getting computers to do the calculation for me and getting intuition about how the computers were doing things. But anyway, Dick Feynman had many, many views about sort of how one should do calculations because he was all into doing calculations himself. I have to say that he was very big on sort of the tricks for how do you jump from here to there in a calculation which wasn't so important for the computer because the computer can be really, you know, just I'm going to do this very dumb thing and I'm just going to do it a lot of times in this very systematic way. What, what Dick Feynman was, was, was always telling me about, is, but what about this trick? What about this way of doing this? And, and it was, and I was often, well, you know, I don't think the computer will care type thing, you know, that's cool. But you know, if you don't use the trick, it's an extra 10 operations and who cares? That'll be done in microseconds, so to speak. But it was sort of interesting. That was kind of at least sort of one corner of how to think about these things was very much the human calculator. And what do human calculators do? And so on. Let's see. Mrudo asks, what is the history of lazy evaluation? That's an interesting question. Let's see if I have an answer. Okay, what is lazy evaluation? So let's say you say F of X is X squared or F of X is G of x plus H of X. In morpheme language, in the way we do things, it will be F of X blank equals or colon equals G of G of x plus H of X. Or something that the blank means. It's a pattern. You can say F of and then you can stick anything into that pattern. Okay, so the big question is, when you do that, do you. Well, okay, actually the simpler case is when you're working something out, do you say, you know, F of x is immediately G of X and that's all we have to say. Well, what about if G of X is also defined to have some value? Do we go and work out what G of X is and then work out what that is? And that is, and that is until eventually we get to something like three where there's nothing more to do, where we get to some literal thing that can't be further transformed. Do we do this kind of infinite evaluation immediately or do we just say we're going to keep it unevaluated until something happens that makes us feel like it's worth evaluating? It's sort of a continual trade off. When is it worth doing lazy evaluation, sort of waiting to evaluate things. The problem with waiting to evaluate things is you don't know what you have until you evaluate it. So for example, if you have thing A and thing B and you've got thing A minus thing B and they're both lazy, you don't know what thing A and thing B are. They might turn out to be equal, in which case you could just say, oh, thing A minus Tthing B is zero, we're done. But you don't know that if they're lazy. On the other hand, if you evaluate them eagerly, it could be the case that they're incredibly hard to evaluate. And so you could waste a lot of time evaluating them, even though in the end you don't really care what the values are because all you're going to do is take thing A minus thing B and then you're going to add thing B, for example, to that. It doesn't matter what thing B is because minus thing B plus thing B is always, you can always think of as zero, let's say. So there's these Trade offs about when do you evaluate things lazily versus eagerly and so on. Okay, so I will say a number of things about this. So sort of infinite immediate evaluation. Say X equals Y, Y equals z. Z equals 2. You type in X, what do you get? Well, in Wolfram language nsmp, you get two. In not all systems do you get two. I think in many systems you just get if X is equal to Y, you just get Y. You don't immediately go down that chain of evaluations, at least not for variables. Most systems, confusingly enough, when it comes to functions, do try and go and evaluate the whole chain. Sort of a weird, inconsistent thing. And when I was first building smp, actually, people told me in theoretical computer science told me the thing you're building is theoretically impossible. Okay, why did they say that? Well, they said, what happens if you Type X equals X plus 1? Well, it will go into an infinite loop because it will keep on saying. It will keep on using The X equals X plus 1 to generate more and more stuff. And so that never terminates. Well, in practice, it runs into some limit. It comes back as a symbolic terminated evaluation object. In any case, the reason they said that was. Well, it had to do with the confusion about lambda expressions, which maybe is not worth going into. It had to do with the fact that people imagined that when you evaluate a function that you have to temporarily bind, you have to temporarily set the value of the dummy variable inside the function to the actual value. Which means that if you feed in X +1 to a function F of X, you're making the assignment X equals x plus one. So they thought that's not really how you do it. When you do transformations for symbolic expressions. That's not at all how you think about kind of the way that you do these things. But in any case, why doesn't the X equals x plus one thing kind of blow everything up? The reason is it just doesn't come up. Yes, you can type in X equals X plus one, but it's kind of a silly thing to type in if X wasn't given a value yet. And the fact that it blows up is a corner case that just turns out not to be important. I mean, this is the long and difficult story of language design. The only language that doesn't do anything weird is a language that does nothing at all. And so you always have these corner cases, and it's a question of where do you put the corner cases? Do you make it be the case that every time you want to evaluate something, you have to go and do and run this loop and this and that and the other? Or do you make it so that things usually just evaluate and do what you expect? But there's a corner case where things go into this kind of infinite loop. So it's kind of a judgment call. And it's a judgment call that. Well, actually just recently, about that particular thing, there's the question of when you have all these loops, x equals x plus 1, x equals the list X and X these kinds of things, can you classify the kinds of infinite objects that you get? And I have this. I wrote something late last year about this, about mentioning sort of using transfinite numbers actually as a way of classifying the kinds of infinite objects you get. Actually, it's a very recent idea linking that to questions about renormalization in quantum field theory. That is kind of a way of thinking about can you get a limited number of infinities in your system? That's kind of what the idea of renormalization in quantum field theory is. Come on, do that. For expression evaluation. An interesting question just came up for me a week or so ago. In any case, the thing that. Well, okay, you're asking about history of lazy evaluation. It's a little complicated because. Let me think about this. You know, when recursive functions, lambda expressions and so on were first invented in the 1930s. Well, recursive functions have been invented a little earlier than that, but general recursive functions were invented in the 1930s. There's kind of a question of. Yeah, it's a little bit undefined whether you're dealing with, for example, for combinators, It's a little bit of a weird question. You know, you have these expressions involving combinators and you could evaluate them to a fixed point, or you could just leave them as these symbolic things. And I think it really wasn't a very well defined issue. So I think, trying to think about this, when I was designing s and P 1979, one of the things I figured out was this notion of immediate assignment versus delayed assignment, which relates to this whole. If you say X equals Y versus you say X Y, they mean different things. X equals Y means evaluate Y right now, if Y is 3, right now, set X to 3. X. Y means just remember that X is supposed to be equal to Y. And whenever you ask for the value of X, figure out what the value of Y is and return that as the value of X. So if you change the value of Y, then the value of X, if you ask for it later, will have changed. Whereas it won't in the case of immediate assignment. But for me, that was. I'm trying to think about that. I, I mean, I remember figuring that out and it was certainly not self evident how that should work. So I think kind of the notion it was certainly not, I don't think it was a well understood concept in the 1970s. It may have, but on the other hand, it was deeply related to things that had existed for a long time in kind of symbolic mathematical logic, kinds of ideas. Okay, maybe one last question then I got to go back to my, my day job there. Here, the. Let me see. Truth is asking, have you come up with new theories of human reasoning from working on Mathematica and computation? Interesting that you should ask that. I mean, to me the story of kind of thinking computationally is a story of another level of formalization of the world. Human language is in a sense of formalization of the world. You can talk about a tree abstractly rather than pointing to a specific tree. And then we have logic, which is another formalization of the world. We have mathematics, which is a formalization of the world. And we have computation and computational language, which is sort of another level of formalization of the world. And for me it's been a super useful one because I end up, I guess I'm fluent enough in this that I can start typing little pieces of orphan language code. I couldn't explain to you what I'm about to type. It's just something that comes out just like the things one says just come out, so to speak. And thinking in those terms has certainly led me to many things. I mean, things like our physics project were necessarily built on top of that kind of way of thinking about the world and way of thinking about things. There are certainly interesting questions about sort of. Is there a. I think, you know, I view sort of computational language as a firm sort of new level of way of thinking about the world. But it probably gives one sort of a platform to get even further, you know, just as we get a lot further probably than cats and dogs and sort of talking about the world. We, we have this whole language where we can put together all these different pieces and the sort of compose them in all these different ways. We, you know, whereas cats and dogs, it's kind of like fetch, sit, things like that. It's kind of single word type concepts. There is a good question which I've been thinking about recently of sort of what's the next level of abstraction beyond. You can put the words together to make sentences. And I kind of my current gloss version of this is we get to put words together. Maybe the cats and dogs only get to have individual words. We get to put words together. What we don't get to do is put paradigms together. We tend to think in some particular paradigm, some particular way of thinking. We think in those terms and then maybe we switch and we think in other terms, but we don't get to sort of put paradigms together with sort of wild abandon. I mean, in a sense, my mission with building our computational language is to make it so that these different sort of paradigms, whether it's, I don't know, functional programming, list based programming, whatever else, they somehow have seams that fit together nicely. But that's sort of a first example of a place where one's sort of trying to fit paradigms together. And I think that's kind of the, you know, that's a possible way into thinking about what would it be like if we were able to sort of think at a higher level is kind of we get to think in paradigms as opposed to think with words and so on. I'm not sure about that. That's something I still have to figure out. I've sort of been actively thinking about that. It's very hard to think about things that are beyond one's level of thinking, so to speak. But I'm sort of trying to do that. I mean, it's kind of like, you know, what can you get just a peek of this thing, which maybe our brains can't really do now, in a sense with computation, we're getting a peek at something our brains can't do. None of us can run sophisticated programs in our brains. So we're getting a peak of that by seeing this phenomenon of computation. And this is kind of a more extreme version of that. All right, well, there's many, many interesting questions here which I will enjoy trying to answer another time. And I didn't even get to tell you my history project that I'm in the middle of right now. It's probably just as well because I haven't finished it and I'll be able to tell it more coherently when it is finished. But thanks for joining me. Thanks for lots of interesting questions and see you another time.