Author: Anthony Alford Roland Meertens

Transcript

Roland Meertens: Okay, so for the fun fact today, I know that the city in Colombo, in Sri Lanka, they created a model of their city using the video game City Skylines. And this is meant as a digital twin. Their citizens can basically use it to understand the impact of decisions such as changing roads, adding more green space. So they created all kinds of digital assets to make the simulation look more realistic. 

They changed some parameters of the game. And the funniest change is that they modified the behavior of the traffic to reflect Sri Lankan driving habits, which includes buses may ignore lane arrows, vehicles may enter blocks junctions, vehicles may do U-turns and junctions, 10% of drivers are reckless, vehicles may park on sides of streets, and three wheelers and scooters are introduced.

Anthony Alford: And they drive on the wrong side of the road, no doubt.

Roland Meertens: I mean, 10% of drivers are reckless, I thought was the funniest change they made.

Anthony Alford: That’s optimistic, I imagine.

Roland Meertens: If it’s only 10%.

Anthony Alford: Hate to see those numbers for my hometown.

Roland Meertens: Welcome to Generally AI. This is season two, episode five, and we are going to talk about simulation. It is an InfoQ podcast, and I am Roland Meertens here with Anthony Alford.

Anthony Alford: Hello, Roland.

Roland Meertens: Shall I get started with my simulation topic for today?

Anthony Alford: Please begin.

Sampled Musical Instruments [01:50]

Roland Meertens: All right. So earlier this season, we already talked about sampling music, right?

Anthony Alford: Yes.

Roland Meertens: However, I wanted to take this a step further and talk about how you can simulate playing a real instrument using a virtual instrument.

Anthony Alford: Like Guitar Hero.

Roland Meertens: Oh man. I love Guitar Hero.

Anthony Alford: Or Rock Band or one of those games.

Roland Meertens: Did you ever play that by the way?

Anthony Alford: I tried it once and I was terrible.

Roland Meertens: I was really good at Guitar Hero, and then I started playing more real guitar and then I became terrible at Guitar Hero.

Anthony Alford: Not to interrupt your train of thought, but you’ve probably seen the video of the members of the band Rush playing one of those video games and they’re playing a Rush song.

Roland Meertens: I didn’t see that.

Anthony Alford: They’re so bad that in the video game, the crowd boos them off the stage.

Roland Meertens: Yes, I know that feeling.

Anyway, the bigger problem I have is that not everybody has space in their house for an actual instrument, or alternatively, your neighbors might not like it, like my neighbors. So instead of buying a real piano, you can buy an electric piano or you can buy MIDI keyboards. And the interesting thing is that some of the cheaper models, if you buy a super cheap keyboard, it’ll probably, instead of playing a note, it will just play like a sine wave, call it a day. But of course, real pianists want the expressiveness of a real piano.

Anthony Alford: Yes.

Roland Meertens: So option one to simulate the sound of a real piano is to record the sound of a real piano and then play that. So you can buy all kinds of kits online, like all kinds of plugins for your digital piano. They record it hitting keys on one specific piano in all kinds of different ways with all kinds of different microphones. So I’m going to let you hear an example of that.

How did you like this?

Anthony Alford: That’s very nice. It’s very convincing.

Roland Meertens: Yes. So this is the virtual piano, but then with recordings from a real piano.

Anthony Alford: Okay.

Roland Meertens: If you want this, it’ll cost you $250 for the pack alone.

Anthony Alford: So is it software? Do you use a MIDI controller, and then does this software run somewhere?

Roland Meertens: Yes, so I think this is a plugin. You can use it as a plugin, so you import it into your audio workstation, and then you play with your MIDI controller. So the MIDI controller will tell the computer what key you’re pressing with what velocity, et cetera, et cetera.

Anthony Alford: Very cool.

Roland Meertens: And I know that professional musicians, they all have their favorite virtual recorded piano they like to use, which they think sounds very good. So that’s interesting. I’ve never bought something like this.

Anthony Alford: Well, I don’t know if this is the right time in the podcast to interject it, but I’m sure you’re familiar with the Mellotron.

Roland Meertens: That’s pure sound waves, right?

Anthony Alford: Well, it’s the same idea. It’s an instrument…probably most famously you can hear it on Strawberry Fields Forever by The Beatles, but they did exactly that. They did audio recordings of real instruments. And so if there’s 50 keys on the Mellotron, it’s a keyboard instrument, there would be 50 cassette tapes.

Roland Meertens:Yes, yes. I now know what you mean. So every key has a certain cassette tape, which then starts going down and playing it, but that’s still sampling. And in this case, I guess it’s also just sampling. So you are trying to simulate.

Anthony Alford: It’s simulated in the sense of…basically just play back a recording.

Roland Meertens: Yes. But then per key, you only have one possible sound.

Anthony Alford: Exactly.

Roland Meertens: Whereas this one already took into account with what velocity you press the keys.

Anthony Alford: Oh, okay. So it has a sound per velocity almost, or could be.

Roland Meertens: Yes. So they press each key probably 25 times with different velocities, and then they record all the responses there. And this is why the software is so expensive. It’s not like someone just recorded 88 keys and called it a day. No, no, they did this 88 times 25 times, plus adding the sustained pedal or not.

Anthony Alford: It’s combinatorial explosion here.

Roland Meertens: Yes, I think it’s good value you get here.

Anthony Alford: Yes, I love it.

Roland Meertens: Well, so the other thing I was looking at is instead of sampling piano sounds, I went to the Roland store this weekend where …

Anthony Alford: Did you get a discount?

Roland Meertens: No, I had to pay like $45 for this t-shirt. No. So one thing which they do is they have a virtual drum kit. So instead of clicking on the pad and then hearing a drum, they actually have a real looking drum kit, but then when you smash it, you only hear like “puff”. So you only hear the sound over your headphones.

But I tried playing it and it still feels like a real drum kit. So the cymbals are made out of rubber. So it kind of looks weird, because it doesn’t feel exactly like a cymbal, but it sounds in your ears the same as a cymbal. And one big benefit here is that you can easily select different sounding drum kits.

Anthony Alford: Okay.

Roland Meertens: So if you want more like a metal drum kit, you select it. If you want a smooth jazzy drum kit, you can select it.

Anthony Alford: And this certainly sounds like a good solution if you have neighbors who are noise sensitive. So all they hear is pop, pop, pop, pop.

Roland Meertens: I also think that if you want to sell your house and you have a neighbor who likes to play the drums, buying this for them will probably increase your property value.

Anthony Alford: It’s worth it for that alone.

Roland Meertens: Yes. So it will set you back around $5,000, by the way.

Anthony Alford: Wow.

Roland Meertens: So I have printed it out. If you ever want to start a new hobby and not annoy your neighbors, this is the way to go.

Anthony Alford: Nice. I want to annoy my neighbors with my hobby, so I’m going to get the real thing.

Roland Meertens: In that case, I think their flagship drum kit at the Roland store was about 10k. Yes. But then you get real drums. Anyways, I will let you listen to how the drums sound.

Anthony Alford: Yes.

Not bad.

Roland Meertens: Sounds realistic, right?

Anthony Alford: Yes.

Roland Meertens: I think this is a perfect replacement for real drums, or at least it felt to me like. I would be quite happy.

Anthony Alford: Play along to that.

Simulated Musical Instruments [08:36]

Roland Meertens: No, absolutely. However, this is the simulation and not the sampling episode. So I wanted to know if people ever simulate sounds, and one of the articles I found was by Yamaha.

Anthony Alford: Of course.

Roland Meertens: Well, you say of course, but so Yamaha I think sells digital keyboards, but they also sell real pianos.

Anthony Alford: Yes. And motorcycles.

Roland Meertens: I did actually own a Yamaha scooter as a kid.

Anthony Alford: I mean, whatever. They’ll make it.

Roland Meertens: Yes. I always wonder how they went from instruments to scooters and motorcycles.

Anthony Alford: Or the other way around.

Roland Meertens: Yes. So they do have a webpage. I will link all these things in the show notes, by the way, but they do have a webpage where they talk about this, and the reason they say that they simulate sounds is different than you might think. They do this not because they want to create a virtual keyboard, but they want to know what a piano sounds like before they build it, and they want to know what design decisions impact their pianos.

Anthony Alford: Oh, interesting. That’s very clever.

Roland Meertens: Yes. So their flagship grand piano costs around $50,000. We are already going up in price here now.

Anthony Alford: How much does the motorcycle cost?

Roland Meertens: Yes, indeed. Yes. You get to choose one hobby in life. But yes, so I can imagine that if you want to build such a high quality piano, you want to know beforehand what design decisions impact the sound in which way. So yes, that’s something which I found fascinating is that they say they are using simulation to improve their real physical products.

Anthony Alford: I had never thought of that. That’s very clever.

Roland Meertens: Yes. The other thing, by the way, is that when I was looking at simulated pianos, one other reason you might want to simulate a piano is: imagine you find a super old relic piano from the past, but it’s important for historical context, right? Maybe this is the piano Mozart learned to play, or the piano George Washington imported. I don’t know.

So you don’t want to play it a lot because it might damage the piano. Or maybe it’s partially broken, maybe some keys are missing, some strings are missing and you don’t want to repair it or it’s too difficult to repair it. You can start simulating that piano and maybe simulate over a couple of keys, maybe play it once, and then record the sounds and then simulate the rest of the piano. So there’s definitely reasons that you want to simulate sound beyond “I’m a musician and I want to have a good sounding piano”.

Anthony Alford: Yes, that makes a lot of sense. My mind is just churning over the Yamaha thing. First of all, that’s one of those situations where you can make your model just as detailed as you want, and you could probably still keep going even after you think it’s done.

Roland Meertens: Yes. In that sense, I tried finding academic papers on this topic, but I didn’t find a lot here. I expected the field of simulated music to be quite large, especially because it feels relatively straightforward that you want to simulate a vibration of a string and you want to simulate how felt on the hammer impacts the string, and you want to simulate how the noise spreads through different surfaces.

So it seems like a relatively straightforward way for me as an engineer, but there were not a lot of papers of people comparing their simulation, or at least I didn’t find it.

I found one academic paper called something like Modeling a Piano, and this person had a lot of pages with matrices on what effect everything had on everything. But the paper concluded with, oh, we didn’t implement this, but you should probably use a programming language like Rust or Python or something.

Anthony Alford: I was actually speculating they probably consider it a trade secret, and it’s probably some ancient C++ code that only one old guy about to retire knows how it works.

Roland Meertens: Yes. I do know that, just continuing to talk about Roland, if you buy their amplifiers, you have a lot of artificial pedals in there. So it’s basically a software defined amplifier. And there you even have people who used to work on this technology and who retired, but who are still creating software packages for these amplifiers to make them sound like different types of amplifiers. So you can make your guitar and your amplifier sound better because there are people who are so passionate about this that they keep improving the software.

Anthony Alford: These people make the world go around sometimes.

Roland Meertens: Yes. Shout out for those people, whose names I forgot.

Also, the fun thing about this Modeling a Piano paper is that I found out that it’s basically a third year master’s student at a school of accounting who created a whole mathematical model of this piano playing, but then didn’t implement it.

Anthony Alford: Talk about somebody who just wanted a hobby. And your neighbors won’t mind if that’s your hobby.

Roland Meertens: I think with mathematics, it’s always about giving it a go. Anyway, as a consumer, you can buy simulation software for pianos, and that is that Arturia makes a piano simulator that’s called Piano V3. This one I actually own, and this one can simulate any kind of piano, has a lot of settings like what kind of backplay do you want, how old should the strings be?

And this package also costs $250. So you can either shell out $250 for recordings of a piano or for something which simulates a piano and different types of microphones and positions. Do you want to listen to a small piece?

Anthony Alford: Let’s roll that tape.

That’s very pretty.

Roland Meertens: It is quite expressive, I think. Yes. I do still have the feeling that it feels a bit more sine-wavy, and I have the feeling my MacBook speakers don’t handle it well because it seems that for a lot of the output of this, especially this program, it just seems to vibrate the keys of my MacBook in such a way that is really annoying.

Anthony Alford: You could do it with headphones, I suppose, and it would sound really good.

