Future of Coding - Structure of a Programming Language Revolution by Richard P. Gabriel

Episode Date: September 20, 2022

Today we're discussing the so-called "incommensurability" paper: The Structure of a Programming Language Revolution by Richard P. Gabriel. In the pre-show, Jimmy demands that Ivan come right out and explain himself, and so he does, to a certain extent at least. In the post-show, Jimmy draws such a thick line between programming and philosophy that it wouldn't even look out of place on Groucho Marx's face. Next episode, we will be covering the Worse is Better family of thought products, so take 15 minutes to read these three absolute bangers if you'd like to be ahead of the game: The Rise of Worse is Better by Richard P. Gabriel Worse is Better is Worse, definitely not by Richard P. Gabriel Is Worse Really Better? by Richard P. Gabriel Links Phlogiston Theory Phlogiston the excellent chiptune musician. Bright Eyes - First Day of My Life, by Conor Oberst. Not to be confused with Conal Elliott, who introduced the original meaning of functional reactive programming in his work on Fran. Peter Gabriel - Games Without Frontiers Pilot: A Step Toward Man-Computer Symbiosis Jimmy's talk Paradigms Without Progress: Kuhnian Reflections on Programming Practice There's some sporadic discussion of Philip Wadler (who Ivan playfully calls "Phil"), specifically his claim that programming languages have some bits that are invented and some bits that are discovered. While we're here, make sure you've seen the best 15 seconds in Strange Loop history. Peter Naur's Programming as Theory Building Sponsors CarrotGrid — They don't have a web presence (weird, hey?) but they're working on an interesting problem at the intersection of data, so listen to the short ad in the episode to find out more. St. Jude Children's Research Hospital — Instead of running our usual sponsors today, we'd like to direct your attention to this humanitarian cause. September is Childhood Cancer Awareness Month, and our friends (can we call them that?) at Relay.fm are running a pledge drive. If you have any spare coins in your couch cushions, or a few million left over from your last exit, you'd be hard pressed to find a more deserving way to invest them. Donate here. Show notes for this episode can be found at futureofcoding.org/episodes/58Support us on Patreon: https://www.patreon.com/futureofcodingSee omnystudio.com/listener for privacy information.

The Future I do have an introduction topic that I'm, you don't have to indulge me in, but that I am interested in talking about. I want to be meta here and talk about introductions. Introductions as in like the beginning of a show or introductions as in like the beginning of a relationship? Like, hey, I'm going to introduce you to this person or I'm going to, you know, there's this album I want you to listen to, that kind of thing. What are we getting at?

Yeah, no, I meant like podcast introductions. Okay. So it's very specific here. Yeah, narrow casting. Yeah, a lot of podcasts, right? And this is not one of them would start with something like, this is Jimmy Miller getting lost in broad daylight in Indianapolis, Indiana. And today we're going to be talking about Richard P. Gabriel's paper,

The Structure of a Programming Language Revolution. Let's code. language revolution. There's a lot of those sorts of introductions and you don't do that here. And I'm just curious to hear your thoughts on why there isn't like the typical start to the podcast read, you know, also though, I also want to just use this moment to praise you on uh how awesome the introduction to last podcast or i guess two podcasts ago was take off you hoser you you you have trapped me in a conversation where i have to talk about myself on my own show how dare you i mean you're the editor you're allowed to just edit anything out so that's true um in fact it's it's it's good that you've mentioned that i'm the

editor you've asked why the show doesn't begin with those kind of introductions i will tell you that this episode will begin with that kind of an introduction since you've just given me one which i i'm pretty sure you were doing on purpose but uh anyway i definitely don't have that written down and read it because I thought about the wording. Yeah, it definitely didn't sound like somebody reading a prepared statement. No, definitely didn't. Contextualized such that it would be a good joke that I put that at the beginning of this episode, which I in fact did.

Yeah, why does this show not start with that kind of thing? I have fun doing something different every time, and I don't really feel like it makes the show particularly fun to listen to, but it's something that if I don't do that, then I don't enjoy it. So at this point, live recording Ivan starts giving some motivations that give rise to the extreme formalism that I, editing Ivan, am responsible for. And I think that those justifications don't really stack up. I think the main reason that editing Ivan really likes to introduce these sorts of formalisms and surrealities and oddball eccentricities into the show is because it breaks with something that i see as a corruption of the podcast as a medium for playful communication that corruption is coming in the

form of hyper produced shows by teams of producers and editors and staff who are trying to bring big money into podcasting because they see it as sort of a life raft for what used to be terrestrial radio and satellite radio. And so they've come to take podcasting from what it was, which was this sort of oddball, freewheeling, underproduced, personality-driven form that rose organically on the internet. And they're turning it into something very commercial

and very accessible and very familiar, and I don't like that. I don't think that feels good to listen to. None of my favorite podcasts have that format. So at this point, editor Ivan starts ranting and raving about all the things he loves in good podcasts, and that doesn't feel very fair to me second-guessing Ivan, because it sort of presupposes that you, the listener,

who, it should be said, should never be referenced within a podcast. There should be no fourth wall breaking. That's against the rules. The listener shouldn't have to care about what Editor Ivan thinks makes a good podcast. The listener is here because they enjoy this podcast for whatever reason they enjoy this podcast and they enjoy whatever other podcasts they also like. And so they, you should just get to listen to whatever makes you happy. So Jimmy's question is poorly formed because it assumes that there's some sort of motivation for

doing things differently on this show, which of course there isn't. I thought this was a perfect paper to have this sort of meta discussion because this paper doesn't start the way a lot of these programming, it isn't written a lot of the way these programming papers you'd expect to be written. Yeah, throughout. Yes, exactly. And so it also has like two introductions. There's some fun playing with ideas here that was really reminiscent of what I see you doing with these introductions. So that's one of the reasons I started thinking about it, right? For me personally, that helped me understand why you do that.

And I'm sure there are some listeners who've wondered that. So I'm happy to dive into this paper if you are. Let's do it. Yeah, because I'm sure we'll come back to that. This paper is all over the place in the best possible way. dive into this paper if you are. Let's do it. Yeah, because I'm sure we'll come back to that. This paper's all over the place in the best possible way, and I'm very okay with this episode being all over the place in a similar way.

Yeah, at the same time, I think the structure of this paper is really interesting. So this is, as I think the introduction's already told you, the structure of Programming Language Revolution by Richard P. Gabriel, and it's really kind of two papers in one. And that's the like threads we're going to be pulling on

as we go throughout this is like, it's a discussion about object-oriented programming and mix-ins in particular, and the way they show up in these various systems and in the way they were described in a paper by, as they put it, two young and very smart computer scientists. But it's also a paper about a change in the way programming research is done and the way computer science research is done and what the implications of that are.

Well, and I think there's even a third level, which is even a step further removed, where it's thinking very big thoughts about what is the nature of science and is computer science a science in the way that natural science is and there's this sort of i i see a distinction between the middle level of sort of looking at not the computer industry but like the institutionalized world of computer science and computer research and computer engineering and conferences and papers and that sort of thing. There's this like mid level, but then there's also this like super high level of, you know, what is science and how does our theory of what science is evolve and what can we learn from looking at how other sciences have

evolved over time and how does that relate to what we're doing with computers i love also the abstract here right so this is the paper starts with the the most simple abstract you've ever seen which is engineering often precedes science incommensurability is real that's the whole abstract that's the whole abstract. That's the whole abstract. And not only that, like the first page of this paper, it's the most interesting layout that we've encountered yet. Like you've seen research papers, you know the format, they have a certain look to them. This one, its title is like a little concrete poem in the top right where it says, The Structure of a programming language revolution and programming language revolution kind of descends down in a in a column and so it's this little l-shaped title in the top right corner sort of hugging richard p gabriel

ibm research redwood city california usa um in the middle and then underneath that he's got his email addresses rpg at and then a little curly brace to indicate uh the set membership or something like that and then the the two different domains you can put rpg at in front of and then in the top left corner a quote from uh borges saying i don't want to die in a language I can't understand. And then further down the page, there is the front page of that paper by two young and very smart computer scientists that Jimmy mentioned a moment ago.

That whole first page of that paper is embedded in kind of like a tea-stained, yellow, faded art style. And then the actual first paragraph begins with a giant drop cap but instead of being a letter it's just this squiggly line and then the paragraph separators are these beautiful squiggles like it's just it's a beautifully typeset paper oh yeah and then and then i'm gonna spoilers jump ahead a minute here. The beginning of the first real section after the intro is titled engineering, comma, a path to science. But the comma is surrounded with parentheses.

So he's already doing like, oh, here's a here's a here's a section title with a double meaning. Is it engineering a path to science as in we're going to do engineering work to create a path to science or is it saying engineering which is a path to science um there's just like so much playing with the format in this paper that i i just after augmenting human intellect it's like such a breath of fresh air to have somebody thinking about presenting their what is basically a blog post with so much consideration and so much regard for like different levels of communication and presentation and all that it was it was very very enjoyable to read just at an aesthetic level i think in general richard p gabriel his papers are just very different in a very refreshing way, right?

And the topics he's talking about and the way he talks about them, I really love, even if I don't always agree with everything, it just, they make you think. They make you step back for a second and reconsider the things that you're doing. I just love, not only do we have this stylistic difference on the first page, we also get this little paragraph to kind of like usher us into the paper. That night I pulled the paper down from the ACM server and read it while outside enormous

puff clouds dwelled overhead, lit from beneath by the town of Porto de Galinas on the Brazilian coast. The smells of burning sugar cane and bitter ocean pushed into my room. Yeah. So I just love that introduction because what paper do you see in a computer science setting that gives you the look at the author and what they're doing as they're doing their research, right?

Like, I just think this is, it has that little bit of flavor to it. It really tells you what sort of paper you're going to be encountering and puts you in the right state to kind of understand his thought here. And it might seem like the descriptive language, for instance, outside enormous puffed clouds dwelled overhead. That sort of flowery language might seem like it's indulgent, but it actually serves a purpose in that he returns to this moment several times throughout the paper. And so by putting in a passage that is very playfully written that feels not in keeping with the typical style

of an academic paper of a computer science paper, it really sticks out in your mind, but he uses the fact that it sticks out in your mind later on in the paper. So it's not just indulgent, it's done with a with a really smart purpose. Yeah, absolutely. Okay, so we've kind of talked about the stylistic thing here. but I think we should dive into this paper. Engineers build things. Scientists describe reality. Philosophers get lost in broad daylight. Which is, of course, a throwback to the intro of this episode.

Ricky didn't know that he was going to be describing the intro of this episode when he wrote that passage, but in fact... Absolutely. Yeah. And so this is how we're ushered into this essay. Seemingly...

We're introduced, I guess, first to this paper. And this paper is a paper called Mixed-In Based Inheritance. That's a paper written by the two young and very smart computer scientists we keep referencing. Gilad Bracca and William Cook. And this is a

a paper that they wrote in 1990 i think it's it's a really pivotal pivotal it's a really pivotal thing a pivotal thing that uh that this uh structure of a programming language revolution paper by uh gabriel is going to be discussing and so i think it's going to be a little bit tricky we probably won't have this perfect but we're going to be discussing. And so I think it's going to be a little bit tricky. We probably won't have this perfect, but we're going to be talking about two different papers at the same time. One is the mix-in paper and the other one is the, I just, I'm going to call it the incommensurability paper. Yeah.

Just because that's, I mean, that's how I've been thinking of it this whole time. It's, it's the big, biggest word in in the abstract which obviously means that's the the thing that Should have been the title so yeah We've got the mix in paper and the incommensurability paper mix in paper by Braca and cook and the incommensurability paper by Ricky Gabriel And this mix in paper were told it Immediately laid claim to being the first Scientific paper on mix ins and so this is actually kind of the the key point here is that we're going to have this discussion about engineering about science and

we're going to contrast this mixin paper which is the first scientific paper on mixins with all of the things that came before it and these these are things like beta, small talk, flavors, and CLOS. C-L-O-S. The Common List Object System. The Common List Object System. The Common List Object System. Yep. That's what we're going to get is this contrast between these two things.

And spoiler alert, Richard P. Gabriel thinks that the scientific paper kind of missed the point. Yeah, this is going to be hard to summarize, I feel like, because it lays out the argument in a slightly circuitous way. So I'm going to be interested to see if we actually manage to make it through this in a kind of

linear fashion along the paper, or if we have to keep zooming out and saying hey, spoiler alert, here's where we're going, because I almost feel like it would be worth explaining, like, like spoiling the punchline a little bit, just because that's a more direct way. I think that's honestly probably good is to just say up front, you know, what's what's going on. And then we can kind of dive into that and see if we can kind of justify it. So basically, there's this idea of incommensurability. And incommensurability comes from Thomas Kuhn. And Thomas Kuhn was looking at the way in which

science evolves over time. And he found that these old theories of science and these new theories of science might use the same words, but meant very different things. And there was actually no easy way to translate between them. And Richard Gabriel thinks that that's what we're dealing with now. That the old way of doing things, his way of doing things, the systems way of doing things, as he calls it, has fallen by the wayside. And there's this new paradigm of the language way of doing things that is exemplified by this mix-in paper from Braca and Cook that kind of missed the point of the old paradigm. This paper shows that they might use the same words, mix-ins, but they mean these vastly different things by it.

I think it comes across in the paper that he's really concerned about this. I think that that first quote is actually kind of this anxiety that Richard Gabriel feels about the fact that the work he's been doing for so long now, he's now living in a world where he can't even understand things commenting on the work he did earlier in his career. Well, and this this paper is written

fairly recently, right? Like it's in the 2010s. When this paper, the incommensurability paper, yeah, 2012, it laments a bunch of things that happened in the 90s. So it's it's not even that there's a that there's a worry about the way things are going in so 90s. So it's not even that there's a worry about the way things are going in so much as it's sort of like somebody who has been worried for several decades now about what happened and they finally found a way to articulate

why things happened. And even very late in the paper, Gabriel suggests that Bracca and Cook could have realized this at the time. that all the pieces were there. And the idea of incommensurability as a disconnect between old practices of a science and newer practices that are superseding them is something that was in the popular science culture in the 1990s. So if the stars had aligned, they could have had this realization and maybe others in the industry could have had this realization and avoided some really heartbreaking things that happened in the 90s that we'll get to, I think, when we get to

them. I wanted to read a quote from Kuhn where he describes what incommensurability means to him, just because this is a quote from the paper. And so I think it's, I get to use the little radio voice and I like to use the little radio voice. Incommensurability is a notion that for me emerged from attempts to understand apparently nonsensical passages encountered in old scientific texts. Ordinarily, they've been taken as evidence of the author's confused or mistaken beliefs. My experiences led me to suggest instead that those passages were being misread. The appearance of nonsense could be removed by recovering older meanings for some of the terms involved, meanings different from those subsequently current. And so what he's getting

at here is this, and I really want to nail what this word incommensurability means, because it's a really cool concept, and it's going to be relevant to a whole bunch of things we talk about. It's this idea that when you're reading some old scientific work, and it gives some examples in this in this incommensurability paper of um this this substance called phlogiston am i pronouncing that right phlogiston phlogiston phlogiston i'd never like i've i'd heard of this substance before because i i uh there's a chip tune musician who i think uses it as their as theirias. And that's the only case where I've heard of this term before. But it's this old idea of how fire and combustion worked that sort of predate what we now know of as thermodynamics.

And so I also want to read this quote of the paper, and then I'm going to talk about it as the example. So here's sort of a couple levels of quoting from the incommensurability paper. One good example is the steam engine. Engineers began its development while scientists were making their way from the phlogiston theory of combustion to the caloric theory of heat, both today considered hilarious. Phlogiston theory was an attempt to explain oxidation, fire, and rust. The phlogiston theory held that combustible resources contain

phlogiston, a colorless, odorless, tasteless, and massless substance which is liberated by burning. A phlogisticated substance contains phlogiston and is dephlogisticated when burned, leaving behind its true form, calx. And then here's a quote within the quote. And this quote is from James Brian Conant in an overview of phlogiston theory, the chemical revolution of 1775 to 1789. Substances that burned in air were said to be rich in phlogiston. The fact that combustion soon ceased in an enclosed space was taken as clear-cut evidence that air had the capacity to absorb only a definite amount of phlogiston. When air had become completely phlogisticated, it would no longer serve to support combustion of any material, nor would a metal

heated in it yield a calx. Nor could phlogisticated air support life, for the role of air in respiration was to remove the phlogiston from the body. So there's this scientific theory from the 1700s that is patently absurd when you look at it through a modern contemporary scientific lens of today. And this idea of incommensurability is suggesting that we shouldn't do that when we're encountering an idea from a different era we should try very hard not to look at the terms that it uses and the language that it uses and the and the and the ideas that it's exchanging with our modern definitions because if we do that we will lose a lot of the nuance and subtlety and meaning of that older work because it's using words that are still used today, but it's using them in a different way. And that the

meaning of these words has changed over time so much that our current understanding of what these words mean doesn't match up with how they were used back then. And we might look back and see it using these words in what feels like an incorrect way. And this phlogiston example is a little bit silly because it's deliberately very wrong, but this is an idea I encounter all the time when dealing with music theory or art theory or even computer science, if you can believe it,

where there will be an older work that uses terminology in a way that's different from how we use that same terminology today in fact here's a great computer science example functional reactive programming frp we all know that story that in the 90s um uh what's his name uh connell Elliott. Connell Elliott. Thank you. I was thinking Connor Oberst, singer of Bright Eyes. No. This is the first day of my life. So singer of Bright Eyes,

Connor Oberst wrote this paper when he was at Microsoft about how sad it is that, how depressing and how it makes you cry because animations were using discretized frames instead of continuous functions over the real numbers. And so he wrote this thing about if you're going to do animation, use real numbers, don't

use integers, use things that can be evaluated as functions rather than like discrete measurements of data at specific frames, right? That's what functional reactive programming means. But nowadays, if you talk to people about functional reactive programming they will say oh no it's this idea of like making web you know front ends and back ends that are these streams and these uh functions that you can use that take and return streams and it's these you know stream combinator functions and that's what functional reactive programming means it has nothing to do with animation and continuous real numbers

rather than discrete individual frames, right? So we have two different meanings for the term functional reactive programming, such that Conal Elbiot now says that he wishes he had used the term denotative design to describe these ideas because that's closer to what he was getting at as a way of sort of saying like, look, you know, all the all

the react kids have taken my term functional reactive programming and have given it a new definition such that when people read the old functional reactive programming papers that I wrote, they're very confused and it doesn't make sense. And so this situation where the contemporary meaning of a term is different from a past meaning of the term puts you in this position where you can read the old papers and think that they're worthless or think that they're wrong or think that they're poor. That's where the idea of incommensurability comes in, especially in the context of computer science is that this mixin paper by bracha and cook is looking at these

older object systems from lisp and from small talk and i'll leave the details of how it commits this sin for us to get into in a minute but the sin it commits is that it has one set of thoughts about what mix-ins mean. And it looks at these old papers, assuming that they mean the same thing when they say mix-ins, and they don't. That's kind of where Gabriel bases his argument for how incommensurability is at play here. That contemporary 1990s ideas about what mix-ins means aren't matching up with the earlier 1980s and 1970s ideas about what mix-ins means. That's like one of the cruxes of this paper. Yeah, I think that's a fantastic...

I'm glad that you read those quotes. I want to... Just because I'm a nerd who really likes philosophy of science, I actually gave a talk on Kuhn and programming before I knew about this paper. I was into incommensurability before it was cool. But I think there's another way that Kuhn, we don't really see in this paper, but I actually think it's really important that Kuhn emphasizes. So you get like ridiculous sounding theories like phlogiston and caloric, but you also get theories that we think of as like approximately correct, like Newton versus

Einstein, right? That like Newtonian mechanics is just an approximation of Einstein. And Kuhn wants to even tell us like, we can't do that. That to do that is actually to not understand what Newton was trying to accomplish. Newton wasn't trying to be an approximation of anything. He wasn't bracketing off, you know, things near the speed of light or with very heavy masses, etc. He was putting forth a total theory, right? A complete theory. And if you actually go back and read newton and try to pretend that it was just an approximation of eisenstein you're going to find yourself very confused that there's going to be a bunch of stuff missing and so i think we could also be tempted here to read the

early mixin papers as just an approximation of what we now know mixins really are and i think that also like like, instead of thinking of them as ridiculous, we just think, ah, they were close. And that actually also would be to miss the substance of those papers. And I think one of the things that computer science does, and this Richard Gabriel paper describes this phenomenon a little bit, and we'll hopefully come back to this in a richer way in a minute. But in a superficial level, one of the things that happens in computer science is we generally think that as time progresses, the theories that emerge and the practices that

emerge are encompassing generalizations of the things that came before, or they're more correct or more workable or more versatile or in some way more complete that we have this sense that as time goes on there's like a march of progress effect where later theories are able to encompass earlier theories and that we're able to sort of stand on the shoulders of giants and so this paper from from Braca and Cook, to take Gabriel's articulation of it, and to be fair, I haven't read the mix-in paper, so I don't know exactly whether or not this is a charitable interpretation of what they're saying, but assuming that it is, that they're positioning their formulation of mix-ins as something that can subsume these earlier articulations from

Smalltalk and from Lisp from these earlier articulations from small talk and from lisp from these earlier works and that's a separate matter from the fact that they claim that it's the first scientific paper about mix-ins that's a that's a separate dimension of presumptuousness that we will drill into in a minute but just there's this feeling that in in computer science like natural science later theories are able to cover in totality earlier theories and that in in computer science like natural science later theories are able to cover in totality earlier theories and that is in fact not the case and that's not the case always in natural science as we know from einstein's relativity versus um quantum mechanics right there's that need for a grand unified theory because we have these two theories that aren't total and so we're looking

for a total theory you know that's the exception that kind of proves the rule that in general later theories are able to completely subsume earlier theories and computer science being a science makes us feel like that's also the case when in fact that is not at all the case and it's probably not even close to being the case that earlier theories and later theories are independent in part, and this is something that the incommensurability paper seems to argue, in part because computer science is not a natural science. Natural science is about looking for this singular truth about the nature of reality, and that better theories are able to be a closer approximation of the nature of that

truth and that as that science is done it doesn't actually change that ground truth whereas in computer science as the science gets done there's this interesting mix of discovery and invention and that that that is a huge point of debate. And I have many feelings about that, you know, how much of computer science is invented versus discovered. But to the extent that any of it is invented and not discovered, later science is going to be a reflection on the materiality of computers as they exist in that moment, and that later science is going to change that material. It's going to take what we know of as the computer and change it into something new.

And the science that follows isn't going to be looking at this immutable computer that has existed throughout all of time. It's going to be looking at the computer that is as it is now, as it was changed by the earlier science and the earlier engineering. And it's this constantly shifting thing And so it's sort of a mistake to assume that because we call it computer science You know with the s-word that the thing being studied is as immutable as the universe that we study in natural sciences

And so that that leads us to this assumption that later computer science is going to be encompassing earlier computer science, when in fact that is arguably not at all the case. Yeah, and he puts kind of this belief that he has about the relationship here, I think pretty succinctly. I believe engineering and science are intertwined. And for programming languages

and software creation techniques, it is often the case that engineering precedes science, and it's very easy to see it. And I think this is one of the key points that he gets us into this paper, is that engineering is, in natural science, very important. You know, you read this idea about phlogiston and caloric, and he says that even during all of this time of these incorrect theories, as we would put it today, the steam engine just kept going. The steam engine was already being created. The steam engine kept improving. And it didn't actually care what the theory of how it worked was, it worked. And in the same way, and maybe even to a greater extent, as we're doing programming, as we're building systems, we're creating that. Engineering is what is forging ahead, and science is what's looking back. One of the things that both the mix-in paper and the incommensurability paper discuss is this emphasis on good design.

One of the failings of the mix-in paper is that it assumes that what makes for good design are things that make for good design in a programming language. And the things that the earlier Smalltalk and Lisp papers assume make for good design are what make for good design in a programming system. And so this comes back to that point that Jimmy made earlier about a disconnect between the mix-in paper and the earlier object system papers. The earlier papers are looking at programming systems and just very briefly a programming system is sort of what we think of today as live programming. There are a bunch of other terms that we use for it. I think for the same reason that poor Conor Oberst had to rename his idea from functional reactive

programming to denotative design, that programming system is a term that is so loaded with multiple meanings that we can't really use it nowadays the way we used to. And so we now call it live programming. And I'm being a little bit fast and loose with the terminology oh dear i'm perpetuating the problem um a programming system is is something where the program is always running that there's a repl or there's some environment where there is live living code it's it's continually executing and what you are doing is you program is you are introducing changes to that live running system. And so any objects that exist in that live system are transitioned into some new form. And so you need semantics around how do I take my existing objects and turn them into new things without losing them.

Whereas the programming language approach is I have a source code in text and I have a compiler and the compiler turns the source code into some compiled program and then I run the compiled program and the compiled program runs until it stops. And that divide between those two schools means that what counts as good design is different depending on which approach you're working within. If you're working within the programming language school, when you encounter an issue, you just shut down your running program, throw it away, throw away all its state, go back to your source code, tweak the source code, and then recompile and rerun it. And that means that you emphasize certain things, you emphasize correctness in a different way, you emphasize, you know, all the things that we look at when we look at what make the good tools so that you can do good programming design, tests and types and, you know, patterns

and all that kind of stuff. They are expressed in a certain way when you're looking at a pre-compiled programming language where the expectation is you throw away your state whenever you need to make a change. Whereas in the programming systems world that is, at least in the framing of the incommensurability paper, the programming systems world is a little bit older. That one, what tools you have that make for good design are different. It's not about testing and types and all all that in the same way because you are instead more concerned about not correctness in the sense of is the source code correct but correctness of the sense in that is the running system internally consistent and is it able to

be transitioned into new states and are the the messages that the different objects in that system able to send to each other the right messages and and how does it work as a living evolving organism as opposed to something that is like the static source text is the thing that is of paramount importance and the source of truth? And so that kind of disconnect there between the earlier papers that are about programming systems and the later papers that are about programming languages That's another one of these It's another one of these huge aspects of this this actually relatively short incommensurability paper that like that opens up so many cans of worms because what is meant by good design

differs depending on which side you're on so that's that's that that's an incommensurability there is that Bracca and Cook assume that what good design is in the world of the new is the same as what it was in the world of the old. And they miss that there's actually a difference there that means that good design means a different thing on each side yeah to make this uh this rabbit hole go deeper i i agree with everything that you've characterized as like that's what uh richie see i did it now haha that's what richie uh thinks is the case here right like that is what he that's where he focuses his difference on i actually think he's misplaced it i i i think that there is something true to that right there's something about language versus system but he discards he says like he used to think it was engineering versus science and he discarded that and realized it was more narrow than that it was systems versus language language. But I don't know. I

think he might have been more right on this initial thought of engineering versus science. And the reason I want to say this is imagine that instead of focusing on languages, on these formal grammatical structures, the modern computer science had focused on systems evolving over time and had thought about the correctness properties of you know you can imagine like poor triples or something you know like the before the preconditions the post conditions and had specified formally all the ways that this system should work. Right? I don't think Gabriel would have been any happier with that.

I don't think he would have been like, ah, yes, you're focusing on systems and how they adapt over time. I'm all good with it. I think what he really is getting at is what he puts in this paragraph here. He's talking about this differing opinion between whether engineering precedes science or science is discovering all the things and engineering has to just do its bidding, right? So he says,

what's the effect of these differing opinions? What happens when engineering is reduced to science's handmaiden in the fields of programming languages and software, and in computer science in general, the effect has been to separate engineers from scientists and put them in a little hierarchy. Engineers are for the most part left out of the lofty scientific academy. I think this is what he's really lamenting in this in this paper and i do think this paper is kind of a lament it is the fact that as practitioners as builders as engineers we've kind of been left

out we're not writing papers ourselves we're not included in the scientific discourse and you'll see people now i if you go on twitter writes the certain sections of twitter you'll see people now i if you go on twitter writes the certain sections of twitter you'll see people saying like if run-of-the-mill programmers would just listen to what the scientific research is what computer science has told us we would solve all these problems and we wouldn't have a big deal and to me yes he's right that the disagreement in the Mixon paper and the incommensurability paper might be about these systems versus language thought, but that's such a minor point, and I think the bigger one is this starting point. There's a starting point of do we build something,

or do we describe something and only later build it? Yeah, like that that almost like a class divide between computer scientists and computer engineers. Like that, when I was reading this, and he gives some examples of like, he took a, he,

Peter Gabriel took a break from writing computer science-y kind of stuff for a couple of years in the early 90s. And when he came back in the mid-90s and tried to submit papers to conferences and participate in the community again, he noticed that all of the conferences that he used to participate in had been rebranded and were no longer about Lisp and were no longer about the practice of programming, but they were instead now about theory and they were about the science and they were about sort of a more academic research kind of focus. New conferences were created to focus just on the

practice and they were treated as sort of a lesser side channel for people who were not as relevant, perhaps. And I went to university for computer science in the mid-2000s. But when I was there, something I noticed was that class divide was still in full tilt, at least in my university. There were all these courses you could take, and there were the different degrees you could be working towards. And so there were all these courses you could take and there were the different degrees you could be working towards. And so there were some classes that were just for computer science and there were some classes that everybody takes, whether they're doing hardware engineering or software engineering or computer science.

And so one of the things that we would talk about as undergrads was, hey, what's the difference, right? Why is this class just for computer science and that class is just for software engineering? what's the difference, right? Why is this class just for computer science and that class is just for software engineering? What's the difference? And the thing that we got from our instructors and the thing that we got from our older peers was this like sneering condescension

towards software engineering because that's what you would study. That's what you do if you weren's what you do if you weren't particularly gifted, if you weren't particularly mathematically or scientifically inclined, if you just were going to get a job as a code monkey writing Java. It's the thing that you do if you're just looking for a job with a computer and not something that you do if you're actually passionate about what a computer is and what it means. And the people who are going to go on and have great illustrious careers and Are going to be important and are going to do the fun part of programming work

They're all the ones in computer science and the computer engineering is like this this lower Class that we don't interact with except when we have to and of course, this is all patently absurd This is preposterous. It's ridiculous. It's so hurtful and it's so pointless. It's one of these cases of culture kind of boiling over and spoiling what would otherwise be a wonderful opportunity for people with different interests to cross-pollinate you know like like the things that the software engineering side was actually focused on were things like thinking about good design and thinking about how do you build a system whereas computer science was very much

like head up its ass sort of the kind of the researchy stuff like type systems and and lisp and all that like all that you know wanky kind of nonsense that nobody should be interested in because it's terrible that little aspect of there being a culture war here that is yet another thing that this very short paper digs into and opens up a rabbit hole about yeah i i knew that we would run into this with the paper so like to be clear as i'm like looking through my notes all the things we've talked about are kind of like scattered as little observations here and there right like they're they're all in this big frame story that we haven't really even gotten the details of about mixins yeah and these differences and then just

like sprinkled in you'll get little quote here about engineering versus science little quote there about coon right and it it doesn't translate super well to a podcast but as a paper i loved it yeah like i loved that you were it it was like comedic relief right in some ways like i'm not saying it was funny but just that like you're in a very serious moment and then all of a sudden like now you get those little thoughts interspersed in and it kind of keeps you back in to the the technical detail that he wants to talk about here a part of this paper that we haven't really talked about at all is that it has lengthy technical discussion of the difference between uh different object

systems in small talk lisp and then some language based programming as opposed to system-based programming and those technical discussions like it it it almost throws in these sort of you know oh hey that makes me think kind of asides that launch these huge you know thoughts about class war or about is computer science a science in the way that natural science is a science like these you know these huge thoughts just yeah like jimmy said they come out of little little uh palette cleansers in between okay let's roll up our sleeves and talk about uh about the way um objects work in this one particular paper that built this you know this system called flavors right we're going to talk about flavors a whole bunch if you if you did a like a heat map of how much of this paper is devoted to these big big ideas and how much is

devoted to object systems and remember this is a short paper. It's like, I'd say 60 to 70% about object systems. And we haven't talked about that at all yet. I find that I find that very funny. Yeah. And I guess we could, you know, we could try to get into that a little bit. I don't know how much of like detail we want to get into. And, you know, we have like quotes from the object system the common list object system specification about exactly how these things work but i do think it's important to kind of get the flavor of disagreement going on oh boo boo that was actually an unintentional pun uh So that makes it good, right? I think that's the requirement for a good pun.

All right. So here's my way of specifying this kind of disagreement. Mix-ins are not this one monolithic idea in Richie's mind, uh in richie's mind right in gabriel's mind right there they're kind of a term that was developed over time an idea that like different systems kind of took different stabs at and kind of continued to accrete and add new features onto and so it's not as simple as we can go look at the definitive definition of mixins, but we can kind of look at all these various systems, what they were doing with mixins, and what they had in common. And that can kind of give us a good general idea of what mixins were. And his idea is that they're orthogonal code. They're code that you can write at the edges,

and once you combine things together, you get functionality that emerges from all of these parts interacting together. And so the example that's given is about these before and after methods, that you can say before this method is called please do this or after this method is called please do that and being able to do this you can compose together all sorts of

interesting functionality that you wanted to be orthogonal you didn't want it to be in one place you wanted lots of different things to be able to mix in and combine and use this functionality together. And so that's Gabriel's idea of a mix-in. And then we get to the mix-in paper's idea about mix-in. And I will admit that I don't quite have as good of an understanding here of what that one is, because that's not most of the text here. Yeah, it's not really explained. Yeah, what we get is kind of the opposite. We see that their definition literally excludes the definition that Richard wants to give us here, right? So we get a quote from Bracca and Cook saying, In class, locally unbound uses of call next method are clear indications that a class is a mixin.

And Gabriel goes on to tell us that you actually can't use call next method in before or after methods. So that this clear indication is exactly the opposite. What Cook and Bracco want to include as mixins literally excludes the very idea of mixins. And what their idea seems to be is something about the way in which inheritance works. And that's really the primary mechanism here is this kind of way of doing multiple inheritance

that completely ignores these before and after methods that Gabriel sees as core features of mixins. The focus on multiple inheritance is worth pushing on because the objection that Bracca and Cook have to the way that older systems do mix-ins stems from in part at least this is as you know i'm parroting peter who's parroting braka peter you mean richard oh i mean uh peter peter gabriel richard p the p stands for peter it must it must there's only one p gabriel and it's peter gabriel come on aha peter gabriel is definitely not a different person no no no so pd um in his paper uh if is

parroting braka and cook you know this is several uh games of telephone happening. Uh-huh, exactly. But the issue that Braca and Cook bring up is that multiple inheritance, you want it to resolve statically. source code and I declare that I have some superclass in a class that I'm creating, what exact methods are going to be visible from this class that I'm writing? And what is the exact chain up the class hierarchy that I will be climbing as I am searching for a method? Like as the program is running and it searches for a method on this class, what are the exact superclasses that are going to be searched for that method? And the way that these older Lisp and Smalltalk and other mix-in ideas worked, it was not so static. Because of multiple inheritance and because of the way before and after worked, you wouldn't know at compile time what your exact set of superclasses

would be. If you're writing a class in Smalltalk or whatever, and I'm going to get this wrong, but this is my best sense of it. If you're writing a class in Smalltalk and you declare that you're extending some superclass or you're mixing in some abstract base class to just mix all sorts of different generations of terminology in here, because of the before and after, there might be other classes that are injected into your hierarchy that you will encounter as you climb up the chain. And so you looking at the source code of your small talk or your list program don't know what the truth of the class hierarchy will be. Because the truth of the

class hierarchy exists in the running system at runtime and this is where that systems versus languages approach comes down that braka and cook want the truth to be known at the time you're writing the source code before you compile and the earlier lisp and small talk people want the truth to be known at runtime in the running system and the and the source code does not need to be the source of truth and that difference leads to this misunderstanding on the part of bracha and cook this alleged misunderstanding about how mixins worked in these old systems and what they were good for why they were bad um and why why they weren't really worth considering and that sets them up to say okay you know those old mix-in systems had these these issues where they would encourage bad design and these this

new formulation of mix-ins that we're introducing here encourages good design. Yeah, and what Braca and Cook criticize about the doing it this way is that there's a violation of encapsulation. I think this is one of those incommensurability ideas here where encapsulation means very different things to Cook and Br braca versus richard gabriel because of these systems ideas that encapsulation is about the text and whether you're being accurate to the text right whether you you're really following what the text said and not letting other things get in and access stuff that they're not supposed to. And for Gabriel, it's really about is the system running the way that it ought to? And is the system stopping things from having access that they shouldn't have

access to? Maybe that was not, not clear at all, but I've encapsulation is one of those really fuzzy concepts. Yeah. having access that they shouldn't have access to. Maybe that was not clear at all. Encapsulation is one of those really fuzzy concepts. Yeah, almost as though it's subject to incommensurability, where depending on what paradigm you're in, it means something different.

Yes, completely agreed. Yeah, I think, I don't know if there's's i don't know if we should dive into any more of these details here i will call out uh pilot as one of the papers that was pointed to that i just think is a really great paper and really does give you kind of a better flavor in my mind of what the system's idea of mixins would look like, mostly because it doesn't have any of the trappings of what we think about in things. I think it's really easy to take Common Lisp and consider it just a language

and not think about it as a system. Whereas Pilot, the idea was you were writing Lisp, yes, S expressions, et cetera. But instead of having an editor where you opened up a definition, and then were able to edit it, you actually like your main mechanism for editing your program was to have a dialogue with the running system. And the dialogue actually isn't in Lisp syntax, because there's this like meta level language over top where you can write your own syntax.

And so it would be like, like the most of that, that dissertation is actually walking through an example dialogues to solve problems. And so you're always saying like, before you return, ensure that you have an answer, right? Would be a very simple example. And then you run the program and you don't have an answer at the end because you haven't assigned the return value. And it like throws an error. It tells you like, oh, we didn't find your advice here. We weren't able to fulfill it.

How can I follow that advice better? It's this very interactive dialogue-based system. And there is no idea of the text because you're not writing in files. You're not ever opening up files. You can't open up files. You're writing procedures and referring to those procedures as entities in your system. So I'd really recommend checking out the paper in general. And I think it really actually gives a much better idea of this systems approach. It's 1960, I think. And so a lot of like the the kind of things we have established today just didn't exist. And so it's it's a very interesting take on a system, as opposed to a language. for taking your coordinate data and transforming it into visual representations of abstract information.

You can then use those abstractions to communicate with the temperature and humidity sensors in your garden, and then share that data with your local port authority. Carrot Grid gives you all the tools you need, like CSV, JSON, hoe, shovel, pin, hook, ball, rope, and pulley, so that you can load and unload all your platforms immediately upon arrival at the nearest port. With Carrot Grid, you'll never have to wonder if your flotilla is arranged diagonally or orthogonally. Carrot Grid's award-nominated customer support is available outside of major urban centers around the world above the 49th parallel. To help with any of your questions, receive your comments, feedback, pitchforks, and snuggles. I've been a carrot-grade user for 45 minutes and my fingernails have never

been tastier. My thanks to Carrot Bread for helping bring us this disquieting noise. Let's code! So in lieu of our usual sponsors today, I wanted to do something a little bit different. It is September 2022 as I record this, and September is Childhood Cancer Awareness Month. There's a podcast network called Relay FM, and I listen to a lot of their shows. And every September, they do a big pledge drive for St. Jude Children's Research Hospital. If you listen to any of their shows, you've probably already heard the spiel, but for those of you who don't, I'll repeat it here because, hey,

this is a podcast. Raising awareness about St. Jude is the thing to do and And so I'm going to get in on that also. The way that it works is, if you are in the US, and you have a kid, and your kid gets a cancer diagnosis, this can be the sort of thing that is financially ruinous for your family. Because in addition to treatment, you often have to travel to get medical attention, and you have to deal with all of the new strains and stresses that come about as a result of this very traumatic thing happening. And so St. Jude will, free of charge, take the entire family of the kid who receives the cancer diagnosis and house them and pay for their food and take care of all of their basic needs so that they can focus on being a family while their child receives

treatment for the cancer free of charge they are a research hospital so a large part of the value that they create in the world is in sharing what they discover about treatments for childhood cancers with doctors around the world. And thanks to work that St. Jude has participated in, the survival rate for childhood cancer has gone from 20% to 80% over the past 50 years. Unlike other hospitals, the funding for St. Jude comes primarily from donations. And so if you would like to take the loose change that you have found in your couch,

or maybe the windfall that you received from your last startup exit, and invest it in a very worthy cause, I would direct you to our show notes where you will find a link to a special fundraising page that I've set up for the Future of Coding community. There's a goal there that is fairly modest, so hopefully the people listening to this will be able to pitch in a couple bucks

here and there and get us to that goal. And instead of listening to an advertisement for another totally real startup, we can take some of our positive energy in this community and direct it towards a very worthwhile cause. So once again, check the show notes for a link to a page where you can make a donation to St. Jude Children's Research Hospital. My thanks to all of you for helping bring us the defeat of childhood cancer. Yeah, so at the top of page three on the right, it says, The Bracca and Cook paper is a dividing point or perhaps a bridge between two different paradigms, or perhaps micro paradigms. This observation further raised the question of incommensurability, a key part of Kuhn's ideas about scientific revolutions. So we've talked

about what incommensurability is, but I don't know anything about Kuhn's idea of scientific revolutions. Do you know any of that backstory? Yeah, so I actually did give a talk. It's on YouTube. It's Paradigms Without Progress. War Without Tears. Kuhnian Reflections on Programming Practice, where I go into this in a lot of detail, actually, because I assumed most people don't know about this. But, you know, the idea here is really pretty simple. If you think about how you were taught in school, how science works, it's this steady march of progress. We learn new facts, we adapt our understanding to those facts, and we just keep accreting things over and over again, right? We just accrete more facts. And Kuhn wants to say that that's not at all how it happens. It is really messy. It's these punctuated times of turmoil. And it always happens when a theory is failing in some way. And when the theory is failing in some way, there's

this moment of crisis. And everyone is looking for a new way out. and then the revolution happens, and the old way is discarded, and the new way continues forward. I think the best example of this is the Ptolemaic view of the solar system versus the Copernican view of the solar system. The Ptolemaic view we kind of think is like so silly today, like the earth is the center of everything, but it did real work for so long. And the only reason anyone started looking for answers is because the math started getting really, really sketchy. Like you could predict everything, but every time you wanted to get

to certain degrees of accuracy, you'd have to tweak stuff. They just kept putting bug fixes for the theory over and over again. And eventually people got so tired of dealing with bug fixes that they came up with a new idea. That's how some people do TDD, right? Like that's a totally viable approach. You do the minimum thing needed to get the test to pass. And if it's like, oh, you know, the test is saying that this thing needs to return false, just return false, right? If that's the only test that's failing, and then you gradually get a more and more general function, just just the minimum amount needed to satisfy the tests. And so that like, that's a

totally workable approach. Yes. And I think though, you know, maybe TDD advocates won't agree with this. But I think we've all been in this point where we continue down that path. And we know what it would take to get our program to be better. We just don't want to do it. Yes, we could add yet another if statement here. We could change just a little bit there. And instead, we often just scrap it and rewrite. And if you try to compare the old code that you were

writing that went in that style to your new understanding, it's actually very difficult to compare them because you often solve the problem in a very different way. You know, I think rewrites are often, they happen just like these scientific revolutions, right? Our rewrites of code, yes, you could go compare certain things about them, but your benchmarks are almost always a lie, right? You're almost always doing something decidedly different. You've broken down the problem in a different way. The vocabulary you use is different, and the words that are in common often have more nuanced, different meanings. This is something that we encounter, I think, all the time as we're doing

these things, because when we're making programs, we're actually building theories about how our programs relate to the world. That feels almost a little bit akin to, like, Wadler's idea. Was it Wadler's idea? Like, programs as proofs, that whole thing? i think that wadler almost would actually be like almost a rebuttal to this paper right because because wadler really believes that we should stop working on things that are engineered that are invented and only work with things that are discovered yeah that that that strain of his idea yeah yeah What I'm reminded of is Peter Nauer has a paper that I love called programming as theory building, where he argues that theory for him is way less technical of a definition. He actually uses Sherlock Holmes as an example of theory building, right? Where we're

coming up with these ideas to put them into use. And that's what he's really focused on is that we kind of have this, maybe I'm being too nerdy here, called the hermeneutic spiral, where we're discovering things, and then we put them into practice that cause us to go and discover things that put them into practice. And we kind of like spiral around and and we're getting in closer and closer maybe never reaching it uh to this point of understanding it's funny that we've actually

accidentally sort of backed our way into the uh the the next sort of thing that i wanted to point out about this paper that it like it launched a tangent of my thinking, which is thinking about who should get credit for an idea within computer science and within programming practice just very narrowly, right? Because you can you that question who should get credit for an idea that's, you know, me. Yeah, okay, Jimmy, done. Cool. Got it. Doesn't matter the idea. As long as it's good, I should get credit for it. Yeah, I guess that is a solution. It made the test pass. No, so I'm curious why you asked that question.

Is this, you know, like do Braca and Cook get this because they kind of like summarized it and fixed some problems? Is that what you're kind of getting at? Or yeah, what brought up this idea for you? There's on page six on the left side, there's a paragraph that reads, But Cannon's paper was not the first to talk about, essentially, mix-ins. Warren Tiedelman's dissertation did, and the dissertation is titled, Pilot, A Step Towards Man-Computer Symbiosis.

And it was published in 1966, 24 years before the Bracca and Cook paper. This idea that you need to find an earlier paper to show, oh, yeah, actually, this person before you had this idea that you thought you came up with first. And I see this every single week, you know, looking at Hacker News or looking at, you know, something on YouTube or some new framework or something like that. There's this constant parade of people saying, look, we've invented a whole new way to do this or that. There's a lot of things where we're trying to aim for novelty, right? We're trying to aim for, is this a novel contribution to the field, right? I think is kind of like the scientific-y way of putting these things.

And I do kind of agree that I have kind of this skepticism about it, right? I think it's great to do things. There are things that are new, right? Like I'm not going to say nothing is new. There are things that are new. There are things that people come up with that haven't been done before.

But I guess they're almost always combinations of old things and influences of old things that they've done. And I think it's more important that we look at those and figure out how we've modified them. And yeah, I definitely think that there's this trying to be different for difference sake definitely feels wrong to me. Or trying to take an idea that you've had and present it in such a way that suggests that it is an original idea for whatever reason you're doing that. Like, for instance, if Rich Hickey had taken the persistent data structures in Clojure and introduced them as these are persistent data structures.

And as far as I'm aware, that's a term that he originated. And if he had not done the thing, let's pretend it is, right? Maybe it's not, but let's pretend that Rich Hickey used the term persistent data structure because that term had never been used before. And if he did not do the thing where he pointed to the previous work on hash array mapped tries like the the the previous work that had been done that inspired his implementations if he hadn't pointed to that and then instead had said you know hey i've created this new way of storing data and here's what i call it and here's it's this new original idea, like that would have been a kind of charlatanism because, you know, in fact it was inspired by earlier work. And even if he

had even even I'm gonna stop slogging rich, even if somebody comes up with an idea that they personally believe is an original idea, like we all know, know right like your ideas are the things that emerge from the cultural context you're in there's like simultaneous discovery is a thing right this is this is a well explored space i don't want to rehash all those arguments today i just want to say it sucks to see people say things like this is the first scientific paper about mix-ins right that sucks right? And I think that's a major thrust of this incommensurability paper is like, or at least like a minor thrust of it is, it's actually not the first paper about mix-ins. And the only reason you can get away

with saying it's the first scientific paper is because you've done this thing where you've defined practices out of being counted as science because you're defining those practices as being engineering and engineering is a lesser thing that's that's to kind of close the loop on that the reason that this cultural phenomenon that separated science and engineering into two classes is relevant is because it lets people in the realm of science say, we can claim an idea as an original idea that we've had and we're the first people

to present this idea, if not inventing the idea, we're the first people to present it because those other works that presented it earlier don't count because they're not science, they're engineering. That sucks.

Yeah, I think we have to be careful, too, though, on just not committing the opposite sin. You and I both come from pretty practical backgrounds. I don't have any formal education. Jimmy, I come from an impractical background. Yes, I totally understand. I love impractical things as well but you you get my point right like we build things more than we describe things and i do think that there's something there's something legitimate going on here and we're reading from the perspective of somebody who

is frustrated by the way these scientific endeavors have happened and the way they've excluded engineering. And at the same time, I do think that there's works that really did help push the engineering effort forward. Totally. Yeah, I think it's important that we have and I do think that Richard Gabriel would want this, but I think there is a little bit more of this emphasis on engineering needs to help science. And I think that it's got to be kind of this give and take of both, right? We need to have this better working relationship. I've always wanted to have this relationship where you're actually building things. And then as you're building things, there's members of the team who are better

at putting it into rigorous, formal, whatever. But also that that requirement of it being as rigorous and formal could be lessened, right? Because I don't think that formality is always the way you get the interesting bits out there. And I think this paper kind of shows that as well. And not just formality, but another big one. And once again, I'm just repeating arguments

that have already been made before. See, this is me saying I'm not having original ideas. I'm just repeating ideas that are already circulating out there. Originality, right? The emphasis on originality in published papers is problematic. And it would be nice for it to be okay and it to be acceptable to not say,

I'm first, here's a new thought, here's I'm breaking new ground, but to instead say, I have a better way to articulate an idea that somebody else has already articulated. And you can do that, right? You can do a paper where you're doing a summary or you're doing a follow-up or something like that, but there's still this sense that the culture is about, like, right, if you're going to do your dissertation, there's this cultural sense that it needs to be about breaking new ground, that you need to be making a contribution to the field in the form of new ideas. And I think that, you know, other people have said, and I agree that allowing for the quality of a communication to be a benchmark on which we want to accept new

works into the official canon, that like, if somebody can take an existing... If somebody took augmenting human intellect and turned it into a really banging 30-page or 20-page or 5-page condensation of those ideas, that should be seen with just as much value in all the same contexts as the thing that is valued for its originality. I do think that this conversation on originality and not is kind of, I don't know,

maybe ironic, maybe not given kind of the end of what we have here, right? So this is the last paragraph. And he says, not many of us stop to reflect. We're just programmers, after all, or software developers or engineers. And as ants and termites do, we are content to follow where others have gone. And most of us go where most have gone. But when we do reflect, perhaps what we find is important and surprising. And i actually didn't understand that very well maybe you can explain that to me yeah i think i think this comes after his discussion about kind of discovering this incommensurability that had been lurking there that that he he's one of the few first,

I don't know, who do we credit with it, to point out that there's this incommensurability going on. You mentioned before that people could have discovered this, but no one did. Gabriel makes that point. Gabriel is the one who says that Braca and Cook could have realized this. Yes, and yet they didn't, right? And nor did anyone else really articulate

that this incommensurability had started. You don't see in history books. And then in 1990, there was a great break. And we went from programming language systems research to programming language research. This is Gabriel's reinterpretation of history. And so I think he's telling us here that in our day-to-day practice, there's often these hidden things going on that we ourselves aren't seeing.

And we might discover something new if we just stop for a moment and reflect on our own practices and see what's actually going on around us. Yeah, I mean, that ending did not stick for me because it felt a little bit too much like it wasn't saying anything. Like it feels sort of like an and they lived happily ever after, or like just kind of a trite sort of like, hey, welcome to the end of the paper. Just before I head out, I wanted to say, don't forget to reflect on the world around you. Well, I guess, you know, he would, right before this,

he tells us there is no world around us, right? At least not in the sense of programming. We create that world. Yeah, like there's no natural world around us there's no pre-existing immutable uh world waiting to be discovered sorry phil um and uh that the world that we have is the world that we've invented yeah and so i think the reason i don't take this as just like uh a silly little like let's let think more, is I think he wants to say, we have this great power

to create the world around us. And if we don't, someone else will. If we don't create it, we're going to be living in the world that others have done. We're going to be following the path that everyone else has followed. And we're going to miss the richness

that we could have created there but then that makes it sound like and at some point in here we really do need to say like braka and cook we're slagging on their work a whole bunch in a way that they don't deserve right they kind of are being used as an example they're being made an example of a broader set of systemic problems and it's we keep pointing to them as a reference but in no way i think is this meant to be specifically signaling that they are at fault for anything or that they've done anything wrong they're just an example that is near to gabriel because gabriel has a a good sort of perspective to reflect on this this transition that they they were a part of and so it's i think it's just worth saying that like we

don't or at least i don't i'm not going to speak for you jimmy you might have like a you know a torch and and some like t-shirts ready to go here for like brocca and cook out um cook out uh but uh yeah i don't think that they deserve uh uh nearly as much scorn as we are heaping on them and i hope that it's that it's clear that this is meant to be a jumping off point for looking at broader issues not that it's meant to be something where we're trying to discredit them or their contributions individually. No, not at all. And I think Gabriel sometimes does a good job of that

and sometimes doesn't here. This paper was started because Braca came to him about this reaction he had gotten about this paper from kind of the older Lisp crowd. So in many ways, this is Gabriel explaining that reaction. And he is also not claiming here that like, and this is a bad, we should never go this route, right? He's claiming really that they're just like Kuhn does. You can't make this incommensurability, you can't measure them. You also can't measure like, is one of these the better path? There's no way for you to determine by some third party neutral

criteria, which paradigm is better? Is it systems? Is it languages? There's no way to know. If incommensurability is real and that's another like that's in the abstract right the abstract says incommensurability is real that's the second final sentence of the abstract and that's something we haven't talked about which is that there's debate as to whether incommensurability is a real thing and one of the points that gabriel makes is that incommensurability might not be real in natural sciences because there is a truth to the universe that we are getting better and better at approximating and that there are future approximations that can completely supersede earlier approximations and the

only problem where incommensurability might appear is in trying to understand earlier approximations in the correct context that you might lose that there but that within computer science you can have real full strength incommensurability where a future theory and an earlier theory are both equally important and equally valid, and one does not supersede the other merely by coming later and using language to make it seem like it's the more encompassing thing that obviates the earlier thing. Incommensurability exists and is a real issue to contend with because the material of computer science is something we've invented it's something that we are constantly reshaping and that there is a loss when a future theory supersedes an earlier theory or when a future practice because this is very much about practice as much as it is about theory

when a future practice supersedes an earlier practice that you are actually losing things and that you are oblivious to that loss because of the incommensurability because of the difference in interpretation of terms that makes it difficult for you to understand the earlier idea in its true context though one of the things we're kind of like, it was kind of left out of this discussion is Kuhn really is taken to have two ideas of incommensurability. The strong idea that there's literally no way to translate between these, that they are different languages,

different language games, that there's literally nothing you can do to understand the old paradigm other than live it. And then kind of the weak idea, which I think is mostly what we see Gabriel here telling us, which is just that there's a difficulty in communication. It can be overcome with enough diligence, with enough deep thought, but it can sometimes be missed because on the surface, it seems that they're not really talking about different things, but deep down you are. And so a lot of it seems that they're not really talking about different things,

but deep down you are. And so a lot of people, when they're questioning Kuhn's notion of is incommensurability true or not, they're worried about this stronger claim because it seems to lead to, well, what Gabriel calls it is anti--realism and he calls it the idea that science can never figure out what the world is like because we live in a sort of manufactured conceptual or representational world that dictates reality to us it's a little bit of a weird way of putting it to be honest uh the the problems would be more about relativism than anti-realism, that we can't ever know the truth because there is no one singular truth. Or at least that one singular truth is outside the realm of human possibility. And so we all can be equally correct, even if we disagree with each other. That's more

usually the worry about this incommensurability. I just don't know if that argument really lends itself towards the computer science issue here, because I don't think anyone's going to say like, yeah, systems and languages view of things are contradictory. Well, isn't that Wadler's claim? Isn't that like in his kind of, in his playful teasing saying that some programming languages are invented and others are discovered and you can just tell? Isn't that kind of, and not just Wadler, once again, I don't want to direct shade at a particular person. This is just an idea that pervades in our world. Isn't the idea that some aspects of programming are discovered as a result of universal truths, perhaps because some aspects of programming emerge from the mathematical parts of logic and that math is kind of a universal thing, just ignore certain work

in the 1930s, that because there's this aspect of computers that comes from the universe as opposed to that comes from our culture that there is a part of it that is not relative that there is a part of it that does have a real truth that we are trying to get closer to because my my sense is that no pretty much all of the programming is relative and that that there is no universal truth and that relativism in computer science is real is that is that also your sense or do you feel differently i maybe a clarification um so how i take wadler to be making this argument is yes he does agree that there's some objective reality to the facts of computer science uh i don't think anyone would disagree with that like no one no one that i know is

like oh the halting problem is a matter of perspective usually people would agree that that's a real phenomenon uh what they would disagree about is kind of the more the ethical or aesthetic claims going on that you can wadler wants wants to say, first off, yes, there's this like a more objective, let's just say more objective to be nice, more objective part. And he wants to say, and that's better. And that's the claim that I think most people, not most people would disagree with, but that people would see as the suspect part, the relative part is this aesthetic ethical whatever word you want to use their claim rather than the claim about what is yeah that makes perfect yeah when you say that things are relative are you meaning what your taste right you're like your aesthetic judgment

is relative yeah what constitutes good design yeah yeah not whether or not the halting problem is a real phenomenon which i'm also not convinced of but okay i'll give a less controversial that uh certain algorithms are linear and others are quadratic no i still think like i i think you know bigfoot aliens there's certain parts of computer science where i'm going to start a late night call-in show where we can have people call in and say like i was out walking my dog in a field the other night and i i saw i saw a polynomial time algorithm for an np complete problem yeah i i think that that way that you put it makes a lot of sense and and captures what i was feeling yes Yes. Yeah, so I think that Wadler wants to almost say there is an objective matter

about maybe the aesthetic elements, right? It just is, what is aesthetically good just is what maps to logic, right? Well, and this is where we need context of use, right? Because he's not positioning himself, at least in my understanding, as somebody who's really concerned with building databases at scale that's not what he's like when he sets

you know his mind on good versus bad the the particular things that he would think of as good have to do with a very specific context of use and that does not include you know making a react app or something like that so it might even be uncharitable to say that it's like um that the error in his or the the the questionability in his thinking is introduced as soon as it turns aesthetic it might be like generalizing that aesthetic to other contexts where it doesn't apply, right? Because it would be perfectly reasonable to have a strong sense of aesthetics about what makes a good proof, what makes a good formula, what makes a good relationship between abstract ideas, what makes a good logic, what makes a good calculus, that kind of thing. Those kind of aesthetics might be closer to the kind of thing that you can defend as being innate to the universe in the way that we all get warm fuzzies

when thinking about e to the pi i minus one, right? And oh, wait, there's actually a better way of formulating that that is even more aesthetically pure, right? Or things like Clifford algebras as opposed to the cross product, right? Like using geometric algebra as a way to express geometry and relationships and that the cross product is just this kind of like awkward hack

that emerges from, you know, looking at three-dimensional matrix math that doesn't generalize to higher dimensions and therefore is less elegant. Like there's a a context within the natural sciences that aesthetics have a a you know maybe there's some people out there who think that the more complicated less generalizable formula is truly the more pure and beautiful one um but we don't see a lot of people staking that claim but it's

only like when we cross over into what does it mean to design a good system and what does it mean to practice programming and what does it mean to do that lower class kind of work that aesthetics are no longer admissible in the same way yeah i think that's what i find so just to like just to give my opinion on this relativism claim or whatever, if we're talking about aesthetically, it's kind of hard to make a strong argument for like, there is an aesthetics in programming that you ought to have. I do think a lot of people make that claim,

whether they realize it or not. Oh, yeah. Right? Yeah, constantly. Yeah, I think that's a hard thing to claim. But what I want to say is that this, what Gabriel calls the language versus the system paradigm, I don't think even he would claim, if we ignore the like, what is good design portions of it, right? Just the descriptive elements, they're still saying something true. They're still saying something correct, right? They're talking about various facts about how languages work, right? That's their context. And that's just not what Gabriel is interested in. He's interested in how various systems work. And so I think that's where this, the strong notion of incommensurability, where

we're literally talking past each other and there's no way to ever understand each other. I think it just doesn't really work in this case. I just don't think that's at all what we're talking about. Because I think everyone, he's even identified. Here's the difference. You're looking at these formal properties. I'm looking at these dynamic properties, right?

Here's a distinction that you missed in your analysis. Yeah, exactly. And so that's where I would stand on there. I will say I completely disagree with him on the language distinction if he doesn't just mean programming languages. Yeah. Natural languages are much more like a system than they are a formal system of signs governed by grammatical rules of

combination to communicate meaning whereas a system is a set of interacting or interdependent components forming an integrated whole and i would claim language natural language is much more like that second part but i would also claim programming languages are as well. Yeah, he does point a little bit to the fact that these definitions need to be interpreted in order to make them applicable to what he's talking about. Like he does point to the fact that the definition of language includes the word system. And so there's sort of already a little bit of interplay between these two terms. Yeah. I don't think the strong incommensurability is, is what's being claimed here. Um, and I think that the, like the big, big takeaway that I got from this paper is that

I keep wanting to accidentally call him Braca because there's so many names in my head, including all the silly nicknames the uh ricky and and peter and and phil um anyways uh gabriel seems sad that at some point the part of computer science that he was passionate about, which is systems, was relegated to a lower class and languages were relegated to a higher class. And that happened independently of Braca and Cook, but that they were maybe riding on that cultural wave. But that's a thing that happened. We are living in a world that emerged from that happening. We struggle to talk about programming systems versus programming languages, and that all the programming that we encounter in popular culture and when you go into an undergrad degree, it's all language-based programming.

Getting into an environment where you can use a programming system is a rare thing, and it's a niche thing. There's a sadness there that I think is what this paper is sort of trying to say, is that this weaker form of incommensurability leads you to misunderstanding other people.

And if you're in a position of power to be deciding things like what conferences should run, what papers should be accepted, your lack of awareness of what other people mean when they use a term might be a kind of bias that leads you to thinking that they don't know what they're talking about and therefore their work is not worth appreciating and that those this is this is like cultural dynamics once again right everything we talk about to me with my particular lens with my particular blinders on it all looks like culture and it all looks like different cultures misunderstanding one another and that as a result of that the opportunities to do programming systems research disappeared and dried up and were relegated to a form of practice rather than a form of science they were relegated to engineering rather than science and i think the the fact that you know gabriel makes all these points about the

relationship between engineering and science is sort of like a side point where it's like and while we're on the subject you know engineering and science are actually um not at all strange bedfellows they actually have a thriving positive relationship and the fact that we don't see them that way is you know the two genders science and engineering right we we put one of them in a lower position in society and we shouldn't do that um but that's not the the the core sadness that i see the core sadness that i see is that um systems have been demoted and languages have been promoted and that just made for a worse industry in a worse field than otherwise would have here. You know, if we do

that thing in the final paragraph, where if we do try to reflect on what other people are doing, if we open our hearts to them, maybe we will avoid making future divisions of classes accidentally emerge as a result of our inability to understand what other people mean when they say things. Yeah, I think that's a great way of kind of summarizing the paper. So, you know, maybe that wasn't your summary. But for me, I'll kind of, you know, end on some closing thoughts here about this. Like, first off, I think this is a great paper. You know, I like to kind of grade these papers.

So maybe if you don't hear me say it's a great paper, I just don't think it is. And I don't want to say that explicitly. I think this is a great paper that everyone should read. You know, the mix in stuff, I don't really care about objectory programming that much, to be perfectly honest. So I don't know if I'll ever use any of the mix in stuff here. But the the way in which he interweaves this technical aspect and the the more you know high higher level thoughts is just beautiful but i want to just end with a i think that we could take this uh problem that he has and have a different solution i guess he doesn't really offer a solution so i'm gonna offer a solution here uh that i think we could do to like bridge this gap between systems and language.

And I think it's actually to focus more on the language aspect. I think our notion of languages and programming is just so far away from the reality of how natural language worked. We've made this analogy to language and like forgotten that it's an analogy and we don't pull in so many of the rich things that natural language have so just to call out like an example uh like elephant 2000 by john mccarthy is a paper that talks about a programming language based on speech acts and speech acts are these things that have effects in the world. So when I say to you, I promise I'm going to read this paper, I didn't just state a fact, I caused it to be the

case that I now have an obligation to read this paper. And so we if we really want to think about the systems and languages and not not make this divide so great, it's realizing that we have a very impoverished notion of language. And if we started including more and more things of natural language, more and more ideas from linguistics and philosophy of language into our programming languages, we

would find systems out of them. So that's what I think we can find systems out of them. So that's my, that's what I think we can do to bridge this gap. And that's not something explored here, but I would love to see it be done more. We're in wrapping up the episode

kind of summary mode. There was one other thing, and I think it dovetails off what you've just said, that I wanted to tangent on. That's great. Is it too late game to throw in one more tangent? No, let's i wanted to tangent on that's great is it too late game to throw in one more tangent no let's throw on a tangent that's the point of this podcast in my opinion hell yeah this actually ties this paper into our community a little bit i'm going to read a quote this is from the part of the paper where it's sort of introducing some of the older ideas about object-oriented programming. And it's giving some

of the early context for how mix-ins emerged back in those engineering papers that aren't worth being counted as scientific papers. So here's a quote from Howard Cannon, his paper on flavors from 1979. From one point of view, object-oriented programming is a set of conventions that help the programmer organize their program. When the conventions are supported by a set of tools that make them easier to follow, then an object-oriented programming system is born. It is neither feasible nor desirable to have the system enforce all the conventions, however. Since the flavor system provides more flexibility than other object-oriented programming systems, programmer-enforced

conventions become correspondingly more important. Therefore, the flavor system is as much conventions as it is code. That made me realize something, which is that one of the things that we have in our programming culture that we sometimes sneer at is convention. It's things like gang of four style design patterns, or it's things like TDD, or it's things likeile, or any of these sort of practices that we do, these things where it's like, independent of the tools that we're using, we have these ways of using them. And we try to make these ways of using them adaptable so that you can do something like Agile in a functional language, you can do Agile in an imperative language, right? There are these set of conventions for how to program. And in fact, you can think of paradigms as being conventions, right?

You can do things that are kind of like functional programming in an imperative language. It's just a way of using functions. It's a way of if a language has functions, you can do something that is functional programming with it. You can kind of do object-oriented programming in other languages, especially if it's a dynamic language. There are kind of fuzzy boundaries around these different practices that in this quote that I've just read it refers to them as conventions or I'm generalizing from what this quote says to come up with a meaning of convention but the thing that I like about this quote is that it describes the way that the conventions and the tools

interact and that there's the conventions supported by a set of tools that make them easier to follow that's something that i don't see within our community that i think i would like to see more which is that programming conventions programming practices these habits that we create are these cultural things that we create to approach how to program should co-evolve with tools and tools should co-evolve with these conventions. And you get a little bit of that, like, you know, TDD and BDD are a set of tools, right? Test runners and test harnesses and mocking and tools that you can use to help you do testing co-evolve with the testing practice with the idea of you know red then green with the idea of change the test or change the code don't change both at the same

time that kind of thing like there's these practices there that co-evolve with the tools and i think that that example is really cool but there's some other examples where i see people creating a new programming language without thinking about what are the conventions of using this language? What are the cultural aspects that should emerge around this language? Or rather, what's a convention or what's a practice that we want to encourage and how can we make a programming tool that encourages that practice or vice versa if we want a new programming language because you think that there's some problem in existing languages how can you create a convention that creates room for that new tool to emerge and there's this

this this this framing that this quote here from theavors paper kind of opened up to me is this idea that this is a practical way to approach the problem that we've referred to in the past and that tons of people refer to about wanting to change a social problem with a technology and how that's kind of a fraught thing to do and realizing that you can be as much a creator of a convention as you are the creator of a technical tool and that you should in fact probably think about both together and how they intermesh is a really cool thought technology yeah i completely agree with you and i think this ties in actually perfectly with what i was just saying here of like we kind of have this belief that our programming languages are these static things that you know the grammar written down by the compiler interpreter browser whatever it is that does the the running of the code that's what defines it but it is almost always our social context that defines what language we're using. You can think of like, I looked up the Wikipedia definition of language construct, and it says that a language construct is a syntactically allowable part of a program.

Think about, in reality, when you have lenters and code review and et cetera, there's all sorts of parts of your language that aren't practically syntactically allowable because your coworker is not going to let you get away with that. Right. Like you're never going to get it merged. You're never going to actually write it. Like you won't let yourself get away with it. And so like what our languages are gets restricted, but they also get expanded. Like I thought of with your convention talk, like a MVC model view controller right these are things that don't have first-class representations in most languages but yet are very clear you can see them in every language that you're in and we have rules about what

count as these various things and it's really mean, I think MVC has had more impact on whether you agree or disagree with it. It had more impact on how people write code than almost any programming language has. And it's merely a convention. I would say it's had more impact than the idea of mix-ins, say. Yeah. Like mix-ins are important.

The idea of abstract base classes used for multiple inheritance, that's a neat idea. But in terms of the impact it has had on the industry, yeah, MVC, which is not actually part of any language, it's just a way of using languages, has had a bigger impact, I would argue. Yeah, absolutely. And I think that's what we should realize is that not only do these conventions exist, but they actually modify the languages that we're in.

At least I think this is a good way of looking at them. Like I worked in JavaScript code bases, where for all intents and purposes, JavaScript was a functional language, because we didn't mutate anything. We could have, but you weren't going to pass code review almost ever if you did it not because we were like, super strict and annoying but because we all kind of collectively agreed we wanted to have that experiment and see what everything looked like that way and turned out pretty pretty good yeah or like like i think ramda is one of them like there's these functional javascript libraries where it's like there is um within the bounds of what JavaScript allows,

there are nice ways to have currying or there's nice ways to have partial application. There are these things that JavaScript doesn't intend for you to be able to do by design, but that it allows for you to do. And then there are these conventions in which that's codified into this is a required way to work within this convention. Not enforced at a technical level, but enforced at a social level. One that I love is Promises.

Promises are now part of JavaScript proper. And they started as just a convention for a way to use functions. Just to do a little bit of higher order programming with some functions that gave you a nice alternative to callback hell style asynchrony you got some more linear reading code and it's code that maybe looks nicer when you are looking at the the actual lines in your editor um arguably it's a little bit harder to follow in certain pathological cases. I think maybe it's easier to come to pathological cases with promises, but they're now part of the language because the convention informed the evolution of the tool. I think this is a great thing that as a community,

we can start establishing, right? Like even if we haven't built our language, we can use convention as a means to explore things we wanted to. So all for it. Because we're talking about our tangents. I also do think that this... So I want to say that there is a fact of the matter. It's just more expansive than we think. All these things that we're saying we invented are actually things we discovered, and that's totally okay. It's just there's a lot more to discover than we give ourselves credit for, basically.

I'm like a naive Platonist who thinks that there's these objects out in Plato's heaven. And we're that's what we're interacting with on a day to day basis in all of our things. And there's just way more of them than we ever imagine. Yeah, that's a that's a pretty different definition of object than we've been using all along. But I follow. Yeah. So like, you know, when we're talking about mixins like they they correspond to something

that that's out there right even if we have the like goofy edge cased ones or if we have the you know whatever it doesn't matter those all those all exist i don't think that they stop existing yeah the deficiency is that we don't have um nearly enough language nearly enough words to use to map to all of these objects that exist and so we end up with uh naming collisions what we really need is like some way for us to store all hypothetical things that could exist in some kind of a a database with a with a hash of that idea in each of them so that if we need to refer to you know no i don't mean that kind of mix in i mean that kind of mix in we can like you know there's a there's a universal spanning hash table of abstract concepts that we're going

to reference in our discussion yeah so we can refer to a singular canonical meaning of our of our words yes i'm nerdy enough that even in normal speech when i'm not talking to programmers i will uh if i'm having a disagreement about words i'll be like all right we're just gonna call you have your word yeah and then i have my word prime yeah and i have learned that that's not a good way of making a distinction for people. So yeah, I usually now use mix in one and mix in two, right? That's just all we meant, right? But yes, so I do think that we just, I think we discover all this stuff.

And then, yeah, I'm going to synthesize both perspectives, right? It's just all the things you think you're inventing are actually already out there in Plato's heaven. Is Plato's heaven a thing? This is a reference I don't get. Yeah, so Plato's heaven is the idea that abstract objects like shape, right, or numbers exist. So we've never seen the perfect triangle, a triangle that's actually

the ideal notion of triangularity, right? So you could imagine like, let's say like an equilateral triangle, right? That has a perfectly equal sides and perfectly equal angles. you can't make that in real life it doesn't exist yeah but uh it clearly does exist in some sense and there's also like triangle-ness itself like what is it that all triangles have in common right and so plato wants to say that that's that's the real stuff of reality and our reality is just a shadow of that i don't go that far but that that's plato's idea that's like the question like are there holes right is a hole a real thing or not yeah those are kind of related a lot of it's about just like a lot of the conversation is ultimately about like numbers right do numbers exist or are they made up by us? And if they're made up by us, how are they made up by us?

How could we ever discover them? But if they do exist, how do we discover them too? Because like, do we have, we don't have a causal connection to them. It's not like, you know,

I can walk down the street and two bumps into me. Where's five? Have you seen five recently? Yeah, exactly. Right. But if you start trying to go down this path called nominalism, where, so there's plate Platonism and nominalism, there's others, but nominalism says like, no, those things don't exist. There are no numbers. If you start going down that path, you start having some, some linguistic issues, but also just some like, some real problems using talking about numbers, if you think that they don't exist.

Because like, for example, saying there's a number between four and six, that's just a false statement. And if that's a false statement, then all of our scientific statements are false because they always decomposed to depend on some statement of that kind of sort, right? Depending on numbers and relations and things that just don't actually exist in your world. Well, I'm going to be thinking about that all day. I mean, there's great books and things like this. I love it. That's the kind of philosophy that I really enjoy

is thinking about, yeah, all these sorts of like uses of language and the ways in which we talk and what that commits us to. Yeah. If I say there is a number between four and six, doesn't that imply that I think there are numbers? But I could say like Adam gave kiss a Steve.

Oh, sorry. Gave kiss a Steve. Gave Steve a kiss. Gave kiss a Steve. Adam gave Steve a kiss. And that seems to commit me to kisses being an entity but i could just change my word around adam kissed steve right and now i'm not committing myself to anything and so this is that a notion that if we can you're only committed to the things you can't paraphrase away. And so if you can have a more rigorous way

of paraphrasing something, of restating something, then you're not committed to that entity existing. And then the question is, can you make a paraphrase that gets us all of the things we want scientifically and mathematically without using entities that are themselves suspect by some standard here and so far no one's done it and i don't think anyone ever will yeah so in the case of nominalism it would be like that the thing that is suspect is the existence of numbers so can we paraphrase all science that is predicated on

the need for math yep to not have a need for numbers. Yeah, so like Bertrand Russell wanted to say that the numbers are, like the number two, for example, is defined as the set of all pairs where he can make pair not depend on the number two. So if we just have the set of all pairs, that is the number two. We've now defined it in terms of concrete physical objects the

question of course is are sets a real thing are sets abstract objects or are they just their members are they something above their members but then also the reason russell's doesn't work is it literally and he's fine with this depends on there being an infinite number of physical objects in the world because otherwise the math breaks down i didn't uh i didn't know that i mean i know about the girdle incompleteness ripping russell's ideas asunder but i didn't know about that aspect of it that failure yeah so he's he just says yeah we just assume there's an infinite number of things which to me seems clearly false can and is that like an infinite number of physical things or can that be like a conceptually infinite okay well uh yeah no because that's the whole thing

we're trying to get rid of right is the reality of conceptual abstract non-physical non-spatial temporal objects so that's why we're getting rid of numbers uh-huh because they're i thought it was just like a weird flex like it's tuesday i'm gonna get rid of numbers no it's because you can't scientifically they're not scientifically rigorous we can't point at them we can't poke at them we can't prod them and measure them right and so this all gets into positivism where uh things are meaningful if and only if they're scientifically verifiable. Blah, blah, blah. And I'll mention these things, I'm sure, because most of this computer science belief about these things are holdovers from positivist attitudes, in my opinion.

Only if I can put it into my format does it work. There's a good little story, I'll end on this one, that I think really summarizes this kind of attitude well. A door-to-door vacuum salesman comes in and knocks on somebody's door and is trying to show them how great his vacuum is. They invite him inside to let him show how great the vacuum is because they really need a new vacuum. And so he sprinkles some dirt on their carpet

and then vacuums it up. And they look and they're like, no, there's tons of dirt right there. Still, you just put dirt all over it and the vacuum didn't get it. And the salesman replies, well, if this vacuum doesn't pick it up, then it ain't dirt.