No Silver Bullets
So much going on in the world, Steve.
Speaker 2:Yeah. I know. I got all these people trying to tell me that Cobalt does pay very well, on Twitter right now.
Speaker 1:I I woah. What was the context of that? Did you Are you going to answer that?
Speaker 2:Earlier today, a discussion with some people, over chat, Kobo being like, the meme of, like, Kobo being a good job you can get paid for heavily came up. And one of my, like, more high harm more harmless conspiracy theories that I believe in, not that I believe in harmful ones, but, like, a conspiracy theory that happens to be harmless and not something terrible is that COBOL is not actually a well paid profession. It's just a thing people say. Because, like, if you try to go look for a high paying COBOL job, they're like, oh, yeah. It pays extremely well.
Speaker 2:Like, we pay $50,000 a year, which outside of the context of software is a great job, of course. All But this is the, like this isn't the, like, don't learn rails because the banks pay for COBOL programmers extremely well because there aren't any of them anymore. Like, I can't actually find evidence that that kind of job exists other than a couple unconnected, like, anecdotes. You know? But, like, if you like, okay.
Speaker 2:The the mean salary for a COBOL programmer in Austin is, like, $70,000 a year or whatever, for example.
Speaker 1:And are you certain that this is not denominated in $1963, which would actually be real. Yeah. It's it's possible. There's a local, hot dog joint here in the Bay Area. Should we go to Top Dog?
Speaker 1:Steve, you've been out here doing the Top Dog?
Speaker 2:Not been to Top Dog, but maybe in a couple weeks whenever I'm out there. Well
Speaker 1:I don't know I don't know that it's worth it. Top dog is kind of an experience. So it is run by an ardent libertarian, an ardent libertarian of admirable purity that I feel like that I feel like we were all once. Know, it's like, wow, this is like me when I was 13, just like straight up. And, and then there's, so there's kind of like this libertarian propaganda, around the hotdog joint.
Speaker 1:And if you wish to pay for your hotdog in the currency from the last year in which silver was actual proper silver was used in the coinage, which I believe is 1969, then you can pay 1969 prices. So if you wish to pay for a hotdog with a dime, you can do so. It just has to be a 1969 dime that has silver on it. And so that may, I was, I'm wondering if the Copel programmers, it's like, no, you get $30,000 a year in silver. It's actually no, it is.
Speaker 1:It's a great gig.
Speaker 2:I feel like it's a good sign for this podcast that both of us had to immediately take a step back and qualify a statement halfway through like the first sentences that we both said.
Speaker 1:Is that wait a minute. Is that foreboding? I feel like I'm
Speaker 2:I said I think it's good foreboding, but Oh,
Speaker 1:you said the good for voting.
Speaker 3:It is. It is.
Speaker 2:Yeah. Yeah.
Speaker 1:It's It's good for voting. Okay. So, we so, I the Adam is, attending to sick children. Adam very much wants to join us, but is, his household duties have called. His nurse duties have called, and Adam is is, of course, doing terrific work as a parent that they're they're attending to to to the ill children in this household.
Speaker 1:So, Adam, to a speedy recovery for all in your house. Okay. So we, we got here so the the the tweet here is absolutely nothing that we're talking about Fred Brooks' classic. But, of course, it isn't actually aprobe of absolutely nothing. In fact, it's it's it's the opposite of that.
Speaker 1:What what is a podcast episode that is a subtweet, Steve? Do we have a is that a sub episode? What do you call that when you have the entire podcast episode as a subtweet?
Speaker 2:I I mean, aren't most podcasts kind of sort of subtweets when you're
Speaker 1:talking about it? You know? Yeah. That's the that's true. I so okay.
Speaker 1:So and I think I definitely some people were hitting me up about, like, what have you been, like, subtweeting so much about? And so just to be just kinda have it out there. So, we're all kind of, so it's actually not what we're gonna talk about, but, I this this is actually important context. So a, a company, Red Planet Labs, is going to announce, tomorrow at 10:59 AM, a time that comes up quite a bit, that they will be, releasing a programming platform that promises 100 x programmer productivity. And, I think it's fair to say that I personally am skeptical, but that's not important right now as airplane might say.
Speaker 1:They I I am skeptical. I also and by the way, I think there is absolutely gonna be real technical depth to whatever they announce. I like, there will be technical depth for certain. And the question is, is it a 100 x program productivity? And, also and I'm sorry, Steve.
Speaker 1:I just I I I can't I know. I I I would like to think that I'm above this kind of a pot shop, but apparently, I'm just not. In the email that they sent out to folks in their email list, they believe it is the biggest paradigm shift in software engineering in at least 30 years. As if the internal debate was, is this the biggest paradigm shift in 30 years or 60 years? And they kinda split the baby with at least 30 years.
Speaker 1:So you know what? Who knows? It's possible. But maybe it's impossible.
Speaker 2:The part to, like, bring this up is basically, like, this is not what we're gonna talk about for the episode, but this is what got us starting to talk about. Like, what does the 100 x platform? Like, how would you evaluate if this claim is true or false?
Speaker 1:How would you evaluate if this claim is true or false?
Speaker 2:And That means you have to get into, like, what does it mean to try to, like, enhance someone's productivity a 100 x?
Speaker 1:What does it mean for a 100 x? I also would like to say that a 100 x is the new 10 x. I swear when I was coming up, this was 10 x. And this paper only talk Brooks's classic does talk about factors of 10, not factors of a 100. We actually did a 10 x on our 10 x, literally, to get to
Speaker 2:years. They did they did one ten x a year, and so
Speaker 1:it's gonna be a 100 x total. That's right. Which is I mean, I think it's fair to say, like, step function in the software engineering paradigm. And, you know, as someone had kind of mentioned this that, the like, hey, this is, you should go back and reread, No Silver Bullet. And how do you Steve, have you read No Silver Bullet back in the day?
Speaker 2:No. I was required to read it as part of one of my earliest college classes, and, like, I hadn't seriously revisited it since then. I mean, obviously, there's sort of, like, the memeified way that we take a lot of these texts and then kinda, like, you know, talk about their conclusions without going back and reading it again. But, like, I hadn't until this morning, when we were talking about this, I hadn't, like, revisited it at all.
Speaker 1:It I was in the exact same boat. I had not revisited it. One thing we do need to revisit this quickly because Ashley's asking in the chat, about split the baby, and now I'm very concerned that split the baby is not enough of a popular idiom to be for me to be using it as casually as I'm using it. Is
Speaker 2:I thought you were mixing metaphors between splitting the difference and, like, the parable of the judgment of Solomon or whatever.
Speaker 1:I think that's right. Yes. Thank you. And thank you for being willing to chalk up to basically just linguistic incompetence. The, the oh, the the the baby in the bathwater, splitting the baby in the bathwater.
Speaker 1:Yeah. I kind of had split the difference and but I feel like we talked but splitting the baby is like the compromise. That's not a compromise. I don't know. It's it it alright.
Speaker 1:It's I I think I need to stop dissecting this. Let's just say it was it was not the the the the bone ball.
Speaker 2:Way to explain a mixed metaphor is to mix even more metaphors in there. You start, you know, making a good metaphor stew, and then everything is very comprehensible.
Speaker 1:Little metaphor, booyah base. A jambalaya, as Adam would say. We got a proxy Adam in absentia. I believe that Adam would say that it is a metaphor jambalaya. So, Adam, hopefully done right by you by representing the jambalaya.
Speaker 1:So, yeah. Steve, I was in the exact same book. I think I'd read this, like, I guess as an undergrad. I know I read the mythical man month, like, some number of years into practicing as a software engineer, but I basically had not gone back and read it since. And just so just read it effectively recently with all this coming up.
Speaker 1:What do you think on the reread? What what was your take?
Speaker 2:So I think that this is classic Fred Brooks in the sense that when I read his stuff again now, it is, like, so on the money for so much of it. It feels, like, contemporary, but then there's just suddenly an example or a detail that's, like, clearly it's very old, and it sticks out, like, even
Speaker 1:more than it would otherwise. And so it kinda, like it's it's a very, like, emotionally jarring, like, otherwise.
Speaker 2:And so it kinda like it's it's a very, like, emotionally jarring, like, thing to read because, like, so much of it seems like it could have been talked about last week. And then he's like, well, of course, you know, there's not enough screen room to see more than one document on a screen. So, like, you know, nobody's really gonna be able to do that. And you're like, wait. Hold on a second.
Speaker 2:Like, I thought we were talking about how AI is not going to, like, make programming better, you know, at the time or whatever.
Speaker 4:So that's He
Speaker 1:is like a time traveler that actually doesn't wanna get caught. But a care a painter, like, trips up every once in a while and says something that reveals his true origin. Like, wait a minute. Like, you from the I think and mythical man of this this way too. So that's asking in the chat, is it worth the read?
Speaker 1:I do think it's worth the read, but you definitely have to factor out the bid on secretaries. Do you remember this, Steve? Where there's, like Yeah. There's a whole chapter on, like, what the secretary should do, and I'm, like, yeah. We don't okay.
Speaker 1:No. We do no. That's not that. That's that's not traveling as well. Yeah.
Speaker 2:I mean, I think part of also, like, in terms of something worth it to read, like, it's it's, like, 15 and a half pages. You can read it relatively quickly. So I think it's worth reading just because it's it's not like you're, like, is it worth watching all the extended Lord of the Rings movies? Right? Like, you're not taught you're not putting in a lot of effort for what you're getting out here.
Speaker 2:So I that the the worth it is very clearly on the side of, yes, you should read this.
Speaker 1:Yeah. I think it's worth being aware of. I think that this essay is actually I again, it didn't, like I I just don't remember it really sticking with me. But the the essay I think the essay is arguably, like, the best part of mythical. I mean, if you're only gonna read one part of mythical man a month, like, this essay is not bad.
Speaker 1:It travels pretty well, and there are some things you just, like, get, like, wait a minute. Okay. Did did you just refer to Constantinople? We don't actually call it that anymore. But it's, I think it it broadly travels pretty well.
Speaker 1:You know, I was looking for, other kind of discussions online. And, actually, it's funny. I found a a podcast called the Future of Coding, which I I had, in my queue before but not listened to. And they did a really in-depth discussion of it that I enjoyed. It was super long, like, 4 hours long.
Speaker 1:And I gotta say, like, I would I was starting to listen to it as I'm in, like, Costco, buying a bunch of stuff for a scout barbecue yesterday. And, the they they talk about, like, you know, well, it's a first podcast of the year we should make predictions. So I'm thinking to myself, hey. We make predictions. That's cool.
Speaker 1:I know the podcast makes predictions. And then they're like, yeah. You know, I was listening to the Oxide Friends, and they make predictions. Like, hey. Wait a minute.
Speaker 1:That's just what they're talking about. That's really neat. So Future of Coding folks, thanks for the shout out, and, really enjoyed listening to your podcast as well and the discussion there. It got very philosophical. So, Steve, I don't want you I I think of you as more than just my go to for philosophy.
Speaker 1:I want you to know that. I just want I don't want you to feel insulted that I exactly. That you're, you're not just the the the the philosophy role player around here. But
Speaker 2:It's not just when your co host is sick and you need a philosophy person. It's more than that specific service.
Speaker 1:I knew that was gonna come up. Look. Look. Okay? I, okay.
Speaker 1:It's true. But here we are. Look. Here we are. Let's just make the best of it.
Speaker 1:You know? So so it it they were really into kind of the, the Aristotelian, dichotomy between, the, the accidental and the essential, And as a kind of the thrust of the paper. And I didn't quite infer that as the thrust of the paper, but I don't know. But then it did cause me to kinda go back and reread it more closely. Would can can you give us some key philosophies to use that on demand?
Speaker 2:So, this is not exactly what they said, but it's close enough, and I think it's a good way to ease into it. So I'm gonna start slightly somewhere else. The, Larry Wall has this idea called the water bed theory of complexity. Now I don't know if you've ever been around a real water bed, but if you push onto one side of a water bed, it makes the other part rise up. Right?
Speaker 2:You have a bunch of water inside of basically a giant balloon. And so you the the, like, amount of cushion doesn't disappear. It just gets displaced into a different area. And so Leary, like, really strongly believed that with complexity, there's, like, essential complexity and accidental complexity, which this also makes reference to. I'm not sure if he got it from here, or if it's just a, you know, similar thing or whatever.
Speaker 2:But the idea is kinda like there's there's some parts of problems that are just they just are complex, and it's not actually possible to simplify them. It turns out that the real world is a messy place, and complexity exists. And therefore, you know, you can't really get rid of that complexity. You can only move it around into different places. And so I see this come up a lot when discussing, for example, like, why some people talk about why they don't like the Go programming language is because Go kind of says, you know, like, we can introduce this simplicity.
Speaker 2:And a lot of people will say, well, no. I don't actually believe that it's reducing the complexity anywhere. It's just moving it to other places. And so, you know, you get endless on our arguments. And so, I thought this section of no silver bullet was really interesting because, you know, they they also talk about this general idea of, like, there's sort of this there's parts of a problem that are irreducibly complex.
Speaker 2:And I I liked specifically not just because I went and saw Oppenheimer 3 freaking times and Einstein is part of that, But, like, they they make reference to this, Einstein quote. Let me for this real quick because I should have say that before. Yeah. So, like, Einstein repeatedly argued that there must be simplified explanations of nature because god is not capricious or arbitrary. But no such faith comforts the software engineer, which I thought was, you know, pretty solid, like, you know, and so they get into this kinda like, where can we if we're trying to simplify things, like, can we even stuff and all that?
Speaker 2:And I thought that was, I thought that was pretty pretty good.
Speaker 1:Yeah. I thought that was great, and it kinda gets to the I mean, I think Brooks is, to me, Brooks is fundamental thrust is against those that kind of offer these single solutions. Because the his kind of point is if you don't attack the essential complexity, and you only attack the accidental complexity, the upper bound on what you can do from a productivity perspective is the elimination of all accidental complexity, which is not enough to give you a factor of 10 increase, unless you're spending 90% effort on accidental complexity, which I thought was, like, I mean, that's a Yeah. Good point.
Speaker 2:Amdahl's law style argument, which I I continually cite is, like, the most important useful thing I ever learned in my computer science degree is Amdahl's law, which is
Speaker 1:Yes. Gedi Amdahl. Yes. Absolutely. The and I actually, you know, it caused me to reflect.
Speaker 1:I'm sure you as well, Steve, in terms of, like, I have to take something like Rust. Rust really eliminates a lot of the accidental complexity, and you are left with the essential complexity. In fact, you're staring the essential complexity, like, dead in the eyes. I felt
Speaker 2:I think on Russ's best days, that is true. And it's not always you know, that's the aspiration. Right?
Speaker 1:Like, I
Speaker 2:don't think it always lives up to that, but that is that is where a lot of the complexity does come from. It's like, well, just turns out this domain has some irreducible complexity into it.
Speaker 1:Yeah. And I think I mean, even when you think about, like, something super basic, like, how does this, function return an error? And the you know, Rust really forces you to to confront that accidental complexity, and and kind of you you gotta boil it down to the essential complexity. Like, you're not allowed to actually like, no. We're not gonna use sentinel values.
Speaker 1:We're gonna actually have some types, and you're actually gonna do this in a way that you actually have to go deal with it. Actually, it's just your strengths, totally. Oh my god. And there's so many times when when I especially when learning Rust, when Rust felt really really pedantic, you're like, oh, Jesus Christ, Rust. It's like, come on.
Speaker 1:I mean, it's like, you know, yeah. I mean, I you know, you're technically right. But, gee, I can't we just, like, can't we have this one slide? And then you realize, like, no. No.
Speaker 1:This is actually forcing me to deal with what I'm actually doing and the consequences of my actions and what is the essential complexity here. So I don't know. It did cause me to kinda rethink it.
Speaker 2:I think it also feeds into a lot of the beginner anxiety when learning Rust because when, you know, virtually every function that you call returns a result, and you feel like, oh god. Do I gotta figure out how to handle all these things? You know, they're sort of like, kinda almost wanna make those, like, bell curve memes where, you know, where you start off, you're just calling unwrap on everything because that is, like, I'm overwhelmed by this complexity. I don't, you know, need to think about it. I'm just gonna blow up on any error whatsoever.
Speaker 2:And then kinda when you get to be an expert, you're like, yeah. Just toss question mark on it because I don't need to handle the actual area here. I don't care what kinds of areas they are. Just, like, pass it up the stack. And then there's kind of the middle area where you're learning and you're like, I didn't realize that, changing the current directory of a process could fail.
Speaker 2:Like, I Totally.
Speaker 1:I didn't I didn't know that was, like, a thing
Speaker 2:that could happen, and now I do. And, like, oh god. There's, like, 15 different ways that this function can fail and, you know, figuring all that stuff out. So, yeah. So I think it's and I think that, like, that's where a lot of the folks that are trying to either improve Rust directly or come up with successor languages to manage its complexity.
Speaker 2:Because there there are some folks who do believe that Rust's complexity here is not actually accidental, or is not actually essential have several strategies for trying to reduce it, and I'm excited to see how those, like, develop, further on in the future. So we'll see. But yeah. Totally.
Speaker 1:Yeah. That's interesting. And, actually, I think you can get, like, a kind of that that interface between the accidental and the essential. You can there's definitely debate to be having which is which. But I also feel that, like, at the extremes, it's very clear that, like, no, no, this is accidental, or this is essential.
Speaker 1:And I feel that what Brooks is addressing is, like, the the things that are gonna really take a big swing at that accidental complexity are the things that are gonna kinda hit this stuff that is indisputably accidental. And I mean and there and there are
Speaker 2:To, like, to to make the argument, Brooks kinda makes in some parts here. If you made the borrow checkers trivial for every programmer, Rust would still have things you would need to learn about it. It's not like you would be
Speaker 1:Yes. It would
Speaker 2:be a 100 times easier to learn Rust if the baro checker was just trivial. Like, there would still be a bunch of different things that, you know, depending on what your background is from, you may not have dealt with before or, like, all sorts of other things. So, like, even that would not necessarily achieve, you know, the goal of a order of magnitude improvement in a ability to learn Rust.
Speaker 1:Totally. And I think that and and, actually, the thing that impeded my own ability to learn Rust is I was trying to port something from c to Rust. Something I rather I wasn't porting it per se. I had implemented it in c, and I wanted to to reimplement it in Rust. And I had I mean, it's I was truly latching on to my accidental complexity and trying to implement it the same way I had done it in c, namely with a doubly linked list.
Speaker 1:And Rust Rust does not want you to do that. Rust is like, you need to leave that accent that is accidental complexity, my friend, and you must leave it in the past now. That is we we need to get to the essential complexity of your problem, and we need to get you must wanna compile our message that tries to coax someone out of their accidental complexity. But I was really latched on to this implementation detail that in hindsight was accidental complexity even though I don't think I would have thought it at the time. You know?
Speaker 1:And I thought that was, like, so eye opening about Rust. It's like, oh, wait a minute. That actually is accidental complexity. And what is the essential complexity? What am I trying to do?
Speaker 1:And what would I do were I not concerned about performance? And I put that in quotes because that Rust program outperformed the c program, which is totally surprising. But I I just think it's really interesting to kinda, like, take the like, look back on Rust as taking on in particular this accidental complexity. But on the essential complexity, I mean, it's not like you're on your own, But, like, you know, kind of hard, you know. It's like, I I don't know that Russ really, aspires even to take on that essential complexity.
Speaker 1:I think it it really aspires to get all of the accidental complexity out of the way. Is that is that a misread?
Speaker 2:I am unsure. I definitely think that some people would think that. I don't know to what degree it's being accomplished if that is an explicit goal, but also I have been sort of out of the loop for long enough that I'm not entirely sure what current leadership's thinking is on this topic exactly. I do think it's really interesting that we sort of I mean, obviously, we latch on to Rust because it's a thing that we both love, and, you know, this is the Oxide podcast after all. But, like, the number one thing that Fred Brooks is like so I was gonna I was gonna ask you what you thought the, like, most jarring example and the most cart current day example things would be in this paper.
Speaker 2:And I think one of them to, like, half before before you get into your picks, just to transition so we start talking about Rust stuff, like, the number one thing under the hopes for silver, is ADA and other high angle advances. And I think this one kinda walks the line because it's very old because it's sort of like, we'll see if this ADA thing shakes out shakes out or not, which, you know, we know now the degree to which ADA has shaken out or not. But, like, you could today write the same section and turn the examples into Rust, and I'm pretty sure I've, like, read it as a Hacker News comment before. And so it is, like, very interesting to me that, you know, one of my favorite, maybe not literal silver bullets, but let's just say, you know, 60% silver seriously wounds werewolves instead of, you know, totally getting rid of them is one of the things that Brooks is like, nah. Totally worthless.
Speaker 1:In terms of ADA itself or
Speaker 2:the Well, he says ADA in other high level languages. Like, his argument again is this 80 20 argument where, like, he basically said, like, going from assembly language to structured programming was the 80% increase in, like, programming languages as a way to tackle these problems. I forget
Speaker 1:But he does he does actually he ends up being in terms of talk talk about object oriented programming, he thinks that object oriented programming does do this ultimately. That it's not a silver bullet, but it is a hope for silver in that it actually so I think he's he's kinda got both sides here in terms of, like, I think the ADA thing okay. So hot take. I think he may be taught even though he says ADA and other high level languages, I think that may be a reaction to ADA itself. And I think that ADA hurt itself by being too preachy.
Speaker 1:I think 80 ADA and I think, you know, I think we all have kind of a natural resistance to the the Rust evangelism strike force, and people talking about, you know, rewriting everything in Rust, and kind of the the damage that they can do when something is kind of being sold as a magic bullet. And, Ada was sold that way. I I and definitely, observatory programming was sold that way. I mean, it was absolutely sold that way in the nineties especially. And and then Java was absolutely absolutely sold that way.
Speaker 1:Java was the magic bullet. And, you know, Java was really important in a lot of ways. I mean, obviously, but the, I think that it was a mistake to think of it as a magic bullet because it didn't actually it it it it doesn't it didn't actually solve all problems. So, yeah, I thought the so I was wondering to what degree it's a itself. He clearly, you know, he did a papers we love.
Speaker 1:I don't know if you caught any of that. So one thing that is funny, I get, did you watch any of that by any chance? I
Speaker 2:did not, have the chance to watch any of that.
Speaker 1:So okay. So I'm just gonna tell you. So you can make your own informed choice. You will be eating the fruit from the tree of knowledge and good and evil by watching that. I have you have you ever heard Fred Books Creek before?
Speaker 2:I don't believe
Speaker 1:so. Oh, oh, I don't I I would say that if you if you're not sure, you definitely haven't. The guy has got a crazy syrupy southern accent. Like super syrupy, which is like the result of which it's and he has and there's no love lost between him and Ada. That thing is, like, recorded.
Speaker 1:He's, like, 88, and he is, like, still going back for more with Ada. He's still just, like Wow. Yeah. So he definitely is like, ADA definitely rubbed him the wrong way. He also there's also a really good and interesting point about that.
Speaker 1:He's like, you know, in the responses to my essay, I noted there were many people that said, I have a silver bullet over here, but nobody said, this is the silver bullet I'm using over there. I know I sound like I'm an antepalom.
Speaker 2:That's wonderful.
Speaker 4:Honestly, it
Speaker 2:makes the whole podcast already as far as I'm concerned.
Speaker 1:Oh, it is but he I but I thought it was actually a really interesting point that he was making that, like, hey. That's funny. Nobody is talking about the silver bullet of someone else's that they're using. Oh, it's always your silver bullet. Uh-huh.
Speaker 1:That's It's
Speaker 2:it's always the snake oil snake oil salesman and never the snake oil affiliate marketing.
Speaker 1:Totally. It's never the snake oil testimonial, is it? It's always the, it it is. It's always to say well, and I think that, like, that is, like, part of the issue is that like there we have so much abstraction that we are, and we get mired by it and frustrated by it, that somehow all of it does leave us amenable to oversimplified answers. And sometimes those are oversimplified answers that we think that we have found.
Speaker 1:Like, I have found that this this thing that has been important for me is gonna be revolutionary for the universe. It's like, well, it's actually important for you on this problem. Maybe it's not as revolutionary. And I don't there's something about software that does leave us leave leave us kind of amenable to this kind of stuff.
Speaker 2:You wake up one day and suddenly you've got a fuzz biz enterprise edition. I don't know if you've seen this before or not. I pasted it into the chat, but it's like, how could we write FizzBuzz in the most, like, enterprise Java way possible? Like, there is, like, 7 config files and, like, yada yada yada. It's really it's really something.
Speaker 1:That is that is pretty funny. Hold on. Trying to get you up here and, sorry. I wanna get wanna give other people's take on this as well. The, so Steve, you're asking about kind of, like, the in the specific technologies.
Speaker 1:Because it is amazing that some of this stuff just feels super current. So, okay, one thing he talks about as, like, the I I think this paper is misperceived to be pessimistic. When he's like, I'm not saying that the improvement is not possible. I'm saying it's not gonna be a single thing that is that that yields that improvement. And in particular, because to me, like, what this is really before, and the thing what this predates that totally changed software is the combination of open source, the Internet, and distributed version control.
Speaker 1:I argue that those three things together did fundamentally deliver a big multiplier. Is it a 100 x? X? Is it a 1000 x? Is it 10 x?
Speaker 1:I don't know, but it's big. It ain't small.
Speaker 4:Keep in mind that at the time that he wrote the essay, he also was no longer writing software for IBM. He'd already transitioned away from being a professional software engineer to being a professional educator. So the things that he's talking about is also from, some time prior, and he put like a decade long proviso on the prediction, so he was explicitly saying, Yeah, within the next 10 years we're not going to get a 10x improvement. But I would note that I think that the the real interesting insight is that like just the ratio, right? It's like is is what we're doing right now 9 tenths accidental If it's, you know, less than 9 tenths accidental complexity then there is no way that we can get a 10x improvement because there's not you know 90% of work that we can just throw away which, you know it's I think the thing that I was kind of curious about reading it was like, thinking about it from the lens of a single programmer versus a team of programmers or a company of programmers, and where the complexities lie in the in the communication between individuals, because the, you know, 9 tenths likely bears out over the course of an individual, but over a team, there's some real interesting stuff at play.
Speaker 1:Totally. And that's a very good point, and I think things that allow people to collaborate more easily can get to these big multipliers. And that is what, like, open source Internet distributed version control together, They allow for a much better collaboration. And, Ian, to your point, you know, we talked about it when we had, David Crespo on and and Justin about how the open API and using Progenitor allowed them to much more easily they didn't have to guess about what the actual specification was, because the specification is derived from the patient. So, yeah, I think that that that's a that's a good point in terms of, like, the all the complexities that come from operating on a team, which and so, Ian, do you think that, of these kind of, purported magic bullets from the past, how many of the ones that have been how many of them have kind of addressed that element of it, that kind of team complexity element?
Speaker 1:Oh,
Speaker 4:I think that there's been a few like, I would note like in the paper Cooks talks about buy versus build and the fact that over time you'll the best thing to do is likely to buy a module off the shelf and use it rather than write it yourself because of just how expensive it is to produce software, and that, you know, he missed at the time, in the, you know, the the
Speaker 1:Like, he did open source in 19 86, but yeah.
Speaker 4:Yeah. Exactly. We and, you know, he's also still talking about the next decade, so he was pretty, you know, on the on the money there, but like in the year since then, yeah, I mean open source has definitely made it significantly easier to buy at, you know, 0 monetary cost on day 1, an open source module off the shelf that can do some of what you, what, you want and that and the assembly of those modules is kind of a big part of how we write software today, by and large, you know.
Speaker 1:So, you know, you kinda got me thinking here about, like, this essential accidental complexity, if you will, of the team dynamic, which is this really important complexity in the construction of software. And as I'm just, like, thinking about, like, what are these big, big, big step functions? They are things that either deliberately or either essentially or accidentally do address that complexity. It the in other words, like, the the presence of open source Internet distributed version control actually allows us to meaningfully collaborate as a species in our fight for the light cone against the AGI. But the it allows us to actually meaning to collaborate.
Speaker 1:And then I think that with the, you know, the the obviously, distributed version control just allowing for much easier collaboration. It's gotta have a kind of a a collaborative angle to it. You know what I mean?
Speaker 4:Oh, yeah. It's gotta be a way for multiple engineers to be more productive working together or be able to align the challenges in, relying on another team to do work on your behalf and, you know, erecting, API boundaries between those teams and the the efforts of those teams such that, you don't have to know as much about what's going on behind the scenes, and you know there's things today that are incredibly effective at that, like s3 is an amazing API for, determining, for like abstracting over storage. You don't need to know that your, your files are now stored on you know a 1000 or 10000 or 100000 or a 100000 or a 1000000 hard drives, that's all kind of hidden behind the API and all that effort is hidden behind the API, and I feel like, you know, that's an extremely effective example of like how this can work, to be able to allow a small group of programmers to, deliver software capability to a significantly larger audience and
Speaker 1:Yeah. That's
Speaker 4:it. I suspect that stuff like that is where where there's some real interesting games particularly in this, like, that's in the large and I kind of wonder how much of that can be scaled down to, like, within an individual company when you have, you know, teams relying on platform teams to deliver capabilities and how you can get those, delivered more effectively.
Speaker 1:Yeah. And that's a really interesting example because with s 3, s 3 took a kind of radical approach that anyone versed in storage would have counseled probably against, which is, like, yeah, we're not gonna actually allow for partial updates. We're not gonna allow for partial rights. Would you we're just seeing, like, what? Like, no.
Speaker 1:Any storage system has to allow for partial partial updates. They're like, we don't think so. And that was a big gamble and a big win. And it's interesting to think about s 3 as one of those technologies. Steve, one of the ones I've gotta ask you about, because I think, like, one of the ones that I've seen in my lifetime, I think Rails was a was a really big deal and was a really big step function.
Speaker 1:And it I mean, you
Speaker 2:know a big enough step function, I basically quit my job. Like, I was like Yeah. I was like, I I mean, I was currently at I was currently. That's pretty funny. At the time, I I was at an internship, writing PHP, and it was fine, but I saw rails and saw rails happening.
Speaker 2:And when I brought that stuff to, like, work, I was like, hey. We should, like, consider doing these things. And they were like, no. And I was like, okay. I'm gonna do something else instead.
Speaker 2:And I went and I started a startup so I could write rails.
Speaker 1:Yeah. I
Speaker 2:was like, that was like. And it was extremely fast and, like, so much easier to get going. You know, I got a lot farther than I would have at the time, especially to 2,009. So, you know, a lot of the current technologies didn't really even exist at that point, and and Rails was super fantastic.
Speaker 1:I was gonna ask what year it was because the DHH video is 2,005. Is that right? I think it's 2,005. And I actually wanted to go back. I didn't get a chance to rewatch that video before today because I It is difficult to find on the Internet, but I can't Which is crazy.
Speaker 1:That's like a that's a part of our history.
Speaker 2:But I yeah. I
Speaker 1:Oh, no. Is it not? Is it, is it is it a milkshake duck? Is it what what's It's not
Speaker 2:a milkshake duck thing. Let I I will just put it this way. I've heard a rumor that it's for personal reasons for David to take it down, and he doesn't really like people watching it these days. I won't get into the details because they were rumors said to me, and I don't wanna say anything. But, my understanding is it was deliberately made hard to find, these days.
Speaker 2:But it is, like, basically, you know, the the magic of it at the moment, like, you don't even necessarily need It's it's it's almost boring to watch because Rails dominated the space so heavily and won so thoroughly, like, conceptually, obviously. I don't really think Rails is still dominant as a technology, but, like, the stuff that it brags about are things that we take for granted today when building web applications. And so when he shows, like, how awesome it is that you can do this, it it, like, doesn't have the same emotional resonance just just because, like, yeah. Of course. Of course, you can do that.
Speaker 1:So I that's interesting because the thing I was trying to remember first of all, I remember where I was when I watched that video. Really big deal when that thing came out. It was one of the YouTube was still really young. I mean, it was only, like it may be the first year of YouTube even. I mean, it was a super early YouTube, and it was the first time that I had a demonstration of a technology over YouTube, and it was arresting.
Speaker 1:I was like, oh my god. This it was like it was it 14 minutes long or something like that? Yeah. Yeah. 15 minutes long.
Speaker 2:Pasted it into the
Speaker 1:fax. Oh, nice. Oh, yeah. Yeah. Yeah.
Speaker 1:Okay. That's good. So it's DHH and and his agents are gonna have to work a little harder to hide it from hide it from oxide and friends. So yes, it's 15 minutes, and, the it is the thing that I was trying to remember, and actually maybe if you've seen this recently, maybe you can recall, but I don't know what degree the the tenor of the video was I have revolutionized all programming versus I have built a block engine in 15 minutes. I just remember being, like, like, here is a very useful approach for this kind of problem that, by the way, happens to be a problem that a lot of people have.
Speaker 1:But I don't remember being sold to me as this is going to revolutionize everyone's productivity. It was more just like, hey. Here's how I did this, and it was really effective.
Speaker 2:And an important thing to understand about David is that he does not care if other people use his thing. Like, he wants to tell you I haven't rewatched it recently, but, like, I would not expect him to be saying, like, you should also use this thing because Rails is first and foremost his project for him to do with as he likes and is written for him and for his taste. Everybody else is incidental. So I I would expect it to be like, I have built this thing that makes building websites incredibly fast, and I'm going to be using it, but I don't think I would not expect it to be a salesman as you would expect from someone making a use my framework, please, today, because I don't really think he cared then or cares now if people use Rails.
Speaker 1:I gotta say that is pretty common for these things that are these big step functions. They that is kind of the the their genesis. Right? I mean, that's, I mean, that's Graden and Rust. It's not like use Rust.
Speaker 1:It's kinda like, hey. This is the I mean, the Graden's presentation from Mozilla, was it 2,000 and what is it? 2012? That early? 10.
Speaker 1:2010. 2010. It's kinda like, here's some interesting ideas I'm experimenting with. I mean, it's just like the way it's it's I feel like UNIX was designed to test the file system. I mean, I think, you know, not to not to put myself in this kind of hallowed hall, but I guess that's exactly what I'm about to do.
Speaker 1:I mean, for Detrice, like, we ultimately designed Detrice for us. Like, it was ultimately, like, this is the thing that we are you like, I actually know this is effective because I'm using it to do my job. And if I would love other people to use it, but I also not then I'm kind of, like, if they don't, that's fine. I mean, I'm I'm happy. And then the and, I mean, this has got me reflect as you can imagine, reflecting on Detrice as well in terms of, like, the because I think what DTrace does for debugging, which is a very narrow problem or a a narrow subdomain, is DTrace eliminates all of the, most of the, accidental complexity in debugging, and leaves you with pure, distilled, essential complexity that does not necessarily make the problem easy.
Speaker 1:And so one one of the things we heard early on in DTrace is, like, oh, I'll put DTrace. I'll, like, I'll I'll use DTrace on this problem. It's, like, well, you can use d trace to debug the problem, but you are ultimately going to need to have like, you are gonna actually have to understand the problem. Like, DTrace can actually help you understand it. All it can do is make it easy for you to phrase questions of the system.
Speaker 1:It doesn't actually tell you what questions to ask, which is honestly the much harder bit. And I I kinda feel and which part of the reason, like, why I would never talk about, like, a 100 x gain because it's, like, it is an elimination of a bunch of tedium for debugging, but your ability to debug the problem is gonna both out of your ability to debug the problem, unfortunately.
Speaker 2:What question to ask is actually, why Brooks in no server bullet says AI is not going to help programmers.
Speaker 1:That section felt chillingly current, didn't it? Yeah.
Speaker 4:The hard thing about building software is deciding
Speaker 2:what to say and not saying it. Right?
Speaker 4:This was a year before the the next AI winter as well. So here was I think the tide was was like turning against, against the the current state of the art of AI at the time.
Speaker 1:The the first snowflakes were falling from the, the late eighties AI winner. So we got, Tom and Alex here, so I wanna get them in. Alex, actually, if if you don't mind what the we'll start with you because, you you would actually, when we were talking about no silver bullet in our internal chat last week, you had mentioned that that you'd read it, and, it sounds like more recently than than Steve and me, and it definitely had an impact as you were thinking about problems. Could you could you elaborate a little bit on that? Alright.
Speaker 1:Now, Steve, now we use you to debug. Do we know that Alex
Speaker 2:is The current state is Alex is not muted, but is not getting audio from their thing into Discord because little green ring does not appear at all. I mean, now you're remitted again, so you wouldn't. But I I would be debugging whatever your connection is to Discord itself, Alex.
Speaker 1:Right. We'll go to, we'll go to Tom, then I'll come back to you back here. Yeah. Exactly. Tom.
Speaker 3:Yeah. I I posted in the chat, but I when I was first looking for this paper, which I'm ashamed to say I never heard of before, I found this weird version hosted at UCSF with a a different productivity equation, and it's about groups where it goes down as the square of the number of people. But it has all these I posted this echo equation. It's got these very weird constants in it with no explanation on where it came from.
Speaker 1:And when
Speaker 3:was exchange.
Speaker 1:Yeah. And and then and, Tom, so when was that? And when and did this kinda resonate with with your experience up to that point?
Speaker 3:Well, yeah, clearly productivity goes down with large numbers of people. But, yeah, I don't I don't know when or where this paper came from, but it's a version of of Perks' paper.
Speaker 1:That's interesting.
Speaker 3:Wanted to say, and I got to meet Fred Brooks back in about 1980. Oh, wow. He was a character even then. In his office, he had a big row of timers, mechanical timers. And whenever he switched what he was working on, he'd hit the appropriate timer so he could try to keep track of his own productivity.
Speaker 1:Wow. He was like a a tailorist for himself.
Speaker 3:Yeah. It was pretty strange, but also the incredibly sugary southern accent. So
Speaker 1:Okay. Did you did you feel that I was overplaying that? I mean, do you feel No. No.
Speaker 3:It But, it
Speaker 2:is possible.
Speaker 3:I I was I was a young whippersnapper at the time, so I was just in awe that I got a meeting at all.
Speaker 2:It's possible the discrepancy is because the version you found is supposedly a direct reprint of the, IEEE Computer volume 20 number 4, April 1987, whereas the version that we linked is reproduced from the mythical mammoth anniversary edition with 4 new chapters, 1995. And so I wonder if this is a modification that Fred made, in between versions or something, Or is, like, yeah, different versions of a preprint, because it's like it itself is reprinted from some conference in 1986 or whatever. So
Speaker 3:The the other thing I wanna mention, which which he dances around, Simon, is this whole specification is the hard part. And I've always maintained that if if you could formally specify something, you can just compile the specification. Right?
Speaker 2:Right.
Speaker 3:It seems like people don't say that directly enough, but that's kind of the whole point of software.
Speaker 1:Yeah. It's to kinda be in that that gray area. When he talks about I do think it's interesting in terms of he talks talking about conformity as a as a constraint, and how, the conformity is is a can't even refer to it as axonal complexity or central complexity, but it's complexity at any rate that a magic bullet, silver bullets are gonna have a hard time addressing the conformity requirement. And I feel like those have only grown over time. Those conformity requirements have have gotten a lot more complicated over time.
Speaker 3:It's a day to day engineering thing. You know, the the principle of least surprise is you should conform conform with what other people are doing or else it just slows them down.
Speaker 1:Yeah. And, actually, Tom, as long as you hear so we the I would 2 other kind of points that I'd like to make about this kinda put it in its 1986 context that people might be, I think, confused by. One is the he talks about rapid prototyping as if it's a totally new idea because it is a totally new idea in 1986. There was a there was things were very, very waterfolly. And, the idea that you would and I think he talks about this in, I think, is it in the update for No Silver Bullet, where he he talks about how the the the big insight that he had is that software is grown, not built.
Speaker 1:Steve, was that in the original essay, or is that in the update? That may be in the yep. Yeah. If you didn't read that recently
Speaker 2:Alex mentioned in the chat, his audio is not working, but he wanted to say that, just so we could get it in the actual recording
Speaker 4:of podcast that he
Speaker 2:thinks the essential thing of Brooks is the quote that I just said. The hard thing about building software is deciding what to say and not saying it. I think that that's a statement generalizes to everything about the construction of software. That's why communication systems, collaboration tools, etcetera, can help so much because they help people decide what they need to say.
Speaker 1:That's a very good point.
Speaker 2:Hopefully, hopefully, Linux audio work for you in the future, Alex, but thanks thanks for continuing with Domino's.
Speaker 1:Linux Linux audio, Essential complexity or accidental complexity?
Speaker 2:We have, like, a a half an hour social meeting at Oxide, and almost every morning, somebody joins and, like, can't talk for some reason. And then when they finally get to talk, they're like, sorry. It was Linux audio. My bad. So yeah.
Speaker 2:Common common issue.
Speaker 1:Says the Windows user. Like, look. I know
Speaker 2:I wasn't I wasn't saying it. I was just acting smug. I wasn't gonna go so far as to be like, my audio always works. Always works.
Speaker 1:I was actually saying it. It was nearly dripping from every word. I was I
Speaker 4:I I will say that once
Speaker 2:I switched giving presentations, like, oh my god. This projector just works now. It's like like, I went from, like, I literally handed someone who runs a theater in Denver, like, if some weird Linux person comes in, hand them this piece of paper, and I wrote the, like, command line to set the freaking, like, x settings to be the same as their weird refresh rate on their projector or whatever. And to go from that to just, like, I plug the computer in and it projects things has been, very nice. So there are obviously lots of other limitations to Windows, but, multimedia working by default is not one of the problems.
Speaker 1:I it may be a 100 x er in terms of your of your projector productivity.
Speaker 2:Moving from Pulse Audio to Linux or to Windows is a default sound. Yeah.
Speaker 1:Yeah. And it's a it's a big bump. So and, Tom, when this came out oh, so the only thing I wanted to say, because I think that this came up in the, either either in the revisiting of it. So Brooks revisited the paper 10 years later. It's really pretty interesting.
Speaker 1:But he when he I and maybe I think it's actually no. No. Sorry. It is in this paper because he talks about, like, kind of the great hopes to the future. And one that I think people have latched on to and is this idea of great designers is finding folks who can really, develop great software.
Speaker 1:And I think you've really gotta take that one in its 1986 context. And, Tom, we'd love to get your perspective on this, and feel free to disagree. But software really was very subservient to hardware for a very long time, and it was not its own domain. Most, universities did not have a computer science program until the very late seventies or eighties or nineties in some cases. And so the it's not thought of as its own domain.
Speaker 1:And so the idea that you would actually specialize in software does it is kind of ridiculous in 1986, and that's part of the reason why he's expressing it. Like, it's a novel idea to develop to actually, like, focus on this as its own craft.
Speaker 3:There was a a lot of professional software recognition in the mid seventies.
Speaker 1:And, you know But, Tom, but but, Tom, what is your degree? Your degree is not computer science, surely.
Speaker 3:It it double e and computer science. They were the same.
Speaker 1:Computer science. So Alright. Yeah. In alright. I I stand corrected.
Speaker 1:It's alright.
Speaker 3:Which which I think they added I'm trying to figure out when they added computer science to the double e name, but it was early seventies.
Speaker 1:Yeah. I mean, total
Speaker 3:test to verify. I graduated in 78 and went went to work for Amdahl, and the, the mythical man month was the first required reading there.
Speaker 1:Oh, that's interesting. So you would read it when you arrived at Amdahl?
Speaker 3:Yeah. It it was it was the bible.
Speaker 1:And did Amdahl And Brooks
Speaker 3:Brooks cites this incremental programming, reference from 1971. So that's kinda how far back some of that goes.
Speaker 1:Right. And this and this is in the paper. Incremental development. Row not build software, which I think actually is that is important.
Speaker 3:Yeah. That's a really important insight.
Speaker 1:Well, I also love the fact I mean, he Steve even talks about demo day when he says, the morale effects are startling. Enthusiasm jumps when there's a running system, even a simple one. And I actually think that's what DHH is tacking into too with the the
Speaker 2:the I
Speaker 1:mean, it's like, it's a real running system. And now I can, like, yeah. Like, you can make it better now. And you can understand what
Speaker 2:it's built. Biggest things Rails did was to, like, marginalize databases, basically. And part of the reason for that was just that, like, to get a web app up and running, you had to deal with database crap before you could even get, you know, your hello world on the page. And just being able to be, like, you know, you don't even need to start the database or write any schemas or do any of that. You just kind of, like, write a couple commands, and now all of a sudden your thing is working was, like, shocking how how fast you could get to something useful.
Speaker 1:And and and the morale boost, the concommitment morale boost. I just even though what are some of the other I mean, some of the other things he talks about in terms of specific, breakthroughs or or putative, silver bullets. He talks about AI. He talks about expert systems. Do how much have you been exposed to to expert systems?
Speaker 1:Is that something you'd
Speaker 2:Not directly, but I'm aware of the term, and I thought it was really interesting that he chose to partition AI into, like, AI and expert systems because Yeah. I found the AI thing to be pretty on point for what we talk about with AI and then the expert system things to be like, oh, yeah. That's right. That's the thing that people thought would be good or something. But, like, I haven't had any experience.
Speaker 2:I don't think I've ever used something that was, like, sold as an export system. I've just I heard about it.
Speaker 1:Very eighties nineties as as Matt is saying in the chat. Yeah. And and experts says and I think that actually, you know, I think they're kind of due for a resurgence as I mean, in terms of, like, dealing with this kinda AI hallucination problem, you actually are gonna need some, some expert training here, whether it's an expert system or not. I there's something some interesting lessons to be learned from expert systems. But the it was very much the fashion of the day, where, was it was expert systems and distinct from AI for sure.
Speaker 1:What did you think about, well, you got graphical programming and program verification. I'm eager to get your and automatic programming. I'm I'm curious on your take on all 3 of these.
Speaker 2:Yeah. I mean, I think it's really interesting. I think the last one is probably the one that I thought was, like, very accurate for today. Like, I was just thinking Copilot, Copilot, Copilot with the, you know, automatic shenanigans, and, like, also the AI stuff. But I don't specifically remember the graphics part that well,
Speaker 1:to be
Speaker 2:honest with you. Oh, graphical programming. Not graphic programming.
Speaker 1:Yes. Not graphics programming, but like
Speaker 2:yeah. It's it's one of those things. So, like, the only graphical programming thing I've ever seen to succeed is Scratch, and maybe LabVIEW, if you consider that to be a success, graphical and programming. I think I do. But, like, outside of that, you know, I definitely feel like, that definitely seemed to be sold as a thing that could make, you know like, it was kind of the precursor to no code is sort of I feel like the vibe was about how graphical programming was gonna, like, fix everything.
Speaker 2:But it's just not it's just not there for, like, getting actual work done. Right?
Speaker 1:So So I alright. So I'm just
Speaker 2:to me, but, like, a thing that was old enough that I still experienced that discussion. But I don't think anything I don't think anybody we'll see what gets launched tomorrow, but I don't think anybody's selling a graphical programming, thing as being the next productivity leap. So this this felt outdated, but, like, in a more familiar way than some of the
Speaker 1:old Okay. But you but those
Speaker 2:186 too also is just a small you know, from the perspective of
Speaker 1:One of
Speaker 3:the things Brooks talks about is the flowchart stuff, which is, like, really primitive attempt at graphical programming, I think. But invented by Von Neumann himself and that gang, but it it was taught all through the sixties and into the early seventies. You know, flu chart and and it was the terrible thing. And and Brooks comes right out and nails it by saying software does not conform to 2 d or 3 d abstractions.
Speaker 1:Amen. I
Speaker 4:would I would say that you would struggle to find a software team today that didn't have somewhere a architecture diagram that was boxes and lines in an image of, you know, varying degrees of accuracy or potentially outdated, but like people do use images to confer to communicate with each other about the shapes of things, and that was probably that was not necessarily true of 86. Like, he's talking about the fact that you you just didn't have the pixel real estate to be able to do that kind of thing, but, like, people were I think people were
Speaker 1:trying hard to do it in 86 because the systems were smaller. I think people were actually trying hard to represent. I actually do think that people were trying to represent systems this way. Do you Tom, do you remember Borland object vision
Speaker 3:back
Speaker 1:in the day? This is, like there are a couple of these things, these graphical programming environments where we are gonna, like, program by by visualizing. And, you know, I agree with you about about the diagram that people have, but they those diagrams take different slices, and I I don't think you can take any of those diagrams and use that to generate the system. I I think that the
Speaker 3:Flowcharting was really taught as an kind of a necessary step for almost all programs. And and, really, diagrams are a great great way to explain things, but they're not directly related to the code.
Speaker 1:It is certainly relative to, like, a schematic where, like, when you have a schematic that actually, like, that is a there's a very important spatial representation. And, actually, this future of coding podcast, Steve, could they get, they are debating whether I shouldn't say debating. 1 of the hosts, I believe it it was Ivan, was like, no. No. I think I I'm gonna die on this hill that software has, like, spatial coordinates.
Speaker 1:I'm I'm only exaggerating slightly. And the cohost is basically like, well, you're gonna die in the sale because, like, I'm gonna show you that you like, I prepare prepare to meet your maker. Again, I'm only I'm exaggerating, but only slightly, but the I actually do think it's important that we go we don't have good this idea of using a spatial representation is a very limited power. And, Steve, I'm gonna give you a hot, hot, hot take that's just gonna get me blown up on the Internet. I actually I I really question the utility of Scratch.
Speaker 1:Having watched all of my kids do it, they are Scratch has got a super low ceiling, super low ceiling. And then they don't know where to go. Like, they they bonk into the ceiling, and they're like, I don't know how to, like I I can't connect this, like, thing I've made with this cat bouncing around with, like, the other software that I use. And, actually, they go to Minecraft, and they build things in Minecraft.
Speaker 2:Mhmm. Totally.
Speaker 1:Where the where there is actually, like, there is it's it's, like, totally, like, frameworks versus libraries. You know what I mean? Like, in in Scratch, you're super frameworky, and then you're going super library in Minecraft where you can, like and that they that has been more engaging for my own kids. And I'm not that, like, Scratch is a net negative, but, like, I think it's pedagogical utility is pretty limited.
Speaker 2:To maybe, just, like, add to the fire, note that I didn't say, like, was the best software in its class. I said, this is the most successful example of the software being written. So I agree with you. I do need a lot of things that Scratch gets really right, but the I mean, kind of inherits the sins of small talk. Right?
Speaker 2:Like, can't get out of that little box because you were too, you know, in the system as opposed to outside of the system, like, yeah, like, all that stuff. And going to Minecraft and redstone makes so much sense, for all of that. So, yeah, I I definitely, like, agree that, maybe there's a little bit of, damning of faint praise going on there on my end.
Speaker 1:But I also feel that, like, this gets to, like, the fundamental problem that I feel like Brooks also hits on. That if I'm gonna make you a 100 x more powerful as a programmer, a 100 x more product product productive, I am almost certainly gonna do it by really raising the level of abstraction. And if I raise the level of abstraction, I'm also going to give up some of that generality. I'm you're you're gonna you are gonna lose you're not gonna be able to do it in any language. You're not gonna be able to do it with any database.
Speaker 1:You're not gonna be able to, you know, you're I I'm gonna make a bunch of decisions for you. And those things can be great, but then you you are losing more and more and more of the power of software. So you can do things quickly, but they are the things that I have preconceived of. And I think a lot of these things fall into this trap of, like, yeah. Okay.
Speaker 1:It does make me, you know, of in order of magnitude more productive for the problem that you are envisioning me for, but the problem that you're envisioning for is actually not the problem that I have, which certainly the the the case with something like Scratch, and it's not gonna surprise me at all if that's the case tomorrow as well. I just think it's like have you seen dark, Steve?
Speaker 2:Oh, yeah. I am very familiar with dark.
Speaker 1:Do you consider dark to be graphical programming? It kind of is, isn't it?
Speaker 2:Sort of. Yeah. I mean, you're not wrong. I have to think about that for a second. It definitely suffers from the problems that we've been discussing.
Speaker 2:I don't know necessarily from, like, the act of programming it if I think about that way exactly. I'm mostly familiar with the, like, internal stuff rather than the actual, like, interface, of dark because they were in Rust, and then they rewrote into f sharp or whatever.
Speaker 1:Right. So I
Speaker 2:had, like, looked at the Rust version relatively in-depth, but have not done as much lately. I wanna mention that people in the chat have been coming up with other good visual software systems that what did you say? Good in their domain, but maybe didn't break out and don't think us think a ton about. Like, Line Sean says Simulink, Just like, you know, a good example, although it's very narrow. Emily is referencing HyperCard,
Speaker 1:which is
Speaker 2:near and dear to my heart. Totally. Literally, like, I some of the first quote, unquote conference talks I ever gave were as a kid about HyperCard programs to, some computer science professors. Pittsburgh Pennsylvania had a really good, science program, yadayada. But I feel like there's one another one somebody mentioned that was very good too.
Speaker 1:I think so I and HyperCard and Simulink are both really good examples, because they are content to confine the solution space a little bit. Like, I'm gonna solve, like, a a slightly more domain specific problem. But then I'm I then we can actually bring some of these tools to bear, which I think is kind of interesting. In terms of, like, you like, tone down the ambition a little bit, and make it a little more, and sharpen it a bit, and then you've got something that can actually so I think, I mean, the, like, HyperCard was used to build all sorts of things. But I think, okay, 4 of these things, they surely, they are used beyond the original intent of the designers.
Speaker 1:I mean, I I kinda think that HyperCard was used in places that that its designers didn't intend. But
Speaker 2:Well, I mean, HyperCard was, like, born out of an LSD trip, so I don't think that the designers intended for there to be that much constriction on what you could do with it. But, yes. Yeah. Like, Myst being the most famous example, as Emily brings up, but, like, they thought it was gonna, like, replace the web. Like, it was it was viewed by the creators as being very, very broad.
Speaker 1:Very expensive. Okay. Never mind. I'll set of that. Well, q, this is where Tom would recommend what the doormouse said just to learn that they were that all of computing owes its history to people who were dropping assets in seventies.
Speaker 1:Yeah. Okay. Then what so another one they mentioned that is also, near your heart, I think our heart is, program verification. And, again, this was done as kind of a on the one hand, okay, Brooks is I he he says, I do not believe we're gonna find the magic here. So, like, this is not a single magical concept.
Speaker 1:But he does say it's like there's, like, hope for this. Like, this can actually improve programs, and I think, you know, we we've a TOA plus. I mean, there's a lot of things that we can do that actually can we can be much more rigorous about the way we verify programs.
Speaker 2:Here's my super hot take on this. This is just types. Like, we we the the the, like, revolution in program verification is not so much about what we think. It's almost kinda like the AI thing where, like, AI is perpetually just like what we can't do with computers. Right?
Speaker 2:Like, the definition keeps moving. A lot of the stuff that we do today would have been considered AI in, like, the sixties. It's the same thing with program verification. Like, the rise of like, I think there's the history of type systems has been a lot up and down, I think. But I think in the current historical moment, we are on we are on a spot where we started to find the sweet spot of type systems that are expressive enough to not get in our way as much, but also give us a lot of the benefits of program verifications.
Speaker 2:This is like yeah. Dependent types are another example that are a little further on this step, that Blaine has mentioned in the chat that I'm still not a 100% sure is ever gonna be real, but we'll see. But, like, that the exact same problems that he talks about in this section are true of types. Basically, it's probably true. And acknowledging the downsides too.
Speaker 2:Right? Like, I don't think we'll find the magic. Verification is not about, program verification does not mean error proof programs. There's no magic here. Mathematical proofs can all also be faulty.
Speaker 2:It can reduce the testing load, but it can't eliminate it. Like, those are all statements that are absolutely true of types as well. And yeah.
Speaker 1:Totally. What I love that idea of, like, you take someone from 1986 and take them to a time machine to current date. And they're like, oh, you solved the formal verification problem. I just, like, I looked at this message that the compiler just generated, and clearly you've solved it. It's like, no.
Speaker 1:No. That's just the type system. It's actually giving you a, that's that's a really interesting idea. So yeah. So so those things and then and then where where did you net out on AI?
Speaker 1:The I mean, the AI, it it's such amazing how current that discussion felt.
Speaker 2:Yeah. That's I think that was probably one of my areas that felt most, correct, and I tweeted about it whenever I, read it a couple hours ago. And I got one or 2 good responses from people who had pointed out, like, that they kind of, like, think, yeah. It's it is true that I that it doesn't tell me what to think, but if I can quickly generate 10 different options and choose between them, that still could help me clarify my thinking even if it's not directly telling what to do. And I thought that was a particular, I forget who replied me to that, so I'm sorry that I've forgotten in the moment.
Speaker 2:Maybe I'll find the link and put it in the show notes. But I thought that was an interesting comment on, like, a pushback on this that I think is an interesting idea from the current, like, AI stuff that we use. But, definitely, I have not really, used I've used Chat gpt a little bit for funsies, but, like, I have not used any of the, like, programming assistant tools yet because I tend to be a little bit of a a laggard when it comes to adopting this kind of stuff. So I I don't have a lot of practical yeah. I don't know.
Speaker 2:I definitely what he says here resonates with me in general.
Speaker 1:Totally. And then we, and we had a, I think, a great discussion, on on the the the promise of large language models for software engineering and what it could mean. And there's definitely stuff it could mean, but it's not as simple. It's just like it is not a silver bullet. I think that I think we can say that with with some confidence.
Speaker 1:And the, and so so what happened the we've hit on some of them, but are are there any of the the things that have been big step functions in your career that we've missed? So we we talked I mean, I think Rails was a big step function. Right? I don't think I'm I'm exaggerating that. I think it was I think Rails is a big deal.
Speaker 4:I think
Speaker 1:the that Matt says in the chat, GC. That actually is a very yeah. And I definitely hear that. Sorry. Is that what you're gonna say?
Speaker 2:No. But it's close enough, which is, like so I learned GW basic and then, like, c and then c plus plus and Java was sort of my initial slate of languages I wrote stuff in. And then someone showed me Perl and specifically closures, and I went, like, holy crap. And I started churning out Perl code, like, far faster and got way more done than I was getting done in, like, late nineties c plus plus or, you know, those early, early Javas. And so that was, like, a personal step function.
Speaker 2:I don't know that that fits into, like, the history of computing and was true for everyone, but I kind of had this situation where I started with static typing and then went hardcore into dynamic typing for a while, and now I'm back on basically purely static typing. Yeah. So it's but, like, because I think that the dynamic typing was giving me a step function over the static typing at the time, and then now I think that the static typing that exists today is giving me a step function over dynamic typing had been, but that's just like a personal thing more than something I'm willing to generalize to the industry at large.
Speaker 1:I mean, for whatever it's worth, that's my path too. Right? That's, like, I a hardcore c, and then, like, realizing, like, oh, wow. JavaScript could be used for a bunch of these things, not just on the browser. And then realizing, like, maybe that was actually a few too many things.
Speaker 1:Maybe we can this Rust thing is pretty interesting.
Speaker 2:So And to kinda, like, bring that into the GC thing too, like, Patrick Walton has this really interesting, thing. I hope I don't miss misrepresent what he said on this before, but it's like, Java did like, as much as we did say Java didn't save the world, like, earlier in this this podcast, for example, like, it did seriously eat into the market share of, like, application software for c and c plus plus. Right? Like, is all of your problem? No.
Speaker 2:But, like, those used to be the default choice. You're building a desktop app. You write it into your c plus plus. And then in that time period, it moved to Java, and GC was a very large part of that being true. Right?
Speaker 2:Like, for software that didn't need every single last bit of performance, it allowed a lot of people to get a lot of work done. So Well and that was my point of reporting. That.
Speaker 1:Well, no. But my first impression when writing Java was this is the end of c plus plus because this eliminates now, I mean, I didn't think of it this way at the time because I didn't have I had not read Brooks' paper moments before. But looking at it in hindsight, Java eliminated so much of the accidental complexity of c plus plus and distilled you to the essential complexity. Of course, it generated excellent complexity of its own, but I'm like, this is gonna be the end of c. Well, why would you write in c plus plus?
Speaker 1:And, of course, I underestimated the the the the c plus plus tie words that, that that they would definitely, have their own resurgence. But, yeah, I think Java was a very big deal in that regard. And then, I mean, Java made the mistake of overshooting a bit, but it was a very big deal. And then, I mean, I think we didn't talk about cloud computing, but cloud computing is a huge deal for accidental complexity around infrastructure. Right?
Speaker 1:I think, hard to argue. Orchestration feels like we haven't yet had I mean, Kubernetes is super complicated, and I'm not sure that, I'm not sure that Kubernetes is in the book, as Paul Erdos used to say, of proofs that he felt to be sufficiently elegant that they'd be recorded in the book of the supreme fascist, which is his name for God. I don't feel like the Kubernetes is in the book. I'm not sure though.
Speaker 2:Yeah. We'll see. I kinda feel like, you know, Apple never, like, releases something, but they or the sorry. Never releases. They're never the first, like, the pro like, the iPhone was not the first cell phone that was, like, even smartphone, but it just, like, became product defining.
Speaker 2:Like Okay. I I've not used Kubernetes in anger enough in production. Like, I kinda got into that whole working on a programming language thing around the time that that became sort of, the cool kid thing to do for web apps. But I feel like I feel like there's gonna be a sequel or a second system that comes out that makes it better. But I don't know what that is.
Speaker 2:I'm not willing to bet that's true. So like, for for everything, but just kinda Is
Speaker 1:it coming from Apple specifically? No. But just like that sort of, like, an
Speaker 2:outside somebody not like not like them turning it. Like, it's not like Kubernetes 3 or whatever is gonna be, like, the best. Like, someone outsider seeing the space and then reworking all of that stuff to be on some sort of simpler or better primitives. We will see.
Speaker 3:Oh. Yeah.
Speaker 1:And I well, because I think that these, like, lurches that happen I mean, they do have some things that that they have in common. One is that when they they're not being first of all, they're not being preannounced as 10 x or a 100 x, improvements. They are represent they're kind of pulling together. I I'm just, like, talking thinking about the things that we've talking about. Java, Rails, Rust, I mean, Detroit's for that matter, where you're pulling together a bunch of existing ideas, and and kind of packaging them up in a way that is it is expressing their their usefulness, eliminating a bunch of accidental complexity, but done in a way that, like, the creators really did it for themselves.
Speaker 1:Java was done for Gosling, more or less for Oak, and the Setau project. Rails clearly done for for DHH. Again, we talk about UNIX and and certainly and so I I feel like it's that there's something these things have something in common. I've there there are some properties that that these big step functions have in common as individual technologies. And then there are these other step functions like Internet, open source, distributed version control, which feel like they're even more broad based and are even more radical over time, but just take a really it's not like there's some grand reveal for and now, ladies and gentlemen, the Internet.
Speaker 1:It was more like this is something that was available and then became more ubiquitous and a bunch of things unlocked that. I don't know. In terms of, like, these these indisputably, a huge step function, but took a long, long time to unfold.
Speaker 2:Yeah. Yeah.
Speaker 3:Sharing software was was always a big part of the buy versus build, you know, if you could get it for free. But the Internet made sharing the mechanics of sharing so much easier.
Speaker 1:Totally. Yeah. And then distributed version control even easier. You could actually, like you're not downloading tarballs from SourceForge. Or what did we used to do, Tom?
Speaker 1:What did we do before Git Bash? I don't remember.
Speaker 3:Yeah. SourceForge. ForceForge.
Speaker 1:That's right. Right. I have some books
Speaker 3:that publish the software in the back of the book.
Speaker 1:Right. There you go.
Speaker 2:Invite only BBSs.
Speaker 1:The Discords of their day.
Speaker 2:Yeah. Yeah. JBK said something in the chat that, is reminded me of one of my favorite quotes actually from the paper. JBK says, I don't know if it counts for programming productivity, but going way back, what about the whole concept of pipes as an operating system concept? And Yeah.
Speaker 2:In the ADA section, Brooke says, operating systems, loudly decried in the sixties for their memory and cycle costs, have proved to be an excellent form in which to use some of the MIPS and cheap memory bytes of the past hardware surge. And, like, you know, having people and companies argue, like, I don't need an operating system because it uses too much, you know, resources. It's, like, not worth it or whatever is, like, a thing that we just now take for granted as a tool that we build software on to be productive. And, like, you know, NOS is itself a platform. Yeah.
Speaker 1:That has a bunch of it turns out a bunch of of useful, things associated with it. I mean, things like and McIlroy was obviously a a big lurch forward. And, yeah, Matt, it was funny. I was gonna mention the same thing. Have you heard about this with the the, Knuth McIlroy showdown?
Speaker 3:Oh, yeah.
Speaker 1:Steve. Yeah. Exactly. Where Knuth writes a, you know, a a 5 page algorithm, and Knuth writes it as a pipeline, which just feels like, I've always thought was I think practitioners everywhere even though people are right to point out that, like, well, it's kind of that. That wasn't really the spirit of that, and it's like, I don't care.
Speaker 1:I just find it very entertaining, as I as a as a as a practitioner, I'm entertained.
Speaker 3:Brian, wanna jump on the opportunity to to correct your pronunciation. It's McElroy.
Speaker 1:It's McElroy. Thank you, Tom. It's, is it misspelled?
Speaker 3:No. That's just a weird spelling.
Speaker 1:It's a weird spelling. Alright. McElroy. Thank you, Tom. Let me you know this listen.
Speaker 1:A a an important, theme in this podcast is correcting my pronunciation for essentially everything. As we've learned, I I I mispronounced absolutely everything. Well, if it's like a a, yes. No. I'm listen.
Speaker 1:You can pry spig out of my cold dead figures, Ian. The, it's been great. This is Steve, thank you very much for, for being willing to jump in here, philosopher, and podcast host. Oh, thank you very much.
Speaker 2:Exactly. Thanks for having me.
Speaker 1:No. I really appreciate it. And, and, Ian and and Tom and Alex, thank you. Sorry that the, and, thanks to to everyone for all of your contributions. A lot of interesting stuff in the chat.
Speaker 1:We're gonna be definitely interested to see, the the the magic bullets of our the silver bullets of our future. I'm sure there will be, will be some, and I'm sure they will be somewhat valuable, but I think we can I think broadly stand by a lot of the conclusions here, that that Brooks made? I mean, coming up on, like, 40 years ago. I mean, this this is pretty old to be able to make things that are actually remain really quite current. Very, very impressive.
Speaker 2:For sure.
Speaker 1:Alright. Thanks, everyone. We'll see you next time.
Creators and Guests