Roland Meertens: And then my neighbors would also be happier. So yes, that’s the outcome. There is software which can simulate how a piano works.

Anthony Alford: Very cool.

Roland Meertens: Yes.

Anthony Alford: I’ll have to check that out.

Robot Simulation – The Matrix [17:11]

Anthony Alford: Well, Roland, you were talking about Yamaha modeling and simulating the piano before they build it to see how those design decisions affect the sound of the piano.

Roland Meertens: Yes.

Anthony Alford: So imagine you’re doing that, only you’re building a robot or an embodied agent, embodied AI. Nobody does robots anymore. Okay, so when you write code without the help of an LLM…at least when I write code, it doesn’t work 100% correctly the first time.

Roland Meertens: Oh, no.

Anthony Alford: Usually, right? So the downside of having a bug in your robot code could be pretty big. Just like spending $80,000 to create a piano that sounds terrible. You have a bug in your expensive robot. So if your code might cause the robot to run off a cliff, or even worse, the robot might hurt someone.

Roland Meertens: Yes.

Anthony Alford: And probably you’re not the only programmer. You’re a part of a team. Well, everybody wants to try out their code, but maybe you only have one robot because it’s expensive, or you might have a few, but they’re shared.

Or let’s say you’re not even programming the robot because we don’t program robots anymore. The robots learn. They use reinforcement learning. That means that the robot has to do a task over and over and over again, maybe thousands of times or more. That could take a while.

Roland Meertens: Yes.

Anthony Alford: What do we do?

Roland Meertens: I guess given the theme of this episode-

Anthony Alford: The Matrix.

Roland Meertens: The Matrix.

Anthony Alford: We use The Matrix. Okay. It’s a simulator, right? Yes. No surprise, right? Spoiler. So testing your robot control code in a simulator can be a way to address these problems. So we’re going to talk about robot simulators. There’s quite a few different ones available, just like there’s a lot of different piano simulators, and I won’t get into really specific deep dive detail. Instead, we’re going to do high level and talk about what you’ll find in most simulators.

Well, the core component is some kind of world model. The world is usually sparser and more abstract than the real world. It’s got the robot in it, and you’ll put other objects in there. That will depend on what task the robot’s for. If you’re doing an industrial pick and place robot, that’s great. All you need is the workstation and the items that the robot’s picking up. You don’t need to have obstacles and other robots it has to avoid. But if you’re simulating a mobile robot, you’ll need walls, obstacles. If it’s outside, you’ll need buildings, sand traps, people.

Typically in a simulator, you describe these objects in some sort of standard format in a file. You define their geometry and other physical properties. There’s some common file formats for these. There’s Unified Robotics Description Format, URDF. There’s a Simulation Description Format, SDF. So the idea is very similar. With a physical robot, you model it usually as a collection of links and joints. So we’re thinking about a robot manipulator that’s an arm. It has joints and bones.

Roland Meertens: And these are standards for every simulator, or is it-

Anthony Alford: Not every one, but these are for some common popular simulators. But the thing that they accomplish is going to be common to almost any simulator. You have to physically define the objects in the world. And robots in particular usually consist of links and joints. And if you mentally replace “link” with “bone” or “limb”, you could probably describe the position of your body that way, your configuration. You’ve got your arm raised or stretched out, do the YMCA.

Roland Meertens: Yes, with your links and joints.

Anthony Alford: So these attributes define the shape of the robot, how it can move. And you can specify other properties like the mass or moment of inertia of the links. And the reason you do that is because the next key ingredient is the physics engine.

So here’s where we’re calculating the motion of the robot and other objects, the forces on these objects, the forces between objects due to collisions, and things like that. So this is basically Newton’s laws. This is the part where we’re trying to protect the robot, trying to save the robot from damaging itself or from hurting other people. So this is pretty important.

Roland Meertens: Yes. The better the simulator is, the more confident you are that your robot is going to behave safely.

Anthony Alford: Yes. So one important piece of simulating robot motion is called kinematics. There’s two directions of kinematics. There’s forward kinematics, and this is where, for example, with the robot arm, you know the angles of the joints. Forward kinematics computes the 3D position and orientation of the end effector—of the “hand”.

And if you recall our previous episode, we were talking about coordinate systems. This is based on transforming coordinate systems. And by the way, the mathematics involved is matrix multiplication. So there’s the matrix tie in again.

Roland Meertens: Yes. So forward kinematics is quite easy, right? Because you know the exact angle of each motor, and then you know exactly where your robot arm is.

Anthony Alford: That’s right. The opposite of that is inverse kinematics. And that’s where you know what 3D position and orientation you want the end-effector to have. You need to figure out the joint angles to get there. And that is harder to compute because you have to invert those matrices.

So now we’ve got the robot’s motion. So we can command the robot, put the end effector at some 3D point, figure out the joints, angles, and drive it to those angles. But there’s also sensors. So the robots usually have sensors. You’ll have things like LIDAR, sonar, proximity sensors, vision cameras.

So to simulate sensor data, especially for those cameras, you need some sort of 3D graphics rendering. And what’s nice is that a lot of the info you need for the physics of the robot in the world can also be used for the graphics.

So you have to include things like colors and textures and maybe some reflectivity and light sources. And surprise, the mathematics for the 3D graphics are very similar: coordinate transformations and matrix multiplication.

Video Games and Other Simulation Frameworks [23:57]

Anthony Alford: So quiz time. What broad class of software usually includes both physics and 3D graphics besides robot simulator?

Roland Meertens: Is it video games?

Anthony Alford: It’s video games, absolutely. All technological progress is driven by video games. And in fact, some of these game creation frameworks or game engines are actually sometimes used for robotic simulation. There’s one called Unity, and there are several InfoQ news articles that cover embodied agent challenges that are built using the Unity game engine.

Roland Meertens: I’m always surprised that if you think about the costs to build an accurate representation of a world, Grand Theft Auto is actually quite good.

Anthony Alford: I wonder how many people are training their robot using Grand Theft Auto.

Roland Meertens: So it used to be quite a lot.

Anthony Alford: Oh, really?

Roland Meertens: Yes. But they explicitly make it hard to use it as an API because they don’t want people cheating in their games, which is a bit lame because it’s just already an accurate simulator of life in America.

Anthony Alford: Hey, come on! Some of it, maybe.

Roland Meertens: I will tell you this, that I first played Grand Theft Auto and I was like, “The real world can’t behave like this”. And I came to America and I was like, “Ah, some of these things are actually true”.

Anthony Alford: I’m so ashamed.

Okay. Since we’re name-dropping some simulation frameworks, I might as well mention a few others. There’s one called Gazebo.

Roland Meertens: Oh yes, I love Gazebo. Yes.

Anthony Alford: I knew you would be familiar with that. It’s an open source project. It’s maintained by Open Robotics, which also maintains ROS, the Robot Operating System. And InfoQ has a great presentation by a software engineer from Open Robotics that is about simulating with Gazebo and ROS.

Roland Meertens: Yes, I actually invited her to speak at QCon AI.

Anthony Alford: I sometimes often seem to be doing the half of the podcast that you’re the actual expert in.

Roland Meertens: Well, I mean Louise Poubel is in this case the expert, right? I just invited her.

Anthony Alford: Yes, you’re correct. Some of the big AI players, in fact, have their own simulation platforms. NVIDIA has one called IsaacSim, and that’s part of their Omniverse ecosystem.

Meta has one called Habitat, and that one has an emphasis on stimulating spaces like homes where people and robots might interact.

Roland Meertens: And is Habitat easily accessible?

Anthony Alford: It’s open source, yes. They do challenges where they invite people to build virtual robots that operate in the Habitat. Yes.

Roland Meertens: Nice.

Anthony Alford: I don’t know if they’re still doing this, but they tried to pivot to this Metaverse thing, which is basically a simulator, but for people, maybe the real matrix, the alpha version.

Roland Meertens: Yes. Meta is not super active in the robotics space, are they?

Anthony Alford: Again, they’ve built a simulation environment and they’re inviting people to build on it, so maybe.

Roland Meertens: And they already have the technology to do accurate 3D localization. They have all the ingredients to create super cool robots.

Anthony Alford: Yes. So Google is doing robotics. Google, is there anything Google doesn’t do? I don’t know.

So I mentioned ROS, and now as it happens, many of these simulations have integrations with ROS. Because the idea, remember is we’re trying out the robot control software, and that really means the entire stack, which includes the OS.

So you’ve got your control software running on the OS, and instead of the OS interacting with the real robot, sending commands to actual motors and reading physical sensors, instead it can do all that with the simulated robot.

But I keep assuming that we wrote control software. Of course, nowadays, nobody wants to hand code control algorithms. Instead, we want the robot to interact with the environment and learn its own control software. And that’s again, as I said, another reason to use simulation. Because reinforcement learning requires so many iterations.

And, no surprise, there are reinforcement learning frameworks that can integrate with the simulators. So a lot of times these are called a gym or a lab. For example, NVIDIA has a framework called Isaac Lab that works with their Isaac simulator. Meta has a Habitat Lab for Habitat, and probably a lot of us remember OpenAI’s Gym. You could play Atari games and things like that. That’s now called Gymnasium, and it integrates with Gazebo and ROS.

Roland Meertens: Oh, so the OpenAI Gymnasium now also interacts with all these other open simulators.

Anthony Alford: Well, at least somebody has built an integration. So you can find integrations. They may not be … I don’t know how official some of them are.

So the key idea with these reinforcement learning frameworks, these gyms or labs, is that they provide an abstraction that’s useful for reinforcement learning. So basically they provide you an abstraction of an environment, actions, and rewards. And because it’s operating on a simulator instead of the real world, in theory, you can do many episodes very quickly.

Roland Meertens: Yes, I tried this with OpenAI Gym. It was quite fun to play around with.

Anthony Alford: So you’ve simulated pianos to various degrees of success. You may wonder how well robot simulators work in practice. Train a robot in the simulated world, what happens when you let it loose on the real world?

Roland Meertens: What’s the reality gap?

The Reality Gap [29:42]

Yes, that’s exactly right. It’s called sim to real, the reality gap. The robot learns from an imperfect simulation, and so it behaves imperfectly in the real world. So this is an active research area, and there are different approaches.

One that popped up a couple of times in recent work is called domain randomization. Now this is where you apply randomization to different parameters in your simulation. So for example, maybe you have a random amount of friction between some surfaces, or you randomly add or subtract something from the weight or shape of a robot link. And the reason this works according to the researchers is it acts like regularization. So it keeps the model from overfitting.

Roland Meertens: Yes, by adjusting the domain just a bit.

Simulation Makes Dreams Come True [30:31]

Anthony Alford: Mm-hmm. So one final thought: earlier I brought up The Matrix.

Roland Meertens: Yes.

Anthony Alford: I was never a huge Matrix fan. I felt like it violated the laws of thermodynamics to say that the people were power sources. What if that’s not actually what happened? Because we could see in the movie that The Matrix is a simulation environment and humans can learn skills like Kung Fu very quickly, just like bam. So what if that’s what The Matrix was actually originally for.

Roland Meertens: The learning environment?

Anthony Alford: Exactly. So believe it or not, as I was preparing for this podcast, I came across an interesting biology preprint paper. The title is The Brain Simulates Actions and Their Consequences during REM Sleep. So basically the authors found that in mice, there’s a motor command center in the mouse brains, and it’s involved in “orienting movements”. It issues motor commands during REM sleep.

So these are things like turn right, turn left. And they found that although the mouse’s real physical head isn’t actually turning, the internal representation of where the mouse’s head is pointing does move. They look at certain neurons that are responsible for-

Roland Meertens: Interesting.

Anthony Alford: Yes. I don’t know how they—they’re basically reading the mouse’s mind somehow. Anyway, they suggest that “during REM sleep, the brain simulates actions by issuing motor commands that while not executed, have consequences as if they had been. The study suggests that the sleeping brain, while disengaged from the external world, uses its internal model of the world to simulate interactions with it”.

So it seems like dreams are like an organic version of The Matrix. Basically we do know that your memories and what you’ve learned do get affected by sleep, especially REM sleep.

Roland Meertens: Your dreams will come true.

Anthony Alford: They do. And so that’s a better tagline than I had. So we’re going to end it on that.

Roland Meertens: Yes, I like it. Make sleep even more important than you realize.

Anthony Alford: So there we go. Let’s sum it up: Simulations make your dreams come true.

Roland Meertens: Probably.

Anthony Alford: Bam. Headline.

Roland Meertens: Nice.

Grand Theft Auto: Columbo [32:57]

Roland Meertens: All right. Last but not least, some words of wisdom. Do you have some fun facts? Anything you recently learned which you want to share?

Anthony Alford: I don’t have something new, but something that occurred to me while you were talking about simulating musical instruments. Supposedly the theremin, which I think we’ve probably talked about before, the musical instrument you don’t touch, I believe the inventor of that was trying to at least mimic the sound of a cello.

Roland Meertens: Interesting. It’s also fascinating that with the synthesizer, people started trying to mimic existing sounds, but then it became a whole thing on its own to use those artificial sounds as its own separate …

Anthony Alford: Brand new thing: square wave, sawtooth.

Roland Meertens: Square wave. Yes. Yes. It’s its own art form now.

Anthony Alford: Definitely. And in a way, a quite dominant one.

Roland Meertens: Yes, no, definitely. And then also, if you think about different eras, if you want to have an ’80s sound, you are thinking of synthesizers, which are playing …

Anthony Alford: Yamaha FM.

Roland Meertens: The Roland 808s.

Anthony Alford: Oh yes.

Roland Meertens: Yes. No indeed. So it is interesting that the inaccuracies also become their own art form.

Anthony Alford: Very true.

Roland Meertens: Where I must say that I often, as a software engineer, strive for perfection, but maybe sometimes you can stop sooner and then just call it a new thing and then you’re also done.

Anthony Alford: It’s not a bug. It’s a feature.

Roland Meertens: On my side, I found this very interesting video yesterday. We talked about juggling robots in the first season, and I found someone called Harrison Low. He is building a robot which can juggle, and it’s quite interesting to see what he came up with because he has a super complicated system with multiple axes, which can move up and down and throw balls and catch balls again. It can also hold two balls in the air.

It doesn’t sense yet, but it’s very interesting to see his progress. So I will put that in show notes, so you can take a look at that.

Anthony Alford: I wonder if he uses a simulator.

Roland Meertens: I don’t think so, but I’m not sure.

Anthony Alford: Now that’s hardcore.

Roland Meertens: Yes. I guess he has some kind of 3D model, so at least knows how different things impact his 3D model.

Anthony Alford: One would assume.

Roland Meertens: Yes. It’s just annoying with the simulations that the devil always seems to be in the details, that tiny, tiny things tend to be really important.

Anthony Alford: Maybe he could run it in GTA.

Roland Meertens: Yes.

One fun thing, by the way, talking about the reality gap is that I always notice in my machine learning career that the things you think matter are not the things which actually matter.

Anthony Alford: Ah, yes.

Roland Meertens: At some point, for example, with self-driving cars, people ask me, “Oh, what’s important to simulate?” And I was like, “Oh, I don’t know”.

Anthony Alford: You’ll find out.

Roland Meertens: Yes, like, “Oh, I don’t know, like windows are maybe transparent or something”. We noticed at some point that a neural network, we trained to recognize cars. It really knew that something was a car because of the reflective number plates.

But if you ask me what’s the most defining feature of a car, I would be like, “I don’t know, like it has a hood, has four wheels”. Nobody ever says reflective number plates.

Anthony Alford: Interesting.

Roland Meertens: Yes. Shows again that you never know what you really want to simulate accurately.

I guess that’s it for our episode. Thank you very much for listening to Generally AI, an InfoQ podcast. Like and subscribe to it, share it with your family, share it with your friends.

Anything to add to that, Anthony?

Anthony Alford: No, this was a fun one. I really enjoyed this one.

Roland Meertens: All right.

Anthony Alford: I enjoy all of them, but this one was especially enjoyable.

Roland Meertens: Cool. And my apologies to America for comparing you to Grand Theft Auto. And my apologies to Sri Lanka for saying that 10% of drivers are reckless.

Anthony Alford: Grand Theft Auto Colombo.

Roland Meertens: Yes. Well, I guess you could easily say-

Anthony Alford: Show title.

Roland Meertens: Show title. Cool. I think that’s it for today.

Anthony Alford: Oh, too funny.

Roland Meertens: It is too funny.

Mentioned:

Transcript

Roland Meertens: Anthony, did you ever have to program a turtle robot when you were learning to program?

Anthony Alford: I’ve never programmed a turtle robot, no.

Roland Meertens: Okay, so I had to do this when I was learning Java and in robotics, the concept of a TurtleBot is often that you have some kind of robot you can move across the screen and it has some kind of pen, so it has some trace. So you can start programming, go upward or go forward by one meter, then turn right by 90 degrees, go forward by one meter, turn right by 90 degrees, so that way you trace a pen over a virtual canvas.

Anthony Alford: The Logo language was based on that, right?

Roland Meertens: Yes, indeed. So the history is that the computer scientist Seymour Papert, who created a programming language Logo in 1967, apparently they use this programming language, so these are things I don’t know, to direct like a big robot with a pen in the middle, which would let you make drawings on actual paper.

Anthony Alford: Okay.

Roland Meertens: It’s pretty cool, right?

Anthony Alford: It’s a bit of a plotter, a printer.

Roland Meertens: So apparently in 1967 people learned to program with a physical moving plotter. They immediately start with a robot-

Anthony Alford: That’s pretty cool.

Roland Meertens: Yes, instead of using a virtual canvas. It was round and crawled like a turtle. But the other thing I found is that turtle robots, their first mention is in the 1940s they were invented by Grey Walter and he was using analog circuits as brains, and his more advanced model could already go back to a docking station when the battery became empty.

Anthony Alford: That’s pretty cool. In the ’40s.

Roland Meertens: In the 1940s. Yes. I will put the video in the show notes and I will also put two articles in the show notes. One is the History of Turtle Robots. Someone wrote an article about it for Weekly Robotics and another article on the history of turtle robots as programming paradigms.

Anthony Alford: Very cool.

Roland Meertens: Yes.

Anthony Alford: Slow and steady.

Roland Meertens: Yes, slow and steady and is a great way to get started with programming.

At the Library [02:15]

Roland Meertens: All right, welcome to Generally AI, Season 2, Episode 4, and in this InfoQ Podcast, I, Roland Meertens, will be discussing coordinate systems with Anthony Alford.

Anthony Alford: How’s it going, Roland?

Roland Meertens: Doing well. Do you want to get started with your coordinate system research?

Anthony Alford: Let’s go for it. So I decided to go with an AI theme of coordinates and perhaps you can guess where I’m going. We’ll see.

Roland Meertens: Tell me more.

Anthony Alford: Well, in the olden days, a teacher, for example, in a history class would often ask me and other students to write a paper about some topic. So let’s say the topic is the Great Pyramid of Egypt. Now probably most students don’t know everything about the Great Pyramid and the teacher says anyway, “You have to cite sources”, so you can’t just write anything you want.

Roland Meertens: I always hate this part. Yes, I always say, “I found this on the internet. These people can’t lie”.

Anthony Alford: Well, I’m talking about the days before the internet. But in the 20th century, let’s say, we would go to the library, an actual physical building, and there would be a big drawer full of small cards, the card catalog. These are in alphabetical order, and so we’d scroll through till we get to the Ps and then P-Y, pyramid. Great. Pyramid of Egypt, right?

Roland Meertens: Yes.

Anthony Alford: This card has a number on it. This is the call number for books that are about the Great Pyramid of Egypt. So in the US a lot of libraries use a catalog system called the Dewey Decimal system for nonfiction books. It’s a hierarchic classification system.

Books about history and geography in general, they have a call number in the range from 900 to 999. Within that, books about ancient history are in the range of 930 to 939. Books about Ancient Egypt specifically have call numbers that begin with the number 932. And then depending on what ancient Egyptian topic, there will be further numbers after the decimal point.

Roland Meertens: And maybe a weird question, but were you allowed to go through these cards yourself or did you ask someone else like, where can I find information about Ancient Egypt?

Anthony Alford: Both methods do work. If you’re young and adventurous, perhaps you’ll go to the card catalog and start rifling through. But yes, in fact, a lot of libraries had a person whose job was to answer questions like that: the reference librarian.

Roland Meertens: Yes, because I’m too young, I never saw these cards. My librarians would already have a computer they would use to search.

Anthony Alford: Right. But the point there is that the card catalog is pretty familiar to us in—speaking of search, the card catalog is an index. And it maps those keywords like Great Pyramid of Egypt, it maps those keywords to a call number or to maybe multiple call numbers.

Actually, university libraries, in my experience in the US, they don’t use Dewey Decimal, they use a different classification, but the idea is the same. Anyway, it’s a hierarchy and it assigns a call number to each book.

So to go actually get the physical book, it’s hopefully on a shelf that’s in a cabinet. We call these stacks. That’s the lingo. So the classification hierarchy is itself mapped physically to these stacks. There will be a row of cabinets for the books that are in the 900 to 999 range and maybe one cabinet for the 930 to 939, and then maybe one shelf for 932 and so on. Now that I think of it, this structure is itself somewhat like a pyramid.

Roland Meertens: Perfect example.

Anthony Alford: Hopefully if nobody’s messed with them, the physical order of the books matches the numeric order. So you’re doing an index scan or index search if we’re thinking about it in terms of a database or information retrieval. Because that’s what this is, it’s literally information.

Roland Meertens: Yes. And it is good that it’s indexed by topic because otherwise you don’t know if you’re searching for P for pyramids or G for great pyramids or E for Egyptian great pyramids.

Anthony Alford: Right. If you’re not talking to the reference librarian, you might try all those keyword searches in the index. So now that I’ve got a couple of books, I can use that content in those books to help me produce my essay about the Great Pyramid.

Now that was the bad old days of the 20th century. Here in the 21st century, it’s like you said: you do an internet search or maybe you read Wikipedia. That’s just the first quarter of the 21st century. Now we’re into the second quarter of the 21st century, and we’re in a golden age of AI. We don’t have to even do that. We just go to ChatGPT and copy and paste the assignment from the syllabus web page as a prompt and ChatGPT writes the essay.

Roland Meertens: Quite nice, quite neat.

RAG Time [07:35]

Anthony Alford: Well, in theory. So there’s a couple of problems. First, the teacher said, “Cite your sources”, and you have to do that—in the content where maybe you quote something or a reference you need to put in there. Another thing is ChatGPT is good, but maybe it’s not always a hundred percent historically accurate.

Roland Meertens: Yes, it sometimes makes up things.

Anthony Alford: And it really only knows things that are in its training data, which is large, but maybe there’s some really good books or papers that are not on the internet that might not be in that training data. So I think you know what is the answer.

Roland Meertens: Are we going to retrieve some data before we’re processing it?

Anthony Alford: Yes, it is RAG-time. So the key technology now is retrieval augmented generation, also known as RAG, R-A-G. So the general idea, we know that if we give an LLM some text, like the content of a history book, LLMs are quite good at answering questions or creating summaries of that content that you include with your prompt.

Now ignore the problem of limited context length, which is a problem. The other problem is: how do you know what content to provide it?

Roland Meertens: Yes, you can’t give it the entire stack of books.

Anthony Alford: Exactly. And even if you had the content electronically, and you had picked it out, you want to automate this, right? You don’t want to have to go hunt down the content to give to the LLM.

So finding the right history book, the right content in an electronic database of content, well, we already said it. This is information retrieval. And again, in the old days we’d use natural intelligence: we would use the reference librarian or go look up some keywords in the card catalog.

Roland Meertens: It is too bad that the librarian is not very scalable.

Anthony Alford: Exactly right. We want to automate this and scale it. So let’s take an analogy. The key idea of RAG is: take your LLM prompt and automatically assign it a call number. So now you can go directly from your prompt—your instructions for writing the essay—now we have automatically assigned it a call number, and now you just go get those books automatically and add that with your prompt.

Roland Meertens: Sounds pretty good.

Anthony Alford: Yes, more precisely: we have an encoder that can map an arbitrary blob of text into a point in some vector space with the requirement that points that are near each other in this space represent texts that have similar meanings. So typically we call this an embedding.

So we take an encoder, we apply the encoder to the prompt that turns that into a vector. Then we have all of our books in the universe, we have encoders applied to them, and we get vectors for them. We find the vectors that are close to the vector for our prompt. So easy-peasy, right?

Roland Meertens: Easy-peasy.

Anthony Alford: Right. Well, here’s the problem. So the encoder-

Roland Meertens: Encoding your data.

Anthony Alford: Well, there’s that. Well, I’m just going to assume somebody encoded all the books in the library. That’s a one-time job. The problem is that people usually use BERT as the encoder. Well, the embedding vector that you get is 768 dimensions. And so the question is: what does it mean to be nearby something in a 768-dimensional space?

Roland Meertens: Yes, that depends on what distance function you want to use.

Anthony Alford: That’s exactly right. With call numbers, it was easy because they’re scalars. So the distance function is: subtract.

Roland Meertens: Oh, it’s quite interesting. I never even realized that call numbers could be subtracted.

Anthony Alford: Well, that’s how you do it, right? If you go to find your book 932.35, you probably don’t do a scan. You probably do some kind of bisecting search, or you know you need to go over to the 900s, and then you jump to the middle of the 900s and scan back and forth depending on the number that you’re at.

Roland Meertens: And also for the library, it of course makes sense that they put books which are similar close together.

Anthony Alford: Yes, well, you physically store them in order of their call number.

Roland Meertens: Yes.

Cosine Similarity [12:04]

Anthony Alford: More or less. Anyway, like you said, this distance, the closer they are to zero, like the closer the two call numbers are together, physically the books are closer together.

So anyway, we need a distance function, or the opposite of a distance function, which is a similarity, right? The smaller the distance, the more similar. In the case of these embeddings, people typically use a similarity measure called cosine similarity. Now, if you’ve ever worked with vectors, you probably remember the inner product or sometimes called the dot product.

To explain this without a whiteboard, let’s say we’re in 3D space. So each vector has X, Y, and Z. The dot product of two vectors is you take the X from the first one, multiply by the X from the second one. Then you do that for the two Y components, and then the two Z components, you add those all up. That’s the dot product. And that’s a single number, a scalar.

Roland Meertens: Yes.

Anthony Alford: The geometric interpretation of the dot product is: it’s the length of the first one times the length of the second, and then times the cosine of the angle between them. So you could divide the dot product by the length of the two vectors, and what you’re left with is the cosine of the angle. And if they’re pointing in the same direction, that means the angle is zero and the cosine is 1. If they point in the opposite directions, the cosine is -1. And in between there, if it’s zero, they’re at right angles.

Roland Meertens: Yes, intuitively, you always think that it doesn’t really matter what the magnitude of the interest is, as long as the interests are at least in the same direction, it is probably fine in your library.

Anthony Alford: Yes, and I’m going to explain why. Anyway, the cosine similarity is a number between -1 and +1. And the closer that is to +1, the nearer the two embeddings are for our purposes. And you may wonder why cosine similarity. So again, with 3D space, X, Y, and Z, there’s a distance called the Euclidean distance, which is our normal “The distance between two points is a straight line”, right?

Roland Meertens: Yes.

Anthony Alford: So you basically take the X is the square of the Y is the square of the Zs, add them up and take the square root.

Roland Meertens: As long as we are in a Euclidean space, that’s the case.

Anthony Alford: And in vector terms, that’s just the magnitude of the vector drawn between those two points. Well, if you wonder why you don’t use that, why instead you use cosine similarity, if you look on Wikipedia, it’s something called the curse of dimensionality.

Basically, when you have these really high-dimensional spaces, and if the points are uniformly spread around there, they actually aren’t. The middle of the space and the corners of the space are empty-ish. And most of the points are actually concentrated near the surface of a sphere in the space.

So when all the points are on a sphere, their magnitudes are more or less all the same. And so you don’t care about them. And so the thing that makes them different points is there are different angles. They are at different angles relative to some reference. So that means we don’t care about the magnitude of vectors in the space, we care about the direction, and that’s why cosine similarity.

Roland Meertens: Is there any reason that the magnitude of the vectors tends to be the same?

Anthony Alford: It’s just the way that these sparse high-dimensional spaces…it’s just the math that they work out. And in fact, because the magnitudes are all more or less the same or at least very…you can take a shortcut, you can just use the dot product. You don’t have to get the cosine similarity, you can just do the dot product That’s a nice shortcut because GPUs are very good at calculating dot products.

And so let’s back up, right? We take our prompt, we encode it, we’ve already encoded the content of all the library. We just find the vectors in the library that have the largest dot product with our prompt vector. And in the original RAG paper they did that. It’s called maximum inner product search. So basically you take your queries vector, you do the dot product with the vector of all the documents and take the ones that have the biggest.

What’s the problem now? I bet you know.

Roland Meertens: What is the problem?

Anthony Alford: Well, the problem is you have to—basically every time you have a new prompt, you have to go and calculate the dot product against every other document.

Roland Meertens: If only there was a better way to store your data.

Who Is My Neighbor? [16:50]

Anthony Alford: Well, there’s a better way to search it turns out. The default way is linear complexity. So for a small library, it may be no big deal, but if we’re talking about every book ever written, well, if you compare it with index search in a database, that’s complexity around log(n). So linear is way worse. It’s terrible. So again, it turns out this is a well studied problem and it’s called nearest neighbor search.

Roland Meertens: Approximate nearest neighbors or exact nearest neighbors?

Anthony Alford: Well, one is a subset of the other. So if you go back to the database search, that’s log(n), and you can actually use a tree structure for nearest neighbor search. You can use something called a space partitioning tree and use a branch and bound algorithm. And with this strategy, you’re not guaranteed log(n), but the average complexity is log(n). But this usually is better in a lower dimensional space.

Roland Meertens: Okay, so why is it on average? Do you keep searching or-

Anthony Alford: Well, I think it is just like you’re not guaranteed, but based on the statistics, you can mathematically show that on average you get a log(n) complexity. But remember your favorite algorithm-

Roland Meertens: My favorite algorithm.

Anthony Alford: What was your favorite algorithm?

Roland Meertens: HyperLogLog.

Anthony Alford: Right. So, you already said it, approximate nearest neighbor. When you want to do things at scale, you approximate. So it turns out that a lot of RAG applications use an approximate nearest neighbor search or ANN, which also stands for “artificial neural network”. But just a coincidence.

So there are several algorithms for ANN and they have different trade-offs between speed and quality and memory usage. Now, quality here is some kind of metric like recall. So with information retrieval, you want to get a high recall, which means that of all the relevant results that exist, your query gives you a high percentage of those.

One of the popular algorithms lately for ANN is called hierarchical navigable small world, or HNSW. HNSW is a graph-based approach that’s used in a lot of vector databases. I actually wrote an InfoQ news piece about Spotify’s ANN library, which uses HNSW.

Roland Meertens: Oh, is it Voyager?

Anthony Alford: That’s correct, yes. You must have read it.

Roland Meertens: Oh, I tried it. It’s pretty cool.

Anthony Alford: Oh, okay. Well, you know all about this stuff.

Roland Meertens: Oh, I love vector searching.

Anthony Alford: So I found a nice tutorial about HNSW, which we’ll put in the show notes, and it expressed a very nice definition, concise:

Small world, referring to a unique graph with low average shortest path length, and a high clustering coefficient navigable, referring to the search complexity of the sub graphs which achieve logarithmic scaling, using a decentralized greedy search algorithm and hierarchical, referring to stacked sub graphs of exponentially decaying density.

So all of this to find out: who is my neighbor?

Roland Meertens: Who is your neighbor, and in which space are they your neighbor?

Anthony Alford: Yes. So I think I’ve filled up my context window for today. And for homework, I will let our listeners work out analogies between this topic and library stacks and pyramids.

Roland Meertens: For library stacks, I’m just hearing that they could have multiple boxes with the stacks and you just move from box to box, from room to room.

Anthony Alford: So here’s a very interesting thing. Here in my hometown, there’s a university, North Carolina State University, their engineering library has a robot that will go and get books out of the stacks. It’s basically an XYZ robot, and it’ll move around and get books out of the stacks for you.

Roland Meertens: Oh, nice. That’s pretty cool.

Anthony Alford: Yes, it looks really cool.

Roland Meertens: Always adding an extra dimension, then you can represent way more knowledge.

Anthony Alford: So that’s my fun fact.

Roland Meertens: That’s a pretty good fun fact.

Real World Coordinate Systems [22:02]

Roland Meertens: All right. For my fun fact for today, as the topic is coordinate systems, for software there’s many ways to represent a map in location software. So this can be important for your user data, maybe for helping with people and finding where they are, finding interesting locations close by, and the most popular format here is WGS84.

But what I wanted to dive into is the history of coordinate systems, especially how different countries chose them, and some of the legacy systems which are still in place because the history of coordinate systems, and of course longer than just computers, people wanted to know who owned what land for quite a long time, people wanted to know how to get somewhere for quite a long time.

And, first of all, there’s different ways to project a map. So you want to have a map in 2D, and our Earth is a sphere. In that way, you can project a sphere onto a cylinder, a cone, or just a flat disc on top of the sphere, and you always get some kind of compromise.

So you can choose to keep the angles of the map accurate. That’s, for example, the Mercator projection used by Google Maps. So if you’re going on Google Maps, you’re zooming out, then all the angles are preserved, but the sizes are not very true.

One fun question, by the way, maybe you can help me out with this, Anthony, is that I always ask what is bigger, Greenland or Australia, and by how much?

Anthony Alford: Oh, Australia is quite large. And again, I think the Mercator projection distorts our view of Greenland for those of us who are familiar with it. Australia is much larger, but I couldn’t tell you like by a factor or whatever.

Roland Meertens: Yes, I like to ask this to people because first I ask them what they would estimate and then I show them the Google Maps projection and I ask them if they want to change their guess. And sometimes people change it in the wrong direction, even though they know that Mercator doesn’t preserve size, even though they know that the map is lying. They just can’t get around the fact that Greenland looks really big on the map.

So if you want to fix this, you can use the Mollweide equal-area projection to ensure that all the map areas have the same proportional relationships to areas on the Earth. And the other thing you can do is if you want, for example, to keep the distance constant, there are equidistant projections that have a correct distance from the center of the map.

So this is useful for navigation, for example, if you want to have something centered around the UK that you at least know if I want to go here, it’s equally far as if I want to go here. And here, another fun fact for you is that azimuthal equidistant projection is the one they use for the emblem of the United Nations: this emblem where you see this map from the North Pole, that is an azimuthal equidistant projection where the distance is constant.

Anthony Alford: Okay, nice.

UK Ordnance Survey Maps [25:27]

Roland Meertens: But as I said, I wanted to talk a bit about other systems in the world and which projection they pick and perhaps some of the technical depth and incredibly smart choices they made when doing so.

And, first off, in the UK they have the Ordnance Survey Maps. It’s basically the national mapping agency for Great Britain. And in a previous episode of Generally AI, I already told you about multiple telescopes in the observatory in Greenwich, right?

Anthony Alford: Right. Yes.

Roland Meertens: And I think I also told you that they have multiple telescopes which all have a different prime meridian line, which indicates zero or used to indicate zero. I discovered that the Ordnance Survey meridian was picked in 1801, which is 50 years before this newer prime meridian was released. And nowadays with GPS, the prime meridian moved again. But the Ordnance Survey Maps are basically two prime meridian switches away from what it used to be.

Anthony Alford: I don’t know, but I’m guessing from the name that they would, in the worst case scenario, use these maps to choose targets for artillery. So hopefully they don’t miss.

Roland Meertens: No, actually what I think is probably a good reason to keep the Ordnance Survey Maps the same is that they probably use it to determine whose land belongs to whom.

Anthony Alford: Sure.

Roland Meertens: So you want to be able to keep measuring in the old way as you already determined who owns what land.

Anthony Alford: Makes sense.

Roland Meertens: Otherwise, but we will see this later in this episode, you start publishing error maps like the Netherlands is doing. But it’s interesting that since 1801, when they picked this survey meridian, they were for a long time simply six meters to the east of what people started to call zero for a long time.

I can also imagine that this is still confusing nowadays if people use their own GPS device and compare it to some older document from the 1800s and discover that their place is very much farther away from where they thought it should be. But I’ll post an article to this Ordnance Survey Zero Meridian in show notes.

Netherlands Triangle Coordinate System [27:49]

Roland Meertens: Anyway, moving to a different country, in the Netherlands, the geographic information system, the GIS system, is called Rijksdriehoekscoördinaten. So it’s a “national triangle coordinate system”. And as you can already guess, this mapping is accurate in angles and Wikipedia says it approaches being accurate in the distances, so it’s not accurate in distances.

Anthony Alford: Oh, I see. And so I guess it’s basically you need to orient in the right direction, but the distance is approximate? Is that-

Roland Meertens: Well, the thing is that if you have these coordinates, the angles between your coordinates are the same as the angles in the real world.

Anthony Alford: Cosine distance!

Roland Meertens: Yes. So the coordinates are in kilometers and then meters, right? It’s just that one kilometer in coordinates isn’t a kilometer in the real world. So one kilometer on the map in coordinates isn’t necessarily one kilometer in the real world. So the center of the map is a church in Amersfoort, so basically in the center of the Netherlands. Around there, the scale is 10 centimeters per kilometer too small.

Anthony Alford: Interesting.

Roland Meertens: Yes, I mean, it’s not a big error, it’s just only 10 centimeters.

Anthony Alford: This reminds me again of the last season where the king found out that his land was smaller than the map said it was.

Roland Meertens: Yes. So if you would take the Dutch triangle coordinate system and then determine that you’re going to walk 10 kilometers in the center of the Netherlands, you would have walked one meter too little after walking 10 kilometers.

Anthony Alford: Would you even notice though, right?

Roland Meertens: Indeed, you probably wouldn’t. On the edges, so if you go towards the coast areas into Germany, it’s 18 centimeters per kilometer too large.

Anthony Alford: So you could wind up in Germany and not know it…or would you know it? You might know.

Roland Meertens: You will find out that you’re crossing the border because it says you’re crossing a border.

Anthony Alford: Well, wait, Schengen, you guys are all…you just walk, right?

Roland Meertens: Yes, from where my parents live, you can very easily cycle to Germany. But it’s interesting that because you have such a small country, you can project things in a flat way and-

Anthony Alford: And the country is rather flat as well, I believe.

Roland Meertens: The country is rather flat as well. Yes, indeed. I will get to the height of the Netherlands actually, because that’s also interesting because they use different landmarks than the landmarks used for the triangle coordinate system.

Anthony Alford: Okay.

Roland Meertens: So as I said for the triangle coordinate system, the center of the coordinate system, let me tell you a fun fact about that first. So that’s a church in Amersfoort. And if you look at the coordinates, there’s an X and Y component where X goes from west to east and Y goes from south through north. That’s relatively simple.

But the X coordinates are between zero and 280 kilometers. The Y coordinates in the Netherlands are between 300 and 625. So (0,0) is basically somewhere to the north of Paris. And the nice trick here, which I think is just genius, is that all the coordinates in the Netherlands are positive and the Y coordinates in the Netherlands are always larger than the X coordinates-

Anthony Alford: Interesting.

Roland Meertens: … unlike continental Netherlands. So this removes all the possible confusion around what coordinate. So if I give you two coordinates, I don’t even have to tell you this is X, this is Y.

Anthony Alford: Got it.

Roland Meertens: I can turn them around, I can flip them around. Because as a software engineer, whenever it says coordinates, you get two numbers. I always plot latitude, longitude, trying out combinations to make sure that everything is correct. And here in the Netherlands, if only people would use the national triangle coordinate system, there would be no confusion in your software.

Anthony Alford: Is that a thing that most Netherlanders are aware of?

Roland Meertens: Probably not. I must also say that this coordinate system is not used a lot. Probably mostly for people who are doing navigation challenges or scouting or something.

Although I must say that it is quite nice to take one of those maps because they are divided in a very nice way. It’s very clear how far everything is because with latitude and longitudes, the distance between one latitude or one longitude is different depending on where you are on Earth, right?

Anthony Alford: Yes. But there’s a conversion to nautical miles, but I can’t remember it off the top of my head.

Roland Meertens: That’s a good point. I wanted to say in the Netherlands it’s fixed, but we just learned that it’s 10 centimeters per kilometer too small in the center and 18 centimeters per kilometer too large in the edges.

Anthony Alford: But originally part of the development of the metric system was to take the circumference of the Earth and make fractions of it to be the meter originally. I don’t think it worked out.

Roland Meertens: I think there’s also a map system where they try to keep the patches the same area, but then you get problems when you want to move from patch to patch. So if you have coordinates or if you have a route which crosses multiple patches, one point on one patch doesn’t necessarily map to the same place on another patch.

Anthony Alford: It’s a tough problem.

Roland Meertens: Yes, and that’s why I like to talk about it. It’s a lot of technical depth and it becomes more difficult once you start doing things with software or self-driving cars or things like that.

In terms of technical depth, the original map of the Netherlands was made between 1896 and 1926. And as you can imagine, we now have way more accurate mapping tools, but I already alluded to the fact that if you already mapped out a place and you say this is your property, you can’t really say, oh, there’s a new coordinate system, let’s go measure everything again and assign this again.

So what they do in the Netherlands, I think on three different occasions they published a correction grid with corrections up to 25 centimeters. So you can take an original coordinate and then apply the correction grids to get the coordinates in what is actually measured.

Anthony Alford: Gotcha. Well, not to derail your talk, but here, again, in North Carolina we have a border with another state, South Carolina, and about 10 years ago they had to adjust it. Basically the border had become ambiguous. It was unclear where it actually was. And so they fixed it and agreed on where the border is. And there were some people who woke up one morning in a different state without having to move.

Roland Meertens: I can tell you one other fun fact about borders in the Netherlands and between Germany and that is that in the Netherlands after World War II, there were some proposals around like, can we maybe have some part of Germany to make up for the Second World War?

So they got a few parts of Germany, but those are super small regions like a village or something. And this wasn’t really working out, taking a long time to move people, make sure everything was working well, build schools, et cetera.

So at some point they gave it back, but then weeks before they were giving back this country, big trucks would already start moving in with loads of goods in them. They would find places in the village to park and hours before this transition happened, big trucks would show up with loads of butter inside. So basically at 12 o’clock at night, the country swaps and these goods never crossed a border, so they didn’t have to pay taxes.

Anthony Alford: Loophole.

Roland Meertens: Yes. So they found a loophole which you could only do one night because some parts changed country overnight.

Anthony Alford: Interesting.

Roland Meertens: One last fun fact here about coordinate systems. You already said the Netherlands is quite flat. Good point. But this grid only tells you XY coordinates and it’s mostly based on locations of church towers to measure angles between. So it’s quite neat. Those are relatively consistent places and you can see between them.

There’s a separate mapping for height above sea level, the new Amsterdam Ordnance Datum, and this is actually used in a lot of Western European countries. And these points are indicated by screws on specific buildings. And I know this because once in high school we had to make an accurate map of a field close to a school and I was tasked to propagate the height from this screw to the rest of the field.

Anthony Alford: Wow.

Roland Meertens: We actually had these systems they use in professional area measuring setups.

Anthony Alford: The surveying tools…a transit.

Roland Meertens: There was something where something was perfectly flat and then we would stand somewhere with a height meter, measure the difference in height, place the measuring device somewhere else, have the person with the height meter stand somewhere else.

We also had to do it twice because the first time we made a mistake, I don’t know anymore what we did, but it’s just teenagers trying to come up with a way to measure a field.

Anthony Alford: Very cool.

Words of Wisdom [37:40]

Roland Meertens: All right. Words of wisdom. Did you learn anything in this podcast or did you learn anything yourself recently?

Anthony Alford: The fact that all the points in a high dimensional space are on a sphere was new to me. Maybe not all, but the fact that they all more or less have similar magnitude. That was an interesting fact that I was not aware of.

Roland Meertens: You would say that that means that there is space in the high dimensional space left over. The place in the middle and the corners could be utilized to store more information.

Anthony Alford: One would think, but then that would mess up the assumption of the cosine distance.

Roland Meertens: Yes, but more space to store. It’s free. It’s free storage.

Anthony Alford: Just add another dimension.

Roland Meertens: Yes, that’s why I always throw all my stuff on the floor in my room. I pay for it, I can store it wherever I want, everywhere in the space.

Anthony Alford: Definitely.

Roland Meertens: One thing from my side in terms of learning things, one recommendation I want to give you is, have you heard of the post office scandal in the UK?

Anthony Alford: No. Tell me.

Roland Meertens: It’s quite interesting. So the post office in the UK adopted a bookkeeping system by Fujitsu called Horizon, and it was basically plagued with bugs. Sometimes the system would duplicate transactions, sometimes it would change some balance when users would press enter at some frozen screen multiple times. So you’re like, oh, it’s frozen…let’s press enter.

Every time something would happen with your balance.

And it was possible to remotely log into the system. So Fujitsu or Horizon could remotely change the balances on these systems without the postmasters knowing. And I learned last week that rather than acknowledging these bugs, these postmasters were sued for the shortfalls in the system because the system would say, you owe us £30,000.

Anthony Alford: Oh, wow.

Roland Meertens: Yes. And so these postmasters were prosecuted, got criminal convictions, and this is still going on and still not fully resolved today.

Anthony Alford: That’s terrible.

Roland Meertens: It is absolutely insane. So I watched this drama series called Mr. Bates versus The Post Office, and I can definitely recommend you to watch this because it tells you a lot about impact your software can have on individuals and to what great length companies are willing to go to hide the impact of bugs or systems like this.

Anthony Alford: Goodness gracious.

Roland Meertens: Yes, it’s insane. We can do a whole episode about the post office scandal I think.

Anthony Alford: That would be depressing.

Roland Meertens: Yes, but I must say it’s very interesting. Every time when you read about this and you think, surely by now they will acknowledge that there can be problems like this, the post office just doubled down, hired more lawyers, created bigger lawsuits, and absolutely ruined the lives of people who were postmasters in the last 20 years actually.

Anthony Alford: Wow.

Roland Meertens: As I said, can recommend this as a thing to watch.

Anthony Alford: Sounds good.

Roland Meertens: Anyways, talking about recommendations. If you enjoyed this podcast, please like it, please tell your friends about it. If you want to learn more things about technology, go to InfoQ.com. Take a look at our other podcasts, take a look at our art course and the conference talks we recorded. Thank you very much for listening and thank you very much, Anthony, for joining me again.

Anthony Alford: Fun time as always.

Roland Meertens: Fun time as always. Thank you very much.

Anthony Alford: So long.

Roland Meertens: Any last fun facts you want to share?

Anthony Alford: Well, I don’t know if we want to put this one on the air, but I was looking at how property is described here in the US in a legal document. So you may know, you may not, that we have a system called Township and Range, and I think it was invented by our President Thomas Jefferson.

After our Revolution, we had all this land that legally speaking was not owned by anyone. So they divided it up into a grid. They laid a grid out over it. So here’s a description of a piece of property:

Township four north, range 12 west. The south half of the north half of the west half of the northeast quarter of the northeast quarter of the north half of the south half of section six.

Roland Meertens: Okay. Yes. So they made a grid and then they went really, really, really, really deep.

Anthony Alford: Subdividing the grid. Yep.

Roland Meertens: Yes, I do like that. When people started mapping this, they were probably like, ah, there’s so much land. It doesn’t really matter how accurate this is. Probably North US, South US is probably enough.

Anthony Alford: Well, what’s interesting, a surveyor was sort of a high status job in the colonial days. George Washington was a surveyor, and Thomas Jefferson amused himself by designing buildings. So these guys took it pretty seriously. That was the age of the Enlightenment and Renaissance men and all that.

Roland Meertens: But if you are not good at mapping, you don’t come home on your ship.

Anthony Alford: Yes, exactly.

Roland Meertens: And if there’s no maps of roads or you don’t know where you are, you don’t reach the village you wanted to get to.

Anthony Alford: Exactly.

Roland Meertens: Yes. Interesting.

Mentioned:

Introduction [00:18]

Michael Stiefel: Welcome to the What Have I Done Podcast, where we ask ourselves do we really want the technology future that we seem to be heading for? This podcast was inspired by that iconic moment at the end of the movie, The Bridge on the River Kwai, where the British Commander, Colonel Nicholson, realizes that his obsession with building a technologically superior bridge has aided the enemy and asked himself, “What have I done,” right before he dies, falling the detonator that blows up the bridge.

For our first episode, I wanted to discuss the impact of large language models on software development. I have two guests, well known in the world of InfoQ, Anthony Alford and Roland Meertens. Both host the “Generally AI” Podcast for InfoQ.

Anthony is a director of development at Genesys, where he’s working on several AI and NL projects related to customer experience. He has over 20 years of experience in designing and building scalable software. Anthony holds a PhD degree in electrical engineering with specialization in intelligent robotic software, and has worked on various problems in the areas of human AI interaction and predictive analytics for SaaS business optimization.

Roland is tech lead at Wayve, a company which is building embodied AI for self-driving cars. Besides robotics, he has worked on the safety for dating apps, transforming the exciting world of human love into the computer readable data. I can’t until that and LLMs get together. He also bakes a pretty good pizza.

Welcome, both of you, to the podcast.

Anthony Alford: Thanks for having us.

Roland Meertens: Yes, thank you very much.

The Software Development Lifeycle of the Future [02:05]

Michael Stiefel: I would like to start out with the assumption that we live at some future time, not probably too far in the future, when the problems of using LLMs for writing code have largely been ironed out. The first question to ask both of you is what does the software development life cycle look like in this world?

Roland Meertens: Well, what I assume is that bots will automatically find issues within software, they can automatically raise a PR, and then other bots automatically accept the improvements. Basically, none of the code is readable anymore, which is not that much different than today.

Anthony Alford: That’s a very cynical take. But then you’ve worked with robots a lot. I start out with my general principle here is, probably what will actually happen is going to be surprising to a lot of people. I’m going to go with the safe bets and I’m going to go with the concept of what robots are for. They’re for automating the tasks that people find dangerous, dirty and dull. I’ve never really experienced a lot of danger or dirt in my software development career, but there’s a lot of dullness. I’m going to go with the idea that the automation, the LLMs, are going to take care of the dull stuff. Like Roland said, that’s definitely pull requests, code reviews for sure. But also things like writing tests, writing documentation. Things that we find hard, like naming variables.

The idea is to free up the time for the human engineers to focus on the important things, like do we use spaces or tabs?

Michael Stiefel: In other words, coding standards.

Roland Meertens: Those are things we should have, ideally, already automated, like those decisions you should give to an intern normally. I think that’s at least already something which you give away.

Who of you two is using GitHub Copilot at the moment?

Anthony Alford: I’ve used it for fun side projects. It’s not bad.

Roland Meertens: But you’re not using it for your day-to-day work?

Legal or Regulatory Issues [04:24]

Anthony Alford: That’s an interesting … One of the premises of this episode is that all of the problems have been ironed out. One of the problems for us, professionally at our company, is we don’t want to send data out into the potential training dataset. There’s also concerns about the code that you get back. Who owns the copyright to that code, for example? No, we’re not using Copilot at work.

Roland Meertens: But it’s because of legal trouble and not because of technical capabilities?

Anthony Alford: More or less, yes.

Teaching Future Developers [04:57]

Michael Stiefel: Well, both of you have hit on the idea that we’re going to use this technology to do all the dull stuff and the easy stuff. Isn’t that traditionally where novice programmers get trained? So the question then becomes, if we’ve automated all the easy stuff, how are we going to train programmers? What is the programming class of the future going to look like?

Anthony Alford: The Copilot is actually, I think, a pretty useful paradigm, if we want to use that word.

Michael Stiefel: Do you want to explain to some of the listeners what the Copilot is? Because they may or may not know what it is.

Anthony Alford: Yes, it can mean a couple things. The capital letter Copilot is a product from GitHub that is a code generating LLM. You type a comment that says, “This function does,” whatever you want the function to do and it will spit out the entire code for the function, maybe.

Michael Stiefel: In whichever language you tell it to.

Anthony Alford: Right, exactly. Copilot could also mean an LLM that’s assisting you and I think that might be a nice model for training novices. Maybe more it’s a real time code reviewer, a real time debugging assistant might even be better.

The other way to look at it is maybe the LLMs save your senior programmers so much time that they’ll have nothing else to do but mentor the younger ones. I don’t know.

Michael Stiefel: Well this is, I think what you’re hitting on, is one of the I’ve always found the paradoxes of programming technology in general. It’s that unlike other engineering … For example, if you’re a civil engineer, you can spend your entire life building the same bridge over and over again.

Anthony Alford: It’s the Big Dig.

Michael Stiefel: Well, yes. For those of you who don’t live in Boston, that was a very interesting civil engineering experience for many years, paid for with taxpayer money from throughout the United States. But in any case, there were very few projects like that in the engineering world. You do something that has never been done before.

When I was a graduate student, I took nuclear engineering. On one of the final exams of reactor design was we were supposed to design the cooling system for a nuclear reactor. Not from physics first principles, but taking the ASME standard and applying that to the design. Software’s very different. In software, if you want another copy of something, we just copy the bits. We tend, in software, always to do new things that we haven’t done before because otherwise, why write a software program?

The question is how do you take a LLM, or any technology that is trained on the past, and apply it to the future that we don’t necessarily know what it is?

Roland Meertens: But aren’t you also frequently doing the same thing, over and over again?

Michael Stiefel: Yes.

Roland Meertens: As humankind.

Michael Stiefel: Yes.

Roland Meertens: That’s why Stack Overflow is so popular because everyone seems to be solving the same problems every day.

Michael Stiefel: Yes. But the question is … Let’s say, for example, I go back to the days, well I don’t want to say exactly how old I am, but I remember card readers and even before virtual memory. Yes, there were repetitive things, but people forget things like compilers, linkers, loaders, debuggers. These were all invented at some point in time and they were new technologies that required insight. Firewalls, load balancers. How does a LLM take all these things into consideration if it’s never seen them before?

Roland Meertens: Yes. But also, I think that we started this discussion with how do you learn if you don’t know about the past? In this case, I’m the youngest being only 33-years-old and I unfortunately missed out on the days of punch card programming.

Michael Stiefel: You didn’t miss much.

Roland Meertens: That’s just what I’m asking is how often do you, in your daily work think, “Oh yes, I remember this from punch card days. This is exactly what I need.”

Michael Stiefel: But the point is who would have thought of a compiler? In other words, a LLM is not going to come up with something new. Is it going to look at data and say, “Ha, if we could do this, it would be great, and this is how we’re going to do something that I’ve never seen before?”

What Will Programmers Actually Understand [09:39]

Roland Meertens: I’m mostly wondering what this means for future senior developers. These are the people who are beginning with programming today. I think the question is are they going to learn faster because they can focus on code 100% of the time, instead of having to go through many obscure online fora to find the API code they need? Or are they not going to build a thorough understanding of code and what the machine actually does, because they just ask ChatGPT to generate everything they do?

Anthony Alford: Yes. I was going to say yes it’s true that sometimes software developers have to solve a problem that has not come up before, but really I think a more common use case is it’s like you were talking about with ASME standards, you’re basically putting together pieces that you’ve already seen before. Maybe in a novel way, but quite often not really. “I need to make a rest API. I need something that stores …” This is how these frameworks, like Rails and Django work. They know that there’s common patterns that you’re going to go to. I think that the LLM is just the next iteration of that.

Uses of Large Language Models

LLMs Embody Software Patterns of the Future [10:56]

Michael Stiefel: So it’s the next iteration, design patterns, architecture patterns, enterprise integration patterns.

LLMs as The DevOp First Responder [11:02]

Anthony Alford: Probably. The other thing is, like I said, the code itself is not the entire job. There’s a lot of other stuff. Let’s take the devops model. In my company, the software engineers who write code are on call for that code in production. What if we could make an LLM be the first responder to the pager and have it either automate a remedy or filter out noise? Or pass it along when it’s stuck. LLMs could do other things like helping you design your APIs, helping you generate test cases, maybe even debug or optimize your code.

How Understandable Will LLM Written Code Be? [11:46]

Again, I talked about automating the parts that are dull. Or maybe not necessarily dull, but maybe harder. I don’t think we’re going to see LLMs writing all the code. Maybe we will, but I think it’s still very important. Like Roland said, we don’t want code that’s just completely LLM generated, because then nobody will know how it works.

LLMs as Code Explainers [12:06]

Michael Stiefel: Well, I think it’s hard enough to sometimes figure out how the software we write manually works.

Anthony Alford: Exactly.

Michael Stiefel: In fact, I’ve come across code that I wrote maybe two or three years ago and look at, and say, “How does this work?”

Anthony Alford: Sure. That’s what the LLM-

Michael Stiefel: Incidentally, sometimes I try to convince myself there’s a bug, but then I realize I was right the first time. It’s just that I forgot the intricacies of what was going on.

Roland Meertens: It is worse if there’s a comment which says, “To do: fix this,” next to it.

Anthony Alford: Maybe that’s the way that LLMs can help us. The LLM can explain the code to you maybe. That would be a great start.

Michael Stiefel: Yes.

Anthony Alford: What does this code do?

Michael Stiefel: I like your idea about the pager. Having worn a pager for a small period of time in my life, anything that would prevent me from getting beeped in the middle of something else would be a great improvement.

LLMs and Refining Requirements [13:03]

We haven’t quite figured out how you’d train the new programmers yet, because I really want to come back to that. But how do you describe requirements… One of the things that’s the toughest, to do in a software development, is figure out what the requirements are. I’ve worked for myself for many, many years and I’ve said, over the years, there are only three things that I do in my life. Inserting levels of indirection, trading off space and time, and trying to figure out what my customers really want.

Anthony Alford: I actually made a note of that as well. If we could get an LLM to translate what the product managers write into something that we can actually implement, I think that would be a huge … I’ve had to do that myself. The product managers, let’s assume they know what the customers want because they’re supposed to. They know better than I do. But what they write, sometimes you have to go back and forth with them a couple of times. “What do you really mean? How can I put this in more technical terms?”

Michael Stiefel: Well, I think the point is they very often don’t understand the technology and the customers don’t. Because one of the things I find is just because you can write a simple English language statement doesn’t mean it’s easy to implement. That would be interesting. How would you see that working with the LLM? In other words, the product manager says, I don’t know, that we need something fast and responsive. How would the LLM get the program manager to explain what they really mean by that?

Roland Meertens: I think here, there’s two possible options again. On the one hand, I think that sometimes thinking about a problem when manually programming gives you some insights, and that also goes for junior developers who need to learn how to code. It’s often not the results which counts, but the process. It’s not about auto generating a guitar song, it’s about slowly learning and understanding your instrument.

LLMs Generating Prototypes [15:10]

On the other hand, if you have a product manager which asks for a specific website, if you can have ChatGPT generate you five examples, and they can pinpoint and say, “Yes, that’s what I want.” If you can auto generate mock ups or auto generate some ideas, then maybe you get it right from the first time, instead of first having to spend three sprints building the wrong product.

Michael Stiefel: A LLM, another idea is to have it be an advanced prototyping tool.

Anthony Alford: Absolutely. I think we’ve all seen that demo where somebody drew a picture on a napkin of a website.

Michael Stiefel: Yes.

Roland Meertens: Right.

Anthony Alford: And they give it to the image understander.

Michael Stiefel: Interesting. I think because there’s been a lot of attempts to do prototyping code generation, I’m sure you’ve all seen them in the past. There’s a frustration with them, but maybe large language models can … Again, how would you train such a prototype? Would you put before them samples?

Because one of the things I think with machine learning in general, they don’t understand vagueness very well. In other words, you give a machine learning algorithm something, it comes up with an answer, but it doesn’t come up with probabilities. When you’re doing prototyping, you’re combining probabilities and there’s no certainty. How do you solve that kind of problem? If you understand what I’m trying to get at.

Roland Meertens: But isn’t this the same problem as we used to have with search engines?

Michael Stiefel: Yes.

Roland Meertens: Where people would go to a search engine and they would type, “Please give me a great recipe for a cake.” Now everybody knows to type, “Chocolate cake recipe 15 minutes,” or something.

Michael Stiefel: Right, because we trained the humans that deal with the software.

Roland Meertens: Yes.

Michael Stiefel: But ideally, it really should be the software that can deal with the humans.

Roland Meertens: Yes. I think my father already stopped using search engines and is now only asking ChatGPT for answers, which I don’t know how I feel about that.

Michael Stiefel: I asked ChatGPT to come up with a bio of myself and it came up with something that was 80% true, 20% complete fabrication, but I couldn’t tell. I know because I knew my own bio, but reading it, you couldn’t tell what was true and what was false.

Roland Meertens: But are you paying for GPT-4?

Michael Stiefel: This was on GPT-3 I think I was doing this.

Roland Meertens: Yes. I noticed that on GPT-3, it also knew my name. I assumed that it knows all of our names because of InfoQ. Then it generated something which, indeed, was 80% true and 20% made me look better than I actually am.

Michael Stiefel: Yes.

Roland Meertens: I was happy with that. GPT-4 actually seems to do some retrieval.

Anthony Alford: Isn’t that a game, two truths and a lie, or something like that?

Michael Stiefel: Yes. Yes, yes, it is. But isn’t that the worry about using large language models in general?

Anthony Alford: Yes, but I would submit that we already have that problem. The developers have been writing bugs for-

Michael Stiefel: Yes.

Anthony Alford: Ever since, I guess even Ada Lovelace maybe wrote a bug, I don’t know.

Michael Stiefel: Well, supposedly the term bug came because The Grace Hopper found an insect in the hardware. But I think the saving grace, I would like to think, with software developers, unlike the general public, they could recognize when the LLM has generated something that makes no sense. It gets caught in a test cause. In other words, you could have maybe one LLM generates the test cases and another one generates the code, the way they like to have battling, sometimes, machine learning systems.

Anthony Alford: Yes, and maybe that’s the way we’ll wind up doing this is invert it. The human is the code reviewer, although I can’t imagine that would … I hope it’s not to that point. Nobody likes reading code.

Michael Stiefel: Oh, no. Yes. To do a code review, I’ve done code reviews because again, being in this business for a long time, that was a big thing. Code reviews, at some point in time, people said it was going to solve the software quality problem. To do a code review is really hard.

Anthony Alford: Yes.

Michael Stiefel: Because you have to understand the assumptions of the code, you have to spend time reading it. I would hope that the LLMs could do the code reviews.

Anthony Alford: Me, too.

Roland Meertens: Well, I mostly want to make sure that we keep things balanced, not that the product manager automatically generates the requirements, and then someone automatically generates the code. Then the reviewer, at the end, has to spot that the requirements were bad to begin with.

Michael Stiefel: Well, you see, you raise an interesting point here because when we speak of requirements right now, even when you talk about the program manager, the project manager having requirements, that’s already where the requirements are some way fleshed out. But if you’ve ever done real requirements analysis and I have, you sit down with the client and they don’t really know what they want, and you have to pull that out of them. There is an art form of asking open ended questions. Because most of, when we do requirements analysis, ask them, “Do you want A or do you want B?” But you already narrowed the field and given the person you’re asking perhaps a false choice. You have to be able to deal with open ended questions. Do you see LLMs being able to deal with open-ended questions? And then refine down, as answers come.

Anthony Alford: I really like the idea of the LLM as a rapid prototyper and even a simulator. I’ve seen projects where people have an LLM pretend to be an API, for example. I have a feeling that would be quite handy.

Michael Stiefel: In that case, you’d still be training the software developers the old way.

Let’s go with that idea, for the moment. The LLMs are the rapid prototypers. They may or may not generate reusable code. Because one thing I found with prototypes is you have to be prepared to throw the whole thing away.

Anthony Alford: Yes.

Michael Stiefel: Because you very often get in trouble when you build a prototype and then you say, “Oh, I want to salvage this code.” You have to be prepared to throw the whole thing away. So we use the LLM to come up with a rapid prototype. Then, what’s the next step?

Also, I’m thinking, when I think of the next step, how do you do the ilities? The security, the scalability. Because it’s one thing to design an algorithm, it’s another thing to design an algorithm that can scale.

Anthony Alford: Yes. Well, the security part, for example, our company, our security team is already doing a lot of automated stuff. I think that’s another great fit for an LLM. Maybe not an LLM, but automation for sure, is something that security people use a lot. Maybe LLMs are good on reading things like logs.

Michael Stiefel: Yes.

Anthony Alford: To find an intrusion, for example. Anyway, that’s the only part of that that I have an answer for. I don’t know about scalability, other than maybe helping you generate load at scale somehow. Roland, you got an idea?

Roland Meertens: No, not really. In this case, I must also say that as a human, I don’t always know how to do things except for go to InfoQ and see how other experts do things. I can only imagine that an LLM has already read all of the articles you guys wrote so they can already summarize them for me.

Michael Stiefel: Assuming I was right to begin with, in the article.

Anthony Alford: Yes.

Roland Meertens: Yes. Yes, but in that sense, that those code generation requirements I think could be a good way to brainstorm. I think that something like ChatGPT can remind you to also think about the ilities.

Michael Stiefel: What I hear being developed is that the LLMs are essentially being used as idea generators, checkers to make sure that the human has done, “Have you considered this? I’ve looked at the code.” Yes, it may generate a lot of stupid things, just looking at the code, but it will generate a checklist. “If you use this API, have you considered this? Should you use a Mutex here?” Or something like that. Is that where we’re going with this?

What Could Go Wrong? [24:20]

Roland Meertens: Well, as this podcast is about What Have I Done, I think the dystopian thing I’m not looking forward to is that I think there will be a day where someone adds me, a junior developer will add me to a pull request. I argue that I am right and their AI generated code is wrong, and then I probably learn that their ChatGPT generated code was better to begin with and their AI generated proposal is faster than my code.

Michael Stiefel: Okay, that’s humiliating for us, but that’s not necessarily a bad future. Going with that idea, what could go wrong? Let’s say we were doing a pre-mortem. You’re familiar with the idea of a pre-mortem. Something is successful and you ask yourself, “Well, what could go wrong?” What could go wrong here?

Anthony Alford: I think we’ve already touched on it. I think a big risk of having generated code like this is when something goes wrong, nobody has an idea of how to solve it.

Here’s something, I have this idea with autonomous vehicles. Some of you who are experts in that area may fact check me here. My suspicion that if all vehicles were autonomous, overall traffic accidents would go down. But the ones that happened would be just absurd. It would be stuff that no human would ever do, like on The Office, driving into the lake or something.

Michael Stiefel: Right.

Anthony Alford: I suspect something similar would happen with-

Michael Stiefel: Well, yes.

Anthony Alford: Generated code.

Michael Stiefel: Let’s take your analogy, because I think there’s something very interesting about this. Before you get to fully … I think with self-driving cars, the problem is the world getting to self-driving cars. When you have humans and self-driving cars at the same time, you have a problem. I’ll give you two examples.

One is there’s something called the Pittsburgh Left. Which, for those of us who drive the United States, you generally, if you’re at an intersection, the cars going straight have the right-of-way over the cars that are turning. But in Pittsburgh, there’s a local custom that those making the left turn have the right-of-way. The question is, you have a car that was trained on data in some other city that comes to Pittsburgh, what is that situation? Or you have the situation happen in Sweden, where they went from driving on the left side of the road to the right side of the road overnight. Humans did wonderfully. I don’t see how a self-driving car could do that.

Roland Meertens: I’m only hearing that we need to learn from situations as fast as possible, and that we need and learned driving, so you can actually capture, all in once, as in all the different areas.

Michael Stiefel: Yes. But also, I think the easy case is when everything is automated. As you say, Anthony, there is that case where it comes across something it didn’t expect, like a chicken running across the road. But if everything’s automated, then everything’s predictable because they all know what they should do. The problem is in the world where you’re half automated and you’re half not, that’s where you get into a problem. I don’t know if there’s an analogy here with, you brought up self-driving cars, an analogy with doing the LLMs to generate code and not knowing, if the LLMs are always generating the code?

Roland Meertens: Well, I still think the problem is mostly here with humans, that thinking about the code and thinking about the problem gives you insights into what you actually want to achieve. Whereas if you automate everything, at the end, you maybe have a website very quickly but why did you make this website again? Were you just happy that ChatGPT generated it? I think that’s at least one thing which I noticed when using things like ChatGPT, is that at the start, I used it quite often to help me write a message to a friend. I’m like, “I don’t want to lose the capability of writing messages to a friend.” I think we all lost the capability of remembering 10-digit phone numbers because we just stored them in our phone.

Michael Stiefel: Well, I still could do that but that’s because I got trained with that a long time ago.

Roland Meertens: Yes. The younger folks, they don’t know how to remember 10-digit numbers anymore.

Michael Stiefel: Well, it always amazes me at the checkout, when someone is at the checkout and I sometimes like to use cash instead of a credit card. I can compute the change in my head and the person at the other end is, “How’d you do that?”

Roland Meertens: Yes. Yes, maybe at some point, someone will say, “Wait, you can actually open Notepad and edit the HTML yourself.”

Michael Stiefel: Well, that’s Back to the Future.

Roland Meertens: Yes.

Anthony Alford: We’re going to turn this into “The Kids Today”.

Michael Stiefel: Actually, you raise a very interesting point there because … Let’s go back to the point, you were both talking about before about figuring out what ChatGPT has done. The question is how elegant will the code … Because if ChatGPT can be clever, you could have the equivalent of go-tos all over the place. They could produce spaghetti code and they understand it, but then if you have to, as you say, open up Notepad and look at the HTML, you’ll look at it and say, “What the hell is going on here?” Is that a danger?

Roland Meertens: Have you guys seen that DeepMind’s AlphaDev found a faster sorting algorithm?

Michael Stiefel: No.

Anthony Alford: Yes, I did see that headline.

Roland Meertens: Yes. A while ago, they trained some kind of reinforcement learning agent to generate code and their algorithm found, I think they went from, I don’t know, 33 instructions to 32 or something like that. It was a bit faster than the fastest human written code.

Michael Stiefel: But the question is in sorting algorithms, because if I go back to the good old days, we had to choose them and write them yourself. Sorting algorithms are not universally used in all cases. For example, Bubble Sort, if I remember going back to, is a very good sort except if the data is almost already in ordered state. Do I recall that right? I don’t know.

The question is, in the situation you just had where you came up with a faster sort, does the algorithm now know the cases to use this sort? Or is it just going to blindly use it every place?

Roland Meertens: Or maybe you can apply this algorithm to your specific deployment.

Michael Stiefel: Yes.

Roland Meertens: You just tell it, “Optimize my P99 latency.” Then you don’t know what’s going on, what kind AB tests is set up, but your P99 latency slowly goes down. You don’t know if that’s maybe because your AI starts rejecting customers from a certain country. I think that’s the real danger is what are you optimizing, at the end of the day?

Michael Stiefel: So what you’re saying that in this world of LLMs, we have to log a lot of stuff.

Anthony Alford: Yes. Well actually, now that I started thinking about it, if the LLM is going to be part of your software development pipeline, we’re going to want to check in the prompts into Git. You’re going to want to commit your prompts to the source code because now, that’s the source code.

Michael Stiefel: Right.

Anthony Alford: Maybe.

Michael Stiefel: So you have version control on the prompts, and you have … Well, the question is then …. All right. Let me think about this for a moment. Because many, many years ago, I worked in the computer design world for military. The military is one of the users of the application. They used to, when they archived the designs, they archived the software that was used to create the design, so if they ever had to revise the design, they could bring back the exact software to use it. Are you suggesting perhaps not only do we archive the prompts, but we archive the LLM that was used with those prompts as well?

Anthony Alford: I think you should. It’s almost like PIP freezing your requirements for a Python environment. I don’t know. It depends on the model we’re using. If the LLM is just a Copilot and it’s helping you, that’s basically the same as copy and pasting from Stack Overflow.

Michael Stiefel: Right, right. Because you have the responsibility, in the end, for what you cut and paste, or what you put in, or what was generated. The question then becomes, at some point, does the LLM become compilers, who we just assumed that it works?

I can remember, one time, actually finding a bug in a compiler because it put an instruction on a page boundary, and we took a page fault that actually caused it, but that’s really sophisticated and you have to understand what’s going on behind the scenes. Are people going to understand?

Roland Meertens: I think you can build up this understanding faster. I personally, people are probably going to laugh, but I have no clue how to write SQL queries or work with other large databases. I don’t really know how to work with, I don’t know, PySpark. But nowadays, all these tools have AI built in, so the only thing I do is say, “Fetch me this data from this table, and then do this with it, and select these specific things.” The first day that you’re doing this, you have no clue what you’re doing but you get some auto generated code which does the thing for you. That’s great, but then after a couple of weeks, you start seeing patterns and you actually start learning it. So it’s more interactive learning for me, and slowly learning an API through AI generated commands. Whenever something crashes, you can actually ask it to fix it, which is insanely powerful.

Michael Stiefel: But you said something very interesting. One of the things you do learn when you’ve done SQL, and believe me, I’ve written my share of SQL in my life, is that for example, if you’re doing certain types of queries, you may want to put indices on columns.

Anthony Alford: Hints.

Michael Stiefel: Or hints. Or you may want to renormalize or denormalize things, for example, for performance. There are all kinds of things that you may not learn or the thing may not know to do. Again, I guess what I’m trying to get at is there’s always some sort of a contextual or meta problem, so what I’m afraid of, is in this new world of LLMs do a lot, that people lose their knowledge of the meta problems. They lose their ability to make change, they lose their ability to have long attention spans, or whatever it is, and they lose the context and they begin to trust these things. Then we find ourselves in a situation where it’s too late to get out of, except to rip the whole thing up.

Anthony Alford: I don’t know if we’ll get to that point. But I do think that … As someone with teenage children, I can see the other side. There’s a reason we’re not still writing machine code, most of us.

Michael Stiefel: Yes.

Anthony Alford: Some of us do. Very few of us, I imagine. But I’m sure that, when the compilers came along, everybody was saying, “These kids today don’t know how to write machine code.”

Michael Stiefel: Yes, they did. There were some, they did say it. They did say, “They don’t know how to write assembly.”

Anthony Alford: But I still learned it and I wasn’t that long ago, I hope. But anyway, where I was going was I like what Roland said. If we can use these things as tools to help us learn things, help increase our productivity, I think that is a good future. I think you sure will lose a few skills, but sometimes … Really, in the grand scheme of things, is writing machine code a skill that people still need?

Michael Stiefel: No, probably-

Anthony Alford: People still can write and writing’s been around a long time.

Michael Stiefel: I know that when phones first came out, the ability to write machine language code was very important. That skill had to come back because you didn’t have virtual memory. You had to worry about memory mapping and things like that, because again, this goes back to the whole context.

Anthony Alford: My wife was still writing assembler in the 21st Century for embedded software.

Michael Stiefel: Yes.

Anthony Alford: For sure.

Michael Stiefel: Again, this comes back to I guess the point of context and knowing where the tool works and where the tool doesn’t work. I’m afraid that that would get lost in such a world, where people don’t know. I guess, as Donald Rumsfeld said, “It’s the unknown unknowns that get you.” Or the limits of the tools that get you. The more you automate, the more you run the risk of that. Where’s the happy medium?

Because again, economic efficiency is going to drive us. The most expensive thing in a programming project probably is the cost of the programmer.

Roland Meertens: Yes. Or alternatively, the highest cost is the very large SQL query this developer wrote, who had no clue how to use indices.

Michael Stiefel: Right.

Anthony Alford: I would say that’s R&D cost. What’s the cost of an outage, a multi-hour, multi-day outage of your software? It’s true, that there are always going to be companies that are foolishly shortsighted in some ways, but the ones that survive, we hope, are the ones who are not.

Michael Stiefel: But the question of what is the path for then getting them to survive? How much suffering is there in the process of that evolution? Dinosaurs disappeared in the process of evolution. They didn’t make it, but that took a long time. The question then becomes how do we know what we don’t know? Because I think the economic efficiency, I’m convinced because I’ve seen this happen over and over again, most managers think programmers are replaceable. Interchangeable, especially if you get to larger organizations.

Anthony Alford: Fungible.

Michael Stiefel: Fungible, okay. That is going to provide an economic incentive for people to get rid of programmers and to use technologies. I remember years ago, before even LLMs came out, people were saying automatic generation of code is around the corner.

Anthony Alford: Yes, they’ve been saying that for a while.

Michael Stiefel: Yes. But there was a strong incentive for managers to believe this because programmers are pains in the neck, they cost money. They say no, so get rid of them. I’m playing Devil’s Advocate here, to some extent, but that is going to be a big push, I think, for having LLMs. Or startups that can’t afford programmers.

Roland Meertens: But then you will lose a lot of the tribal knowledge in companies.

Michael Stiefel: Yes, you do. But are they going to care? The more I think about this, the more I realize this world that we move to is a world that … A lot of technology changes. For example, take phones. No one thought about the attention span problem. No one thought of TikTok. No one thought of spyware. No one thought of all the privacy problems.

Roland Meertens: I agree that, in that sense, the difference between a good senior developer and a bad senior developer I think will be how much restraint they were able to use to either automatically accept every LLM generated proposal, or taking a minute to think through what is actually generated.

Although, reading is going to become a way, way more important skill, reading codes and quickly being able to understand what’s happening, and either accepting or rejecting it.

Michael Stiefel: Well, I think you’re right. One of the things that I learned very early in my programming career is that code is read far more often than it’s written. Code should be written from the point of view of the reader, the potential reader, as opposed to the writer. In other words, Donald Knuth, I’m sure you both know that name, wrote a book called Literate Programming. His idea was you program in an explanatory way.

Roland Meertens: Yes, but how often do you take a moment to read some nice codes? I always think it’s weird that if you are a science fiction writer and people ask you, “What is the last book you read?” If you say, “Oh, I never read books,” people will be like, “Oh, how can he be a good writer?” But if you ask programmers, “What’s the last code you read?” People are like, “Oh, I’m not going to read code for fun.” Even though that’s a new skill to have.

Michael Stiefel: I used to read code all the time because I had to debug other people’s code, look at code. I read code so that I could understand my peers. I’d learnt probably reading code from my betters, when I got stared. Perhaps that’s a skill that’s going to have to come back in the future world.

Can We, or Should We Stop This Future? [43:18]

I’d like to sum up at this point and ask both of you. The question is, based on our conversation and any thoughts you have, what does this world look like and do we really, really want to live in this world? Because now’s the time to say, “Stop.” Now, can we really say stop? Is it like the atomic bomb that’s going to be developed by somebody and then everybody has to have it? Or is there a realistic chance that we can say that this is not a good idea, or it should be restricted to a certain area?

Anthony Alford: I was going to say if anybody can stop it, it would be the lawyers, but I don’t know if they will.

Michael Stiefel: They’re already starting. Well, for example, did you know the story about the Air Canada bot?

Anthony Alford: Yes.

Roland Meertens: I know the story about the Air Canada bot, yes. It promised things it couldn’t promise.

Michael Stiefel: Yes. But the thing is that Air Canada tried to say, “No, no, no, this is a platform. We’re not responsible.” The judge said, “No, you’re responsible.”

Most of them I think are copyright lawsuits right now, but eventually there will be lawsuits. That’s one thing that’s certainly a possibility.

Anthony Alford: If I were going to say here’s how we could turn this future into a bright future, I’d say let the machines write the code, but let’s write really good tests. That’s what I tell my development teams today already. Let’s make sure we have really good tests. If we have really good tests, if we run tests all the time, we run tests for scale, for security and all that, fantastic. We’ll keep an old timer around who can go in and debug the code, or look at the code and make the tweaks. But other than that, let’s let ‘er rip.

Michael Stiefel: What happens when the old timer retires? How do you get the next old timer?

Anthony Alford: There’s always somebody who’s an old timer at heart.

Michael Stiefel: What you’re suggesting, if I understand you correctly, is a division of labor.

Anthony Alford: Yes.

Michael Stiefel: That also means that the LLMs have to learn to write testable code.

Anthony Alford: Well, that’s the key, isn’t it? That’s all of us.

Michael Stiefel: Yes, but that’s the point. In other words, for your division of labor to work, the LLM has to generate code that could be unit test, that could be scenario test, that could be use case test. It has to know how to do that.

Anthony Alford: The way we do testing is we use our API. We write tests that call our API, so end-to-end test it. Unit tests for sure, but end-to-end tests, that’s the truth.

Michael Stiefel: But you also have to test the user interface as well.

Anthony Alford: Right. That’s a great human skill.

Michael Stiefel: Yes.

Roland Meertens: I think for me, as someone who has been using Copilot ever since it was in beta phase, I learned a lot of new tricks in terms of programming from having this Copilot automatically inject code into my code. I have therefore explored APIs which I would normally ever do, like found new tricks which can do things faster. If I would have to think about them from scratch, I would have not implemented them this way. I found I became a better programmer with the help of LLMs. But people should show restraint. Don’t just accept every suggestion.

Michael Stiefel: Right.

Roland Meertens: Keep thinking about what you actually want to achieve. I think this constraint, for me, is the hardest. Sometimes when I get tired, I notice myself accepting everything which gets proposed and that’s the moment where I start writing extremely bad code, very bad prototypes, nothing makes sense anymore, it’s not maintainable anymore. You have to be at least a certain amount of awake to use it responsibly. It’s like a lot of things which are addictive, you got to keep using it responsibly.

Michael Stiefel: I have two more questions before we wrap up. One is, again, how do you train the new developers? You talk about exercising restraint. You’re coming from a world where you wrote code and you know what restraint is. How do you teach the next generation of programmers to fear, to respect, whatever adjective or verb you want to use, to know how to treat the technology?

Roland Meertens: You keep pressing the needs work button on GitHub until they finally get it right.

Michael Stiefel: Anthony?

Anthony Alford: Yes, one of those, maybe … I don’t have the answer, I should have the answer. I think it’s experience. We could copy and paste from Stack Overflow. How do we know whether we should or not? Some of its experience. I think with the younger generation, sometimes you throw them in the deep end.

Michael Stiefel: Yes.

Anthony Alford: Of course, you mentor them, you don’t let them drown.

Michael Stiefel: But they come close to drowning.

Anthony Alford: Really, that’s how people learn is by making mistakes so we’ve got to give people an environment where they can make mistakes. It’s just like now. We’ve got to give people an environment where they can make mistakes, where a mistake is not catastrophic, and I was going to say, cross our fingers.

Michael Stiefel: Well, yes. There’s always a certain amount of crossing our fingers with software development.

Just to ask you the last question. To think about Colonel Nicholson, what would cause you to say, “What have I done with this technology?” What is it that you would fear would cause you to ask yourself, “What have we done with this world?”

Roland Meertens: I think for me, there are a lot of things which used to be fun for me because there was a certain challenge to it, from generating simple websites about something silly or building cool tech prototypes about something cool. A lot of those things which would previously be fun weekend projects, you can nowadays generate with ChatGPT in five minutes and that takes all the fun out of it. As long as I can keep doing things manually, I am extremely happy. But just knowing that something can be automated sometimes takes the fun out of it, unfortunately.

Anthony Alford: I think just losing sight of the fact that we need to stay in control, we need to exercise restraint. We need to not let the robots take over. I think that’s the fear we all have. I think when it comes down to it, that’s the fear we all have is that the robots take over. I don’t think that’s going to end life, but it could be very expensive for a company if something bad happened. That’s where I would see, “What have I done?” I’m not a CTO, but if I were a CTO and we implemented this, and it ruined the company, “Oops.”

Michael Stiefel: Well, thank you very much, both of you. I found this very interesting and hopefully our listeners will learn something, and hopefully we’ll have a chance to make the world a little bit better place, get people to think about stuff.

Anthony Alford: Yes, it was a lot of fun. Thanks for having me.

Roland Meertens: Thanks for having us.