Anne: So, hello and welcome to Asynchronous and Unreliable, a new weekly podcast where we discuss the most interesting ideas and concepts in tech. I'm your host, Anne Curry, co-author of Build a Green Software, the Cloud Native Attitude, and author of the science fiction Panopticon series. And today I'm going to be talking to John Berger, a mission critical software veteran, regular on this podcast, and incidentally, I'm married to him. So welcome, John, who is Usefully cashed upstairs in my house, So today we're gonna talk a little bit about that. So today represents one of the episodes that that we're gonna do periodically, which is kind of like to reflex on what we've done we've heard in previous episodes and also to look forward to the future and have a think about what that means and might mean about software in 10, 20. I always say, I always think it's gonna be two years, three years, four years time, but it's more like 10 years or 20 years time. So today is a reflection on the future of software, which plays on what we just heard from in the last episode from Justin Colmack and from episode in episode seven from Martin Davidson on the future of AI and code generation. and with from your perspective, John, as a mission critical software development veteran. So So yeah, ha you've you've heard all the episodes we've had recently. What's what's currently in your mind? What what are you thinking about the fut what all of this means for the future of of software development?
Jon Berger: Yeah, so I I guess I'm interested in where where is this going? It's obviously moving quite quickly. and what people can do today is constrained in all sorts of ways. It's constrained by their imagination, maybe. It's constrained by exactly what the AI tooling can do this week, which will be different again next week. and it's also constrained by the the their the own the the the context that they have in terms of what service they need to deliver, how much risk they can accept, and so on. but I think it'd be interesting to spend some time thinking about well where is all this going, because that that path we're on at the moment is gonna is is is pointed in a certain direction. And working out where that what that destination looks like, I think will inform how people move along it effectively.
Anne: Yeah, it yes. Okay, that makes sense. That makes sense. I I
Jon Berger: If i if I'm in if I'm if I'm if I'm responsible for for for software development, right? I'm I've my the the rug has been pulled out from underneath me. Things are changing pretty rapidly. So when I'm in that sort of state, I like to try and work out, well, okay, well, where where do I think this is likely going? It doesn't need to be precise, but it's got to be a rough direction of travel, which will help me to work out, well, okay, is are the changes that we're thinking of right now likely to be helpful or No health.
Anne: So I so one thing, I mean that that that is interesting. What one thing that's that struck me from the the the last couple of episodes that I've been recording with kind of like practitioners or DevRel type folk, but people who are involved, at least in in talking to customers and and image and and and companies about the problems that they're having, is that they've they're they're setting out some quite different sets of problems that they might need to be solved by AI. They might want to be solved by AI. So Justin Cormac in the last episode talked about the problems of maintainers because I mean he was CTO of Docker, a long-term open source maintainer. You know, it's like it it has become increasingly difficult to maintain software because as it becomes more successful, it gets bigger and bigger and it has more features and it requires more effort to to maintain, it just becomes more maintainable. So that unmaintainable. So there is a problem there. but but when we when I spoke to Adrian Mowitz a few days a few weeks earlier, he highlighted the problem that they saw at the moment, which was security, you know, that exploits are being exposed much, much more quickly now than they ever have been in the past. So people need to be able to get on top of them, they need to be able to patch, they need to and again he was thinking about can can we use AI to solve the problem that is is is coming out of that. but you your in but your history, your work history had a completely different problem, wasn't it? You were you were looking at how to make code run faster but then at the same time maintain it. So the problem was how can you make code run really fast but be maintained and maintainable by humans. So so what what do you think are the what do you think is the key problem?
Jon Berger: Yeah, I I don't think any of those are completely different problems. I certainly didn't have any com any different problems from the ones that were described by Adrian and the the the the of of of course the code had to be maintainable. Yeah. I w I was responsible for products that were in the field for for decades. You know, when we when I when I left Microsoft we were still maintaining products that had been in the field for over thirty years. and successful and very profitable, and and you needed to they still need to work. And you spent way more time on maintenance than you ever did on building the thing in the first place. and well, in some cases, the people maintaining it were actually the people that had written software 30 years earlier. That wasn't the norm, which makes life harder. and of course, security was also absolutely critical. there is there there's not a lot of software. Out there that's doing that sort of job that lasts for that long that for which security doesn't matter and updating security matters. So I don't I don't think there's any any difference at all in terms of what what we're trying to achieve. and I think they also care about performance in the work they're doing because it matters because what they're doing is also a s a scaled problem, which is interesting. I think what was having said that, we've already done a a a podcast where we we did talk about performance at scale in networking where the challenges are quite extreme and people have been willing to go to quite extreme lengths in the past to create very, very high performance software where per packet processing is as low as possible and and that will lead people to craft handcraft code, including potentially down to the level of a assembler, which is by definition therefore pretty hard to maintain. But your the the balance The balance there is more towards performance than maintainability. Now, of course, in the control plane, performance matters a bit, but much less. In the management plane, performance doesn't really, or very rarely matters. and therefore your your needle is much more pointed towards the maintainability side than it is towards the performance side. So yeah, I've been responsible for for. software and across all of those and sometimes it's just about speed of writing and sometimes it's all about speed of execution and sometimes it's it's really about maintainability, which is which is a a slightly different thing yet again. So
Anne: It so yeah, I mean I it's I agree with what you're saying. there's also of course the the kind of point almost that that Justin Cormack made in his last episode, which is that then it it with a long running project, I mean he was talking about open source projects, this this applies to proprietary projects, but the the big the biggest examples are open source projects that sometimes the pendulum swings that That code was put in for absolutely vital say performance reasons. and then over time that performance might not might come not to matter anymore, but it becomes a a maintenance and a security issue. I mean, the the classic case was OpenSSL became almost unmaintainable because it was full of code that had been written. in assembly language to make it perform on certain operating systems or certain certain hardware. And that that just became totally unmaintainable. And it became a security hole, but nobody really knew what whether that code was was as Justin described it, load bearing or or just a nice to have. So nobody the difficulty is with that the projects tend to accrete code That was utterly key for a certain number of years and then became an utter threat at a later point, but it's ridiculous to tell which which state it's in or
Jon Berger: Yeah, exactly. Sure. So so I I want to put everything that Justin and Adrian said to one side because I think it's almost irrelevant to the where are we going in the long run question. Right. That's the where are we today and what can we achieve today? Right. The the the only answer to AI as a security threat is more AI, right? only AI can defeat AI. Not nothing else can operate fast enough. The the the the maintainability question, like today's maintainability question looks nothing like the maintainability question in ten years' time, because today the software is maintained by people and in the future it won't be. And and so it's just a completely different thing. I I just really don't think those th those two things look similar. now, where does that break happen? How do we gain the trust to go from maintained by people to maintained by AI? I think that's a different episode. I think it's really quite complicated. And I think we'll be spending hours talking to to get to that point. I think the goal here is is just to work out what that future might look like.
Anne: Yeah.
Jon Berger: And then we come back to okay, well, this is the direction we're going, then how do we get there? What are the interesting steps on the way to that future? But I think if we if we don't agree roughly the direction we're heading in, then we we won't be as effective at moving through that conversation because we're just gonna go, well what can we do next?
Anne: Yeah. Yeah. So I'm okay. I I get your point here. That that basically all my thinking about what everybody's saying up till now is based on thirty years experience of, you know, of writing and then maintaining and supporting and managing teams or doing all of those things. And actually I need to to let go of that baggage. It's you know, all the limitations of the past are not necessarily should not be become the limitations of the future. Is that what you're saying?
Jon Berger: Yeah, but I think quite. Yeah, I change is hard. Change at scale is really hard. If I'm changing, I want to change to the future, not just to a more recent past.
Anne: Yeah. so okay. So so from what you've heard and what you're thinking, what do you think that future looks like? What do you think a good future looks like that we should be aiming for?
Jon Berger: So I I think the things the baggage that we need to let go of is is all of the limitations in software that only exist because it's humans doing it. They d they don't have another good reason. Some of the things that we've learned over the decades have really good value and we need to keep them.
Anne: Mm-hmm.
Jon Berger: Or the AI will want to keep them because they are useful structures and ways of deploying and maintaining software. And others are only there because we are quite limited in our context window, or we get replaced fairly frequently and we can't ramp up in microseconds, or because We have limited communication bandwidth, which means that our our sort of horizontal scaling in the team is much more limited than than that of an AI. and I think an awful lot of software development, probably most of the difficult stuff in software development, over the last 30 years, is trading off those things against the things that you really want to have, which is you know, your function, your security, your performance, scalability, all of those things. So it's like how do you develop d deliver all on all of those and offer a service that the customer wants as cheaply as possible while still being scalable? And I think what you're alluding to on the performance side is that performance in most areas of software development has been one of the things that is tends to lose out. because it's humans maintaining it because very high performance code is really hard to maintain. Really, really hard to maintain. more so than most other function or or illities in your code. So I think one of the things we will get with code that's purely AI generated is it will say, not today, we're not there yet, but in let's say ten years time, it will be a lot faster. It will be a it will use a lot fewer resources to do the same job.
Anne: Well, say it's so I'm I'm gonna c take pull you up somewhat on that, which is it it might be. It could be, but it won't necessarily be. I mean, not all code will people bother to optimise it. Or well well, I think if you go far enough down the road, then all the people are out of the out of the loop entirely and it will just be optimized. Is is that what what what you're saying that that that there'll
Jon Berger: I think there will still be different levels of optimization because there are there will still be trade offs, right? There will be Do you want or need to have different versions of your code on on plat different platforms? maybe, maybe not. Do you I mean one of the trade offs that's that's just inherent in in code and is affected by maintainability, but e even if maintainability is free is still something you have to think about, is things like size of code versus performance. where there are things that you can do in your code base which make it flabby. but perform better. They often also have a s some of those things also have a maintainability deficit.
Anne: Yeah.
Jon Berger: those will still be trade offs that in a in a purely AI written world someone or some AI will need to make.
Anne: Yeah, I suppose yes, what you're saying there is a is that's a s and essentially almost a hardware trade off say it's like kind of how does it fit into the cash type questions, which are not just about human limitations, they're about hardware limitations. And even if we take humans out of the mix, because AI does it, the hardware limitations still remain.
Jon Berger: Yeah, and that and there will be things where maybe it still costs the AI more to write software. That I don't know. I mean, it may be that once software becomes pretty good All the software, you know, the default is just it's it's excellent. Maybe. That's not the default at the moment.
Anne: Well it's No, no, no, it's it's not. Even even with with with good code bases like the Rust code base, it's it's it's not a totally per you know, it's it they're not the code isn't training the AI to write performant code. Even in Rust, although probably more in Rust than in well, Python.
Jon Berger: one of the things that needs to happen and and is already happening to get us to that future is that AI needs to learn to write code not just by reading human code. So if you look at the AI, the AI training that people are familiar with from the concept of LLMs, where it essentially looks at a body of work created by humans and and and s and to some extent emulates that, is actually very different from the sort of AI that Alpha Go used to learn how to play Go by playing against itself, working out what worked, what didn't work, and and it was quite innovative, right? So Yes, it would play initially relatively naughty moves, worked out whether they worked or not. But then as a result of playing gazillions of games against itself, it created new strategies that humans had not seen before, and that allowed it to beat humans bec because it had trained itself on on what really good looks like, which was beyond what humans could do. I think software needs to go the same way to get to where I thinking. And and people are already starting to do that.
Anne: yeah, so you're thinking they're a totally there's there's no humans in the mix whatsoever way of doing software development, which is basically a couple of AI of AIs fighting against one another, battling against one another to produce the the better instance of the product that you almost like a a little microcosm of companies battling against one another to produce the products that it will be the the the leading product. That's that's That's an interesting question.
Jon Berger: Yeah, I I guess I wasn't even really thinking about it as competitive in that sense, more competitive in just can I make this better? You know, if I write this code in this way, does it still pass the functional tests but do so with some other benefit or or or whatever? But as a as a not an expert in how to train an AI, I don't know whether that would be more or less effective. Yeah, it's an interesting of thinking. You the the there were definitely teams I work with in other companies in the past who when when they when they had a a complex problem they would set three teams off running and say, Go build this thing and whoever whoever built the best one of those still had a job at the end of it and the other two teams got sacked. that that that is one way of doing
Anne: Yeah.
Jon Berger: I don't think that's the cleverest way of doing it, but I don't know.
Anne: Yeah. It's interesting. So obviously of the of the up of our recent episodes that have been about AI, about really genuinely ambitious AO generated code. So the kind of AI generating the kind of code that your teams used to write, mission critical code type thing. That is like Dustin Colmack talking about recreating Amazon S three and Martin Davidson talking about doing all kinds of things that he was doing.
Jon Berger: Well,
Anne: it was what that Martin Davidson was using quite an adversarial system. You know, he had two, he had he had multiple chatbots, different models, almost competing against one another in in helping him. Justin was taking a slightly different approach where I d I think he just had one model, but he was a big, quite a big part of it.
Jon Berger: Yeah.
Anne: But as you say it's
Jon Berger: I I heard I heard Martin's statement more collaboratively than that, th rather than competing. But yeah, I could s I you could take it either way, I suppose. Yeah, I don't know. I don't know whether he was, for example, genuinely you know, having different models create different ideas to see which was best, that sort of a that sort of evolutionary approach versus a try something, change it, see
Anne: Yeah.
Jon Berger: See what happens, sort of model. I'm not sure.
Anne: Well we'll get Martin back on again. And we'll get Martin to listen to this. And so one of my questions is, we've got a lot of questions for Martin. We'd quite like to know how much he spends, which is a question we never asked. what's his what's his token spend? What kind of budget does he have to to do all this experimentation? But also, would he consider what he's doing to be essentially collaborative or essentially competitive? Hmm. But yeah, we'll have to ask him. but yeah, yes. So so coming back to to that, you were saying that that I mean your background is that you ha you often had a problem, which is we needed the y you worked in networking code, so it wasn't just mission critical, it was networking software, which is unbelievable which has to be unbelievably fast. And but the the the the blocking thing for you over and over again was it has to be unbelievably fast, but it still has to be supported by humans and written by humans. That was that was your kind of bottleneck. your prime would you say that was your primary bottleneck?
Jon Berger: the the fact that it had to be done by humans. I was responsible for lots of different products in quite a lot of different spheres, all generally under the heading of networking. But some of that was very much management plane, some of that was data plane, some of that was control plane, and all the things that go go around that. for sure there are times when the limiting factor is a human has to do it. equally a lot of your limitations really just comes from your from the sales environment and what your customer what your customers will tell you or allow you to do and and so But but it but I I just think it's a completely different game. You know, I I just think that that that's why I think it's interesting to see well where could we get to? One of the reasons why it's important to look at where you could you get to rather than how do you evolve there is because if there's a way if there's a place that you can get to which is way better than the place you can evolve to. The new entrants that just go straight there that don't need to evolve will eat the lunch of anyone who's evolving. Yeah, that's that that's that's that that's how economic So that's why it's an interesting question to ask and not just say how do we evolve?
Anne: Yeah.
Jon Berger: I think you've got to do both. If you've got a business today, you've got to work out how you can evolve. And and what we're talking about now, right? Almost nothing we're talking about like what fully exists. We haven't even started talking about what the thing looks like yet. But it's it's not about what you can do today. But but if you can understand where that might get you to, then I would think you'd be able to start evolving in that direction in a way that you can maintain the evolution and get there such that you can maintain your business. can still be in the nirvana of super fast, cheap code that does everything in the future in a way that means that someone else doesn't get to eat your lunch because you're never far enough behind them that they've got an advantage there and you've got the advantage of having a an existing product set and existing customers and money coming in.
Anne: Yeah, yeah. Yeah, that should always be a you real you want that to always be an advantage, not a disadvantage. But but yeah, so so as you're saying, we haven't we've been we've talked a lot about kind of the transition here really and and what what you're really on here to talk about today is where are we going? What's the purpose? What is what are we aiming for here? 'cause you've been doing a bit of thinking about that. So I'm I'm very interested to hear your thoughts on Where are we going? What will good look like in ten years time? Do you think? Is your current thinking?
Jon Berger: Okay, so this is not particularly an ordered list, but the first thing is it will it will all just be machine code. I don't see any good reason why high level languages need to exist in in ten years time for for for for the front end of software development. That they are just they are a brilliantly useful human construct. But they and and during the transition they're very helpful as well. But in the long run they have their only advantage I think it will turn out to be that humans can read them more easily. And I don't think that is a big enough advantage. There are transitional advantages to languages beyond that as well. But once you've actually trained AI on what the output of a compiled version of that looks like and then allowed it to optimize to do even better. I think we'll find that human readable languages are something that exist just because humans like to read.
Anne: It's so it's interesting because in the last episode with Justin Cormac and his experiments, he I mean, he's a big language fan, and I I know almost nobody with such an encyclopedic knowledge of all the different languages and all the pros and cons and what they're there for. He was really using languages as a way to effectively guide the AI when he wasn't guiding it, when he wasn't there, when it was building stuff overnight, he was using the structure.
Jon Berger: I can be agreeing.
Anne: languages to do that. But it but he did also mention another thing, which was when he hadn't given, when he'd given his AI, Claude, I think it was, wasn't it, that an instruction, but not, but he wasn't watching what it was doing too closely, and it couldn't do it with the languages that sh that he'd made it, or the tools he'd made it available to it. It had just gone in and edited the binary, edited binaries to to get the result he that that it that it wanted.
Jon Berger: Remember when we used to have to go and edit binaries? That was how you made that was how you fixed bugs. Yeah. Those those were yes, quite a lot of effort. yeah, I I I I agree with Mart with with Justin's logic on the the short term value of languages because AI can't yet do what I'm saying. It can't yet write excellent machine code. But once it can I can't see any reason why you why why anything else would be better. Right, that's a it's a tr those those languages are a transitional technology as far as I'm concerned.
Anne: Yes, I mean there is plenty of machine code out there for it to learn from.
Jon Berger: Well, and which will mostly be terrible because it's A A it's software, so it's mostly terrible, and B it's c compiled from human readable languages. So it it just won't be as efficient as it could be.
Anne: Mm-hmm. Yeah, I I see what you mean that there's we're still looking at the obviously look everything, almost everything that it's being trained on at the moment is the waste product of sloppy humans. rather than something that it had created from scratch. I mean something else that that Justin mentioned in his in his episode was pony, which is actually a language I'd never heard of before. But Pony and the and the guy who'd invented Pony was creating his own training set, because there wasn't a great deal of pony training set, for the AI. And in some ways that represents a world of the future where the AIs create the training sets for other AIs and they're clean and they're perfect. Is that what you're s kind of envisaging?
Jon Berger: Well, that's what I'm saying. The the once you're if you're training if if if you're training your AI to write code by actually just checking the output of the code, not by saying, What has someone else written in the past? Right? Maybe a combination of the two initially, then you You you don't the the languages give you some constraints, which can be useful. they allow you to write code faster, which can be useful, but but I don't see either why why I don't see how either of those help you in the long long future. I would say those have they have more negatives than positives. the the the the thing that might might change the way that works, I suppose, is that I don't know a lot about semiconductor design, so I don't know how much of that is constrained by humans, whether the the machine code looks completely different because the machines it's running on are completely different, whether you can create much more efficient machines. I don't I don't know what the what the the limitations look like there.
Anne: Yeah, that's it.
Jon Berger: I would guess you can because I think there are some features, some hardware features are are sort of almost aligned with the way software engineering is done at the moment.
Anne: no, we need to get in a hardware.
Jon Berger: And and you know, once you're running on biological computers rather than rather than Silicon Yeah, who knows. But anyway, language machine code. That's that's that's my view of that.
Anne: Yeah. Okay, so that's one. You said you had a couple of thoughts. So your first one is there will only be machine code.
Jon Berger: Exactly. Yeah, I I think so I think libraries, open source, code structure, I think that changes quite a lot as well. But the point where you can you can create just the software that you need and you and you have trust in it, right? The the transition from here to there is all about trust really. then once you've got trust you don't need open source you because you you don't need libraries. They're not really they're not they're not adding value. They're not fundamental to the way that code is going to get executed. you probably still need microservices, but not in not for all of the same reasons that microservices exist today. There are microservices do a number of different jobs for you. Some of them are about humans, some of them are not. So like reusability doesn't help you very that is is not is is not necessary. for example, trust boundary limitations are not are necessary may be necessary across different organizations, but not within an organization in the same way. But there are other aspects of microservices which are brilliant for, you know, resilience, your resilience architecture, in which that is still a great resilience architecture. So they would exist for that reason.
Anne: So that's that's interesting because I Sam Newman is going to be a f is a future guest on this podcast, author of O'Reilly's Building Microservices, and his new book is about resilient sisters distributed systems. And I I think they do do do almost reflect two different things that that microservices were often a kind of developer tool to limit the scope of a problem so that a an individual or a small team could work on it without stepping on on the the treading on the toes of other teams. And it was it was always a a a developer parallelisation of developments and development teams tool. It was a team for a tool for developers. But distributed systems are are are an operational tool that help you to kind of like, well, I'm running 10 copies, so if nine of them fail, I've still got something running and and you can scale up. horizontally rather than vertically. You know, it it's an operational tool. So a microservices, yes, yeah, it does have two completely different use cases. And as you say, one use case is a very human use case, which is allowing humans to work in parallel with other teams of humans. And one use case is just a physics use case, which is sometimes hardware fails and it's useful to have multiple copies of things running.
Jon Berger: Yeah. I I mean interestingly, Martin told us that even with AI writing all his code, he found it useful to break things down into microservices or libraries so that they had such that different AI agents can operate on one piece at a time. it sounded more to me like that was a sort of limitation in what AI can do right now rather than something that would necessarily still be true in ten years' time.
Anne: Yeah, yeah, it's hard to yeah. It's so that but that well, actually you're you're right. That was an interesting point. I don't know if Martin said that in the podcast or but yes, you're you're right. So in some ways, counterintuitively, some of the stuff that we learned about making teams more effective also makes AIs more effective because they do tread on one another's toes, especially in this kind of like
Jon Berger: I think that I think that was when we had a coffee with him.
Anne: they're they're all trying to compete to somewhat with one another. You you want to kind of you w you do want to have those trust boundaries in there.
Jon Berger: So yeah, MarkSaves libraries, no need for open source because you just rewrite it all from scratch. Similarly, code control is completely different. You know, code control is great for humans who need to evolve code in small, you know, one line at a time. But if you're just rewriting it all from scratch every time, then it's just getting in the way. some people are already talking about. Well, there's no point in controlling c code, but but prompt control might be useful so that you know what what you asked for. I think that's that's probably an intermediate step as well on the way to AI actually just running a service where it where it can evolve things, but that's I think that will move in that direction. I think diagnostic's gonna look enormously different, but you know, the fact that they have to be human readable interpretable at the moment. So I think that would be interesting to see where that goes. I wonder if there's some some fun there where just by monitoring other other Things that happen on the CPU you can you can actually just work out what's going on. There have been there have been all sorts of reported security, like super sophisticated security attacks based on listening to the sounds that CPU gives off give off and and voltages and fans and a and temperature sensors and things like that. I I just wonder whether there are ways of again this comes back to a performance trade-off like it it's how much how much diagnostics you've got. Dig yeah you know in i is there a world in which excellent diagnostics doesn't cost doesn't have a performance trade off. yeah, don't maybe that would be interesting.
Anne: Yeah.
Jon Berger: Low level structure is a is another interesting one, which I haven't heard anyone else really talking about. which is that there's an awful lot the way we write code, which is, you know, within the language, which is just which is about maintainability. and and it's sort of about having just one code base really and not duplicating things too much. repetitive code is is just harder to maintain. I mean in in in the world of in the world of networking software, if you imagine the you're processing different types of packets and your packet processing for IPv4 packets and IPv six packets is similar, but not exactly the same. And there are a series of tests that you you you want these things to go as fast as possible, but you've gotta you've always gotta check, you know, where the packets come from, is that legal? Is it a valid packet? Is the addressing okay? That's that's obviously IP dependent, do I just need to drop it? Or does it go through shapers or whatever? So there's there's a lot of sophisticated questions that are going on on each of these things. And they are they are sometimes they're literally exactly the same. Sometimes they're just conceptually the same, but the actual low-level operation you're doing is slightly different depending on whether it's an IPv4 packet or an IPv6 packet, for example. So you might well have in your in your stack a whole series of of if tests where you know if it's IPv4 process it this way, if it's IPv6, process this way, then a bit of common processing, then another if I'm IPv4, do it this, if I'm IPv6, do this. and that makes the code more maintainable. but it is slightly more expensive because each of those if tests costs you performance. If you just duplicated the entire thing and asked the question once is this an IPv4 packet? All of the code. If it's an IPv6 packet, almost exactly the same code, but not exactly the same code. But the fact that it's almost exactly the same, but not exactly the same, would be an absolute maintenance nightmare for a human being. But not for an AI. So there's I think there's a massive opportunity to sort of
Anne: Mm.
Jon Berger: I don't know whether there's a name for it. It's a bit like loop on rolling, but but sort of for if testing. So you just separate out everything. And if you've got repeated if tests, then duplicate massive code duplication in some cases will help you a lot with performance. Maybe that won't be common, but there will be, I think, a lot of cases where. That sort of construct is something that will really help you. And then you go back to the performance question we've got, which is like, well, okay, how much of that unrolling helps you? If the code gets much fatter, is that good or bad?
Anne: I think what you're saying is it's like the opposite of dry. You know, it's like the no, it's not it's not the opposite. Well it's it's not exactly dry, but
Jon Berger: Not exactly the opposite, but but yeah, it sort of is. The the it if you can write code in a way that there's just much less to execute because it's just fatter. But you you know, the the bit you're executing is fat but has fewer tests in it because you've identified up front that some of those tests are not needed. You know, you you would you would have to save as a human being, you would have to save an awful lot of performance there to ever be bothered to go down that route. And to be clear, in networking code, sometimes we have done that, right? In the data plane.
Anne: Yeah.
Jon Berger: packet processing, there is some like super speedy stuff out there, which is really hard to maintain because of those sorts of tricks are being played. But that's way not normal. But that becomes accessible in lots more spaces.
Anne: I'm gonna predict that it's gonna be called wet code, when you make the code as quick as possible, but you don't worry about repetition. But that means we need to think of a something something starting with W, something starting with E, and something starting with T. But anyway, the opposite of dry.
Jon Berger: Wow, extremely we're beginning with T that means fast.
Anne: I can't think of it instantly and then Yeah, I will think W E T. That's you've heard it hurt here first, folks. Wet code is code that where there's no attempt to make it dry. Because the dry, I mean I I remember it's almost
Jon Berger: You can edit edit i in later. Wow. Extremely
Anne: You know, when I was a first a developer 30 years ago, almost the first thing I learned was dry, do not repeat yourself. That is the classic way to make code more maintainable, is that you don't repeat things because then you have to worry about whether or not a code that the two identical bits of code, maybe there's a bug in it, then you have to find the other one to fix the bug in both places, and you never do fix the bug in both places, so you get you experience smoke with the bug twice. It's it's just a maintenance nightmare to have lots of copies of the same code all over the place. Heads do not repeat yourself, dry was like an absolutely foundational piece of advice for developers to learn. And it is a very good example of now we're saying, well, in an AI world, if if humans if you don't have to worry about maintainability by humans, if maintainability of code becomes a lot cheaper, then yeah, dry goes out the window. What is your new approach?
Jon Berger: And and I think as AI writes more code, it will spot more things like that. In in the same way that AlphaGo didn't just learn to play Go and then play it as well as a really good player. It actually created strategies that humans hadn't. because of the way it taught itself. And some combination of its greatly expanded context window or memory or maybe it was just luck in the way it evolved its its algorithm, I don't know. But but it went beyond the state of the art. I think the same will be true here.
Anne: of
Jon Berger: And then you get to a point where code just co couldn't be maintained by humans, right? Even even humans that that can read machine code, just like, well, you know, I can't hold enough in my head to be able to do that. Maybe it will look lot maybe it will look in some ways a lot more like code we used to write 40 years ago when we had like no resources whatsoever to play with, and you had all these weird tricks that you ended up playing with the CPU to try and get it to do what you wanted without. I mean the the limitation there was always j was almost always just on the code size. but There's all sorts of fun that you can do that, which just you which you can't really do commercially on a product that's that's maintained and out there, but but you don't need to. I may maybe maybe you've got a service that runs every day of the week and and it does slightly different things every day of the week. And you've got an if test, is it a Tuesday? Now you just have Tuesday's code automatically runs on Tuesdays, Tuesday's running Tuesday's code, just Wednesday is running Wednesday's code. But it would have to be a reasonable performance benefit to to be doing something like that, but those things are available.
Anne: Yeah. So okay, so that's cool. So what else? What else? What else?
Jon Berger: I suppose the I mean the other the other obvious thing is that all APIs at the moment are just like the slowest things in the world because they're human readable. human readability in in on interfaces is probably one of the biggest performance killers that we have. yeah, definitely getting it.
Anne: and of course and that, of course, interestingly, that was a huge revolution in our working lives as developers. when we when we both started as developers, in and we were working kind of not just networking, but but kind of I was actually working in in applications, I was working on Microsoft Exchange, not not not even super fast or not deliberately super fast code, and all messages were exchanged in in a binary format called ASN1. And it was really hard to debug things because you had to decode these these binary structures in order to work out what what data was being passed between between computers. And then but back then we had almost no resources and those binary, they were quite small and so they were quick for machines to parse and they were quick, they didn't take up much bandwidth. But almost the first thing we used additional bandwidth for as the internet grew was HTML and just passing passing things in text format which are unbelievably bloated and huge, but were human readable.
Jon Berger: Yeah. Well yeah, I mean it's worse than I remember, I mean most of what I worked on, actually even the latest stuff, was you know, was binary, and an awful lot of it was was binary encoded and and pretty efficiently so. but I remember that I think I think SIP was the first protocol I came across that was that was a text-based protocol, and it's like Okay, I get why you might want a text-based protocol because it makes things slightly easier. But it's like it wasn't even it wasn't even specified whether it was uppercase or lowercase. So every time you looked at the message, you had to say it's like, does it say invite in you know upcase I? And then like you know, and you had to test it. It's like all of that is CPU. You're just throwing away to make developers' life slightly easier. That was the first point to me where it was like, wow, software engineering has changed from being like the resources really matter to screw the resources, just just write code as fast as you can. That was that was obvious. That was like late nineties.
Anne: Yeah, it it moved from yeah, ho hardware being the yes, yeah, mid-nineties, hardware being the constraint to cu developers being the constraint. and at that point, yeah, all the hardware got sucked up, making life easier for developers really didn't. So AI will turn the tables on that. Well well, we don't really know, do we? But your prediction is that AI will turn the tables on that.
Jon Berger: I think I think it will make make th those things like that look very, very different. But I think it will I think that that sort of stuff takes longer because again, because it's all about the trust boundaries. And so while it's operating in a mixed environment where you have both AI written code and human written code, then that's that in itself is quite limiting. So how some extent how fast that goes will depend on like how valuable people perceive the latter.
Anne: so have I absor have we exhausted all your thoughts there on what code will look like in the future, or is there anything else that you want to add?
Jon Berger: There was one thing there was one
Anne: about good.
Jon Berger: thing that we we should have talked about really, which I guess sort of we maybe maybe was slightly implied, and you definitely talked about it with with Justin last week was was unikernels. so the the whole unikernel concept was conceptually a step in that direction of yes, you've written An operating system that does all of these things, so it does everything for everyone, but any one use case only requires 20% of all of the things. You don't use all of the drivers, you don't use, you don't even need all of the the the basic functions. that, but more so essentially, is what we'll see in AI or written code. now, whether it will actually be unikernels, you know, w but but but but which it could be, right? If you're certainly if you're not doing anything multi tenant, do you gain anything from having user space, kernel space split? Well no, you've just got code running slower. Kernel case code is harder to write. Not anymore, it's not
Anne: Yeah.
Jon Berger: So why would user space exist? Well, maybe something like it exists in a multi-tenant in a in a in a hypervisor style environment. it's not quite the same thing, but but that sort of split, sure. People might still might still want to do that.
Anne: Hmm, that is an interesting one.
Jon Berger: That's a that's a pretty big structural change, I think.
Anne: Yeah, yeah. Well that I mean that would be that would be a very interesting direction to take. There is only the kernel. There is no kernel and unispa and and user space anymore. so so you've you've put forward a lot of quite radical thoughts there, based on 30 years of you being actually, you know, absolutely deep in the writing of mission critical software that runs everywhere. This kind of system software that runs the world. No more code, machine code only, no more humans in the mix, no more potentially user space, only the kernel. and yeah, and we haven't talked, and as we say, we deliberately haven't talked about how we get from here to there, which will Depend massively, won't it, from company to company. It will depend because some people will be starting from scratch here and some people will need to. that is another episode. So well th so thank you very much. you give me plenty to talk about. And since you're only upstairs in my house, I imagine we will be continuing to talk about this for for for quite some time. And I'll see if we can get Martin back in.
Jon Berger: I think that's another I think that's another episode.
Anne: and there are various other people who I think might want to put their ore in on this discussion. Justin, for example, might want to c to come back in and say, well, hang on a minute. don't get ahead of yourself. Although I think that Justin at the moment is more focused on the transition than the the kind of the the total end game. Although ironically, he was more focused on the total end game ten years ago when he was involved in Unikernels, which was massively ahead of its time in many ways. Fantastic project. Anyway, thank you very much for being on the podcast. And thank you very much to all the listeners and I will hope and watchers and I hope that I will catch you again on a future episode of a synchronous and unreliable podcast. Thank you very much. So thank you for listening to the last episode of Asynchronous Unreliable. But now I have some work for you. We're very keen to answer questions that are submitted by listeners, take suggestions for who we should contact to come on the show next. we're you we're always very happy to do that. And you don't have to record a snippet yourself, you can just send in a message. so you can contact me in if you're on YouTube, you can add things to the comments. If you if you're not On YouTube, if you're listening to this on a podcast, you can reach out to me on LinkedIn. I'm Ann Curry. Very happy to connect to people. Just just reach out and connect, and I'll and I'll connect to you and you can send me your your questions, your ideas, your thoughts. And of course, your thoughts on what W E T, wet programming, the opposite of dry programming. What should that TLA stand for? Now at the moment, the one that's in the in the lead is Gemini's suggestion, which is writes everything twice, which I quite like. We do quite like that one. So but you know, if you if you're a human and you have an idea, please do let us know. So thank you very much indeed and we are very, very keen to hear from you. Thank you.
Jon Berger: Yeah, so I I guess I'm interested in where where is this going? It's obviously moving quite quickly. and what people can do today is constrained in all sorts of ways. It's constrained by their imagination, maybe. It's constrained by exactly what the AI tooling can do this week, which will be different again next week. and it's also constrained by the the their the own the the the context that they have in terms of what service they need to deliver, how much risk they can accept, and so on. but I think it'd be interesting to spend some time thinking about well where is all this going, because that that path we're on at the moment is gonna is is is pointed in a certain direction. And working out where that what that destination looks like, I think will inform how people move along it effectively.
Anne: Yeah, it yes. Okay, that makes sense. That makes sense. I I
Jon Berger: If i if I'm in if I'm if I'm if I'm responsible for for for software development, right? I'm I've my the the rug has been pulled out from underneath me. Things are changing pretty rapidly. So when I'm in that sort of state, I like to try and work out, well, okay, well, where where do I think this is likely going? It doesn't need to be precise, but it's got to be a rough direction of travel, which will help me to work out, well, okay, is are the changes that we're thinking of right now likely to be helpful or No health.
Anne: So I so one thing, I mean that that that is interesting. What one thing that's that struck me from the the the last couple of episodes that I've been recording with kind of like practitioners or DevRel type folk, but people who are involved, at least in in talking to customers and and image and and and companies about the problems that they're having, is that they've they're they're setting out some quite different sets of problems that they might need to be solved by AI. They might want to be solved by AI. So Justin Cormac in the last episode talked about the problems of maintainers because I mean he was CTO of Docker, a long-term open source maintainer. You know, it's like it it has become increasingly difficult to maintain software because as it becomes more successful, it gets bigger and bigger and it has more features and it requires more effort to to maintain, it just becomes more maintainable. So that unmaintainable. So there is a problem there. but but when we when I spoke to Adrian Mowitz a few days a few weeks earlier, he highlighted the problem that they saw at the moment, which was security, you know, that exploits are being exposed much, much more quickly now than they ever have been in the past. So people need to be able to get on top of them, they need to be able to patch, they need to and again he was thinking about can can we use AI to solve the problem that is is is coming out of that. but you your in but your history, your work history had a completely different problem, wasn't it? You were you were looking at how to make code run faster but then at the same time maintain it. So the problem was how can you make code run really fast but be maintained and maintainable by humans. So so what what do you think are the what do you think is the key problem?
Jon Berger: Yeah, I I don't think any of those are completely different problems. I certainly didn't have any com any different problems from the ones that were described by Adrian and the the the the of of of course the code had to be maintainable. Yeah. I w I was responsible for products that were in the field for for decades. You know, when we when I when I left Microsoft we were still maintaining products that had been in the field for over thirty years. and successful and very profitable, and and you needed to they still need to work. And you spent way more time on maintenance than you ever did on building the thing in the first place. and well, in some cases, the people maintaining it were actually the people that had written software 30 years earlier. That wasn't the norm, which makes life harder. and of course, security was also absolutely critical. there is there there's not a lot of software. Out there that's doing that sort of job that lasts for that long that for which security doesn't matter and updating security matters. So I don't I don't think there's any any difference at all in terms of what what we're trying to achieve. and I think they also care about performance in the work they're doing because it matters because what they're doing is also a s a scaled problem, which is interesting. I think what was having said that, we've already done a a a podcast where we we did talk about performance at scale in networking where the challenges are quite extreme and people have been willing to go to quite extreme lengths in the past to create very, very high performance software where per packet processing is as low as possible and and that will lead people to craft handcraft code, including potentially down to the level of a assembler, which is by definition therefore pretty hard to maintain. But your the the balance The balance there is more towards performance than maintainability. Now, of course, in the control plane, performance matters a bit, but much less. In the management plane, performance doesn't really, or very rarely matters. and therefore your your needle is much more pointed towards the maintainability side than it is towards the performance side. So yeah, I've been responsible for for. software and across all of those and sometimes it's just about speed of writing and sometimes it's all about speed of execution and sometimes it's it's really about maintainability, which is which is a a slightly different thing yet again. So
Anne: It so yeah, I mean I it's I agree with what you're saying. there's also of course the the kind of point almost that that Justin Cormack made in his last episode, which is that then it it with a long running project, I mean he was talking about open source projects, this this applies to proprietary projects, but the the big the biggest examples are open source projects that sometimes the pendulum swings that That code was put in for absolutely vital say performance reasons. and then over time that performance might not might come not to matter anymore, but it becomes a a maintenance and a security issue. I mean, the the classic case was OpenSSL became almost unmaintainable because it was full of code that had been written. in assembly language to make it perform on certain operating systems or certain certain hardware. And that that just became totally unmaintainable. And it became a security hole, but nobody really knew what whether that code was was as Justin described it, load bearing or or just a nice to have. So nobody the difficulty is with that the projects tend to accrete code That was utterly key for a certain number of years and then became an utter threat at a later point, but it's ridiculous to tell which which state it's in or
Jon Berger: Yeah, exactly. Sure. So so I I want to put everything that Justin and Adrian said to one side because I think it's almost irrelevant to the where are we going in the long run question. Right. That's the where are we today and what can we achieve today? Right. The the the only answer to AI as a security threat is more AI, right? only AI can defeat AI. Not nothing else can operate fast enough. The the the the maintainability question, like today's maintainability question looks nothing like the maintainability question in ten years' time, because today the software is maintained by people and in the future it won't be. And and so it's just a completely different thing. I I just really don't think those th those two things look similar. now, where does that break happen? How do we gain the trust to go from maintained by people to maintained by AI? I think that's a different episode. I think it's really quite complicated. And I think we'll be spending hours talking to to get to that point. I think the goal here is is just to work out what that future might look like.
Anne: Yeah.
Jon Berger: And then we come back to okay, well, this is the direction we're going, then how do we get there? What are the interesting steps on the way to that future? But I think if we if we don't agree roughly the direction we're heading in, then we we won't be as effective at moving through that conversation because we're just gonna go, well what can we do next?
Anne: Yeah. Yeah. So I'm okay. I I get your point here. That that basically all my thinking about what everybody's saying up till now is based on thirty years experience of, you know, of writing and then maintaining and supporting and managing teams or doing all of those things. And actually I need to to let go of that baggage. It's you know, all the limitations of the past are not necessarily should not be become the limitations of the future. Is that what you're saying?
Jon Berger: Yeah, but I think quite. Yeah, I change is hard. Change at scale is really hard. If I'm changing, I want to change to the future, not just to a more recent past.
Anne: Yeah. so okay. So so from what you've heard and what you're thinking, what do you think that future looks like? What do you think a good future looks like that we should be aiming for?
Jon Berger: So I I think the things the baggage that we need to let go of is is all of the limitations in software that only exist because it's humans doing it. They d they don't have another good reason. Some of the things that we've learned over the decades have really good value and we need to keep them.
Anne: Mm-hmm.
Jon Berger: Or the AI will want to keep them because they are useful structures and ways of deploying and maintaining software. And others are only there because we are quite limited in our context window, or we get replaced fairly frequently and we can't ramp up in microseconds, or because We have limited communication bandwidth, which means that our our sort of horizontal scaling in the team is much more limited than than that of an AI. and I think an awful lot of software development, probably most of the difficult stuff in software development, over the last 30 years, is trading off those things against the things that you really want to have, which is you know, your function, your security, your performance, scalability, all of those things. So it's like how do you develop d deliver all on all of those and offer a service that the customer wants as cheaply as possible while still being scalable? And I think what you're alluding to on the performance side is that performance in most areas of software development has been one of the things that is tends to lose out. because it's humans maintaining it because very high performance code is really hard to maintain. Really, really hard to maintain. more so than most other function or or illities in your code. So I think one of the things we will get with code that's purely AI generated is it will say, not today, we're not there yet, but in let's say ten years time, it will be a lot faster. It will be a it will use a lot fewer resources to do the same job.
Anne: Well, say it's so I'm I'm gonna c take pull you up somewhat on that, which is it it might be. It could be, but it won't necessarily be. I mean, not all code will people bother to optimise it. Or well well, I think if you go far enough down the road, then all the people are out of the out of the loop entirely and it will just be optimized. Is is that what what what you're saying that that that there'll
Jon Berger: I think there will still be different levels of optimization because there are there will still be trade offs, right? There will be Do you want or need to have different versions of your code on on plat different platforms? maybe, maybe not. Do you I mean one of the trade offs that's that's just inherent in in code and is affected by maintainability, but e even if maintainability is free is still something you have to think about, is things like size of code versus performance. where there are things that you can do in your code base which make it flabby. but perform better. They often also have a s some of those things also have a maintainability deficit.
Anne: Yeah.
Jon Berger: those will still be trade offs that in a in a purely AI written world someone or some AI will need to make.
Anne: Yeah, I suppose yes, what you're saying there is a is that's a s and essentially almost a hardware trade off say it's like kind of how does it fit into the cash type questions, which are not just about human limitations, they're about hardware limitations. And even if we take humans out of the mix, because AI does it, the hardware limitations still remain.
Jon Berger: Yeah, and that and there will be things where maybe it still costs the AI more to write software. That I don't know. I mean, it may be that once software becomes pretty good All the software, you know, the default is just it's it's excellent. Maybe. That's not the default at the moment.
Anne: Well it's No, no, no, it's it's not. Even even with with with good code bases like the Rust code base, it's it's it's not a totally per you know, it's it they're not the code isn't training the AI to write performant code. Even in Rust, although probably more in Rust than in well, Python.
Jon Berger: one of the things that needs to happen and and is already happening to get us to that future is that AI needs to learn to write code not just by reading human code. So if you look at the AI, the AI training that people are familiar with from the concept of LLMs, where it essentially looks at a body of work created by humans and and and s and to some extent emulates that, is actually very different from the sort of AI that Alpha Go used to learn how to play Go by playing against itself, working out what worked, what didn't work, and and it was quite innovative, right? So Yes, it would play initially relatively naughty moves, worked out whether they worked or not. But then as a result of playing gazillions of games against itself, it created new strategies that humans had not seen before, and that allowed it to beat humans bec because it had trained itself on on what really good looks like, which was beyond what humans could do. I think software needs to go the same way to get to where I thinking. And and people are already starting to do that.
Anne: yeah, so you're thinking they're a totally there's there's no humans in the mix whatsoever way of doing software development, which is basically a couple of AI of AIs fighting against one another, battling against one another to produce the the better instance of the product that you almost like a a little microcosm of companies battling against one another to produce the products that it will be the the the leading product. That's that's That's an interesting question.
Jon Berger: Yeah, I I guess I wasn't even really thinking about it as competitive in that sense, more competitive in just can I make this better? You know, if I write this code in this way, does it still pass the functional tests but do so with some other benefit or or or whatever? But as a as a not an expert in how to train an AI, I don't know whether that would be more or less effective. Yeah, it's an interesting of thinking. You the the there were definitely teams I work with in other companies in the past who when when they when they had a a complex problem they would set three teams off running and say, Go build this thing and whoever whoever built the best one of those still had a job at the end of it and the other two teams got sacked. that that that is one way of doing
Anne: Yeah.
Jon Berger: I don't think that's the cleverest way of doing it, but I don't know.
Anne: Yeah. It's interesting. So obviously of the of the up of our recent episodes that have been about AI, about really genuinely ambitious AO generated code. So the kind of AI generating the kind of code that your teams used to write, mission critical code type thing. That is like Dustin Colmack talking about recreating Amazon S three and Martin Davidson talking about doing all kinds of things that he was doing.
Jon Berger: Well,
Anne: it was what that Martin Davidson was using quite an adversarial system. You know, he had two, he had he had multiple chatbots, different models, almost competing against one another in in helping him. Justin was taking a slightly different approach where I d I think he just had one model, but he was a big, quite a big part of it.
Jon Berger: Yeah.
Anne: But as you say it's
Jon Berger: I I heard I heard Martin's statement more collaboratively than that, th rather than competing. But yeah, I could s I you could take it either way, I suppose. Yeah, I don't know. I don't know whether he was, for example, genuinely you know, having different models create different ideas to see which was best, that sort of a that sort of evolutionary approach versus a try something, change it, see
Anne: Yeah.
Jon Berger: See what happens, sort of model. I'm not sure.
Anne: Well we'll get Martin back on again. And we'll get Martin to listen to this. And so one of my questions is, we've got a lot of questions for Martin. We'd quite like to know how much he spends, which is a question we never asked. what's his what's his token spend? What kind of budget does he have to to do all this experimentation? But also, would he consider what he's doing to be essentially collaborative or essentially competitive? Hmm. But yeah, we'll have to ask him. but yeah, yes. So so coming back to to that, you were saying that that I mean your background is that you ha you often had a problem, which is we needed the y you worked in networking code, so it wasn't just mission critical, it was networking software, which is unbelievable which has to be unbelievably fast. And but the the the the blocking thing for you over and over again was it has to be unbelievably fast, but it still has to be supported by humans and written by humans. That was that was your kind of bottleneck. your prime would you say that was your primary bottleneck?
Jon Berger: the the fact that it had to be done by humans. I was responsible for lots of different products in quite a lot of different spheres, all generally under the heading of networking. But some of that was very much management plane, some of that was data plane, some of that was control plane, and all the things that go go around that. for sure there are times when the limiting factor is a human has to do it. equally a lot of your limitations really just comes from your from the sales environment and what your customer what your customers will tell you or allow you to do and and so But but it but I I just think it's a completely different game. You know, I I just think that that that's why I think it's interesting to see well where could we get to? One of the reasons why it's important to look at where you could you get to rather than how do you evolve there is because if there's a way if there's a place that you can get to which is way better than the place you can evolve to. The new entrants that just go straight there that don't need to evolve will eat the lunch of anyone who's evolving. Yeah, that's that that's that's that that's how economic So that's why it's an interesting question to ask and not just say how do we evolve?
Anne: Yeah.
Jon Berger: I think you've got to do both. If you've got a business today, you've got to work out how you can evolve. And and what we're talking about now, right? Almost nothing we're talking about like what fully exists. We haven't even started talking about what the thing looks like yet. But it's it's not about what you can do today. But but if you can understand where that might get you to, then I would think you'd be able to start evolving in that direction in a way that you can maintain the evolution and get there such that you can maintain your business. can still be in the nirvana of super fast, cheap code that does everything in the future in a way that means that someone else doesn't get to eat your lunch because you're never far enough behind them that they've got an advantage there and you've got the advantage of having a an existing product set and existing customers and money coming in.
Anne: Yeah, yeah. Yeah, that should always be a you real you want that to always be an advantage, not a disadvantage. But but yeah, so so as you're saying, we haven't we've been we've talked a lot about kind of the transition here really and and what what you're really on here to talk about today is where are we going? What's the purpose? What is what are we aiming for here? 'cause you've been doing a bit of thinking about that. So I'm I'm very interested to hear your thoughts on Where are we going? What will good look like in ten years time? Do you think? Is your current thinking?
Jon Berger: Okay, so this is not particularly an ordered list, but the first thing is it will it will all just be machine code. I don't see any good reason why high level languages need to exist in in ten years time for for for for the front end of software development. That they are just they are a brilliantly useful human construct. But they and and during the transition they're very helpful as well. But in the long run they have their only advantage I think it will turn out to be that humans can read them more easily. And I don't think that is a big enough advantage. There are transitional advantages to languages beyond that as well. But once you've actually trained AI on what the output of a compiled version of that looks like and then allowed it to optimize to do even better. I think we'll find that human readable languages are something that exist just because humans like to read.
Anne: It's so it's interesting because in the last episode with Justin Cormac and his experiments, he I mean, he's a big language fan, and I I know almost nobody with such an encyclopedic knowledge of all the different languages and all the pros and cons and what they're there for. He was really using languages as a way to effectively guide the AI when he wasn't guiding it, when he wasn't there, when it was building stuff overnight, he was using the structure.
Jon Berger: I can be agreeing.
Anne: languages to do that. But it but he did also mention another thing, which was when he hadn't given, when he'd given his AI, Claude, I think it was, wasn't it, that an instruction, but not, but he wasn't watching what it was doing too closely, and it couldn't do it with the languages that sh that he'd made it, or the tools he'd made it available to it. It had just gone in and edited the binary, edited binaries to to get the result he that that it that it wanted.
Jon Berger: Remember when we used to have to go and edit binaries? That was how you made that was how you fixed bugs. Yeah. Those those were yes, quite a lot of effort. yeah, I I I I agree with Mart with with Justin's logic on the the short term value of languages because AI can't yet do what I'm saying. It can't yet write excellent machine code. But once it can I can't see any reason why you why why anything else would be better. Right, that's a it's a tr those those languages are a transitional technology as far as I'm concerned.
Anne: Yes, I mean there is plenty of machine code out there for it to learn from.
Jon Berger: Well, and which will mostly be terrible because it's A A it's software, so it's mostly terrible, and B it's c compiled from human readable languages. So it it just won't be as efficient as it could be.
Anne: Mm-hmm. Yeah, I I see what you mean that there's we're still looking at the obviously look everything, almost everything that it's being trained on at the moment is the waste product of sloppy humans. rather than something that it had created from scratch. I mean something else that that Justin mentioned in his in his episode was pony, which is actually a language I'd never heard of before. But Pony and the and the guy who'd invented Pony was creating his own training set, because there wasn't a great deal of pony training set, for the AI. And in some ways that represents a world of the future where the AIs create the training sets for other AIs and they're clean and they're perfect. Is that what you're s kind of envisaging?
Jon Berger: Well, that's what I'm saying. The the once you're if you're training if if if you're training your AI to write code by actually just checking the output of the code, not by saying, What has someone else written in the past? Right? Maybe a combination of the two initially, then you You you don't the the languages give you some constraints, which can be useful. they allow you to write code faster, which can be useful, but but I don't see either why why I don't see how either of those help you in the long long future. I would say those have they have more negatives than positives. the the the the thing that might might change the way that works, I suppose, is that I don't know a lot about semiconductor design, so I don't know how much of that is constrained by humans, whether the the machine code looks completely different because the machines it's running on are completely different, whether you can create much more efficient machines. I don't I don't know what the what the the limitations look like there.
Anne: Yeah, that's it.
Jon Berger: I would guess you can because I think there are some features, some hardware features are are sort of almost aligned with the way software engineering is done at the moment.
Anne: no, we need to get in a hardware.
Jon Berger: And and you know, once you're running on biological computers rather than rather than Silicon Yeah, who knows. But anyway, language machine code. That's that's that's my view of that.
Anne: Yeah. Okay, so that's one. You said you had a couple of thoughts. So your first one is there will only be machine code.
Jon Berger: Exactly. Yeah, I I think so I think libraries, open source, code structure, I think that changes quite a lot as well. But the point where you can you can create just the software that you need and you and you have trust in it, right? The the transition from here to there is all about trust really. then once you've got trust you don't need open source you because you you don't need libraries. They're not really they're not they're not adding value. They're not fundamental to the way that code is going to get executed. you probably still need microservices, but not in not for all of the same reasons that microservices exist today. There are microservices do a number of different jobs for you. Some of them are about humans, some of them are not. So like reusability doesn't help you very that is is not is is not necessary. for example, trust boundary limitations are not are necessary may be necessary across different organizations, but not within an organization in the same way. But there are other aspects of microservices which are brilliant for, you know, resilience, your resilience architecture, in which that is still a great resilience architecture. So they would exist for that reason.
Anne: So that's that's interesting because I Sam Newman is going to be a f is a future guest on this podcast, author of O'Reilly's Building Microservices, and his new book is about resilient sisters distributed systems. And I I think they do do do almost reflect two different things that that microservices were often a kind of developer tool to limit the scope of a problem so that a an individual or a small team could work on it without stepping on on the the treading on the toes of other teams. And it was it was always a a a developer parallelisation of developments and development teams tool. It was a team for a tool for developers. But distributed systems are are are an operational tool that help you to kind of like, well, I'm running 10 copies, so if nine of them fail, I've still got something running and and you can scale up. horizontally rather than vertically. You know, it it's an operational tool. So a microservices, yes, yeah, it does have two completely different use cases. And as you say, one use case is a very human use case, which is allowing humans to work in parallel with other teams of humans. And one use case is just a physics use case, which is sometimes hardware fails and it's useful to have multiple copies of things running.
Jon Berger: Yeah. I I mean interestingly, Martin told us that even with AI writing all his code, he found it useful to break things down into microservices or libraries so that they had such that different AI agents can operate on one piece at a time. it sounded more to me like that was a sort of limitation in what AI can do right now rather than something that would necessarily still be true in ten years' time.
Anne: Yeah, yeah, it's hard to yeah. It's so that but that well, actually you're you're right. That was an interesting point. I don't know if Martin said that in the podcast or but yes, you're you're right. So in some ways, counterintuitively, some of the stuff that we learned about making teams more effective also makes AIs more effective because they do tread on one another's toes, especially in this kind of like
Jon Berger: I think that I think that was when we had a coffee with him.
Anne: they're they're all trying to compete to somewhat with one another. You you want to kind of you w you do want to have those trust boundaries in there.
Jon Berger: So yeah, MarkSaves libraries, no need for open source because you just rewrite it all from scratch. Similarly, code control is completely different. You know, code control is great for humans who need to evolve code in small, you know, one line at a time. But if you're just rewriting it all from scratch every time, then it's just getting in the way. some people are already talking about. Well, there's no point in controlling c code, but but prompt control might be useful so that you know what what you asked for. I think that's that's probably an intermediate step as well on the way to AI actually just running a service where it where it can evolve things, but that's I think that will move in that direction. I think diagnostic's gonna look enormously different, but you know, the fact that they have to be human readable interpretable at the moment. So I think that would be interesting to see where that goes. I wonder if there's some some fun there where just by monitoring other other Things that happen on the CPU you can you can actually just work out what's going on. There have been there have been all sorts of reported security, like super sophisticated security attacks based on listening to the sounds that CPU gives off give off and and voltages and fans and a and temperature sensors and things like that. I I just wonder whether there are ways of again this comes back to a performance trade-off like it it's how much how much diagnostics you've got. Dig yeah you know in i is there a world in which excellent diagnostics doesn't cost doesn't have a performance trade off. yeah, don't maybe that would be interesting.
Anne: Yeah.
Jon Berger: Low level structure is a is another interesting one, which I haven't heard anyone else really talking about. which is that there's an awful lot the way we write code, which is, you know, within the language, which is just which is about maintainability. and and it's sort of about having just one code base really and not duplicating things too much. repetitive code is is just harder to maintain. I mean in in in the world of in the world of networking software, if you imagine the you're processing different types of packets and your packet processing for IPv4 packets and IPv six packets is similar, but not exactly the same. And there are a series of tests that you you you want these things to go as fast as possible, but you've gotta you've always gotta check, you know, where the packets come from, is that legal? Is it a valid packet? Is the addressing okay? That's that's obviously IP dependent, do I just need to drop it? Or does it go through shapers or whatever? So there's there's a lot of sophisticated questions that are going on on each of these things. And they are they are sometimes they're literally exactly the same. Sometimes they're just conceptually the same, but the actual low-level operation you're doing is slightly different depending on whether it's an IPv4 packet or an IPv6 packet, for example. So you might well have in your in your stack a whole series of of if tests where you know if it's IPv4 process it this way, if it's IPv6, process this way, then a bit of common processing, then another if I'm IPv4, do it this, if I'm IPv6, do this. and that makes the code more maintainable. but it is slightly more expensive because each of those if tests costs you performance. If you just duplicated the entire thing and asked the question once is this an IPv4 packet? All of the code. If it's an IPv6 packet, almost exactly the same code, but not exactly the same code. But the fact that it's almost exactly the same, but not exactly the same, would be an absolute maintenance nightmare for a human being. But not for an AI. So there's I think there's a massive opportunity to sort of
Anne: Mm.
Jon Berger: I don't know whether there's a name for it. It's a bit like loop on rolling, but but sort of for if testing. So you just separate out everything. And if you've got repeated if tests, then duplicate massive code duplication in some cases will help you a lot with performance. Maybe that won't be common, but there will be, I think, a lot of cases where. That sort of construct is something that will really help you. And then you go back to the performance question we've got, which is like, well, okay, how much of that unrolling helps you? If the code gets much fatter, is that good or bad?
Anne: I think what you're saying is it's like the opposite of dry. You know, it's like the no, it's not it's not the opposite. Well it's it's not exactly dry, but
Jon Berger: Not exactly the opposite, but but yeah, it sort of is. The the it if you can write code in a way that there's just much less to execute because it's just fatter. But you you know, the the bit you're executing is fat but has fewer tests in it because you've identified up front that some of those tests are not needed. You know, you you would you would have to save as a human being, you would have to save an awful lot of performance there to ever be bothered to go down that route. And to be clear, in networking code, sometimes we have done that, right? In the data plane.
Anne: Yeah.
Jon Berger: packet processing, there is some like super speedy stuff out there, which is really hard to maintain because of those sorts of tricks are being played. But that's way not normal. But that becomes accessible in lots more spaces.
Anne: I'm gonna predict that it's gonna be called wet code, when you make the code as quick as possible, but you don't worry about repetition. But that means we need to think of a something something starting with W, something starting with E, and something starting with T. But anyway, the opposite of dry.
Jon Berger: Wow, extremely we're beginning with T that means fast.
Anne: I can't think of it instantly and then Yeah, I will think W E T. That's you've heard it hurt here first, folks. Wet code is code that where there's no attempt to make it dry. Because the dry, I mean I I remember it's almost
Jon Berger: You can edit edit i in later. Wow. Extremely
Anne: You know, when I was a first a developer 30 years ago, almost the first thing I learned was dry, do not repeat yourself. That is the classic way to make code more maintainable, is that you don't repeat things because then you have to worry about whether or not a code that the two identical bits of code, maybe there's a bug in it, then you have to find the other one to fix the bug in both places, and you never do fix the bug in both places, so you get you experience smoke with the bug twice. It's it's just a maintenance nightmare to have lots of copies of the same code all over the place. Heads do not repeat yourself, dry was like an absolutely foundational piece of advice for developers to learn. And it is a very good example of now we're saying, well, in an AI world, if if humans if you don't have to worry about maintainability by humans, if maintainability of code becomes a lot cheaper, then yeah, dry goes out the window. What is your new approach?
Jon Berger: And and I think as AI writes more code, it will spot more things like that. In in the same way that AlphaGo didn't just learn to play Go and then play it as well as a really good player. It actually created strategies that humans hadn't. because of the way it taught itself. And some combination of its greatly expanded context window or memory or maybe it was just luck in the way it evolved its its algorithm, I don't know. But but it went beyond the state of the art. I think the same will be true here.
Anne: of
Jon Berger: And then you get to a point where code just co couldn't be maintained by humans, right? Even even humans that that can read machine code, just like, well, you know, I can't hold enough in my head to be able to do that. Maybe it will look lot maybe it will look in some ways a lot more like code we used to write 40 years ago when we had like no resources whatsoever to play with, and you had all these weird tricks that you ended up playing with the CPU to try and get it to do what you wanted without. I mean the the limitation there was always j was almost always just on the code size. but There's all sorts of fun that you can do that, which just you which you can't really do commercially on a product that's that's maintained and out there, but but you don't need to. I may maybe maybe you've got a service that runs every day of the week and and it does slightly different things every day of the week. And you've got an if test, is it a Tuesday? Now you just have Tuesday's code automatically runs on Tuesdays, Tuesday's running Tuesday's code, just Wednesday is running Wednesday's code. But it would have to be a reasonable performance benefit to to be doing something like that, but those things are available.
Anne: Yeah. So okay, so that's cool. So what else? What else? What else?
Jon Berger: I suppose the I mean the other the other obvious thing is that all APIs at the moment are just like the slowest things in the world because they're human readable. human readability in in on interfaces is probably one of the biggest performance killers that we have. yeah, definitely getting it.
Anne: and of course and that, of course, interestingly, that was a huge revolution in our working lives as developers. when we when we both started as developers, in and we were working kind of not just networking, but but kind of I was actually working in in applications, I was working on Microsoft Exchange, not not not even super fast or not deliberately super fast code, and all messages were exchanged in in a binary format called ASN1. And it was really hard to debug things because you had to decode these these binary structures in order to work out what what data was being passed between between computers. And then but back then we had almost no resources and those binary, they were quite small and so they were quick for machines to parse and they were quick, they didn't take up much bandwidth. But almost the first thing we used additional bandwidth for as the internet grew was HTML and just passing passing things in text format which are unbelievably bloated and huge, but were human readable.
Jon Berger: Yeah. Well yeah, I mean it's worse than I remember, I mean most of what I worked on, actually even the latest stuff, was you know, was binary, and an awful lot of it was was binary encoded and and pretty efficiently so. but I remember that I think I think SIP was the first protocol I came across that was that was a text-based protocol, and it's like Okay, I get why you might want a text-based protocol because it makes things slightly easier. But it's like it wasn't even it wasn't even specified whether it was uppercase or lowercase. So every time you looked at the message, you had to say it's like, does it say invite in you know upcase I? And then like you know, and you had to test it. It's like all of that is CPU. You're just throwing away to make developers' life slightly easier. That was the first point to me where it was like, wow, software engineering has changed from being like the resources really matter to screw the resources, just just write code as fast as you can. That was that was obvious. That was like late nineties.
Anne: Yeah, it it moved from yeah, ho hardware being the yes, yeah, mid-nineties, hardware being the constraint to cu developers being the constraint. and at that point, yeah, all the hardware got sucked up, making life easier for developers really didn't. So AI will turn the tables on that. Well well, we don't really know, do we? But your prediction is that AI will turn the tables on that.
Jon Berger: I think I think it will make make th those things like that look very, very different. But I think it will I think that that sort of stuff takes longer because again, because it's all about the trust boundaries. And so while it's operating in a mixed environment where you have both AI written code and human written code, then that's that in itself is quite limiting. So how some extent how fast that goes will depend on like how valuable people perceive the latter.
Anne: so have I absor have we exhausted all your thoughts there on what code will look like in the future, or is there anything else that you want to add?
Jon Berger: There was one thing there was one
Anne: about good.
Jon Berger: thing that we we should have talked about really, which I guess sort of we maybe maybe was slightly implied, and you definitely talked about it with with Justin last week was was unikernels. so the the whole unikernel concept was conceptually a step in that direction of yes, you've written An operating system that does all of these things, so it does everything for everyone, but any one use case only requires 20% of all of the things. You don't use all of the drivers, you don't use, you don't even need all of the the the basic functions. that, but more so essentially, is what we'll see in AI or written code. now, whether it will actually be unikernels, you know, w but but but but which it could be, right? If you're certainly if you're not doing anything multi tenant, do you gain anything from having user space, kernel space split? Well no, you've just got code running slower. Kernel case code is harder to write. Not anymore, it's not
Anne: Yeah.
Jon Berger: So why would user space exist? Well, maybe something like it exists in a multi-tenant in a in a in a hypervisor style environment. it's not quite the same thing, but but that sort of split, sure. People might still might still want to do that.
Anne: Hmm, that is an interesting one.
Jon Berger: That's a that's a pretty big structural change, I think.
Anne: Yeah, yeah. Well that I mean that would be that would be a very interesting direction to take. There is only the kernel. There is no kernel and unispa and and user space anymore. so so you've you've put forward a lot of quite radical thoughts there, based on 30 years of you being actually, you know, absolutely deep in the writing of mission critical software that runs everywhere. This kind of system software that runs the world. No more code, machine code only, no more humans in the mix, no more potentially user space, only the kernel. and yeah, and we haven't talked, and as we say, we deliberately haven't talked about how we get from here to there, which will Depend massively, won't it, from company to company. It will depend because some people will be starting from scratch here and some people will need to. that is another episode. So well th so thank you very much. you give me plenty to talk about. And since you're only upstairs in my house, I imagine we will be continuing to talk about this for for for quite some time. And I'll see if we can get Martin back in.
Jon Berger: I think that's another I think that's another episode.
Anne: and there are various other people who I think might want to put their ore in on this discussion. Justin, for example, might want to c to come back in and say, well, hang on a minute. don't get ahead of yourself. Although I think that Justin at the moment is more focused on the transition than the the kind of the the total end game. Although ironically, he was more focused on the total end game ten years ago when he was involved in Unikernels, which was massively ahead of its time in many ways. Fantastic project. Anyway, thank you very much for being on the podcast. And thank you very much to all the listeners and I will hope and watchers and I hope that I will catch you again on a future episode of a synchronous and unreliable podcast. Thank you very much. So thank you for listening to the last episode of Asynchronous Unreliable. But now I have some work for you. We're very keen to answer questions that are submitted by listeners, take suggestions for who we should contact to come on the show next. we're you we're always very happy to do that. And you don't have to record a snippet yourself, you can just send in a message. so you can contact me in if you're on YouTube, you can add things to the comments. If you if you're not On YouTube, if you're listening to this on a podcast, you can reach out to me on LinkedIn. I'm Ann Curry. Very happy to connect to people. Just just reach out and connect, and I'll and I'll connect to you and you can send me your your questions, your ideas, your thoughts. And of course, your thoughts on what W E T, wet programming, the opposite of dry programming. What should that TLA stand for? Now at the moment, the one that's in the in the lead is Gemini's suggestion, which is writes everything twice, which I quite like. We do quite like that one. So but you know, if you if you're a human and you have an idea, please do let us know. So thank you very much indeed and we are very, very keen to hear from you. Thank you.
