Abstraction Layers in Programming - Jonathan Blow

um personal experience has been that I have had to unlearn all the things I learned at University and my manner of programming now is much more similar to what I did when I was a teenager than what I was doing when I was a new graduate so are we actually making the problem worse than it has to be well I think we are um I don't know if that's the entirety of the problem right I don't know what people would do in the state of nature right but but definitely obviously in programming yeah um people are taught to solve problems by adding abstraction layers right and what is never really admitted is there are several things that are that are not taken into account in the scheme right one your abstraction layer cannot ever it cannot ever perfectly abstract and it cannot ever tightly couple between the layer above it and below it and so it's always adding some slop right and then also your abstraction layer um it's not like pure math living out in the in in the platonic World somewhere it's it's code that has to run right so it has weight and it adds it adds complexity right it takes time to compile um it makes things harder for people to understand because more volume of anything you have more things to understand right um it takes time to compile it takes time to run and so I wish that we thought of code in a little bit of a material science way like you can imagine that it's like okay some code is a lot like uh you know softer and doughier and won't support much weight yeah because it's you know and some code has a lot of like flaws and Imperfections and will shatter if you press on it and some is very robust and strong and you could build a taller building out of it right yes um but no matter what any kind of material as you add more material you add more weight to the thing right yeah if you're building a rocket ship you're very very careful about how much material you add because you know that there's a very large penalty right and I don't think our penalty is as bad as a rocket equation kind of penalty but it's a lot worse than we admit all this code has a cost this case is where a problem will grow in a predictable way and then hit a moment of inflection and then sort of break and suddenly get way worse I sometimes wonder whether um there is a factor like this in software where you have how much complexity can a system have up to the point where one person can understand all of it and it it scales quite sensibly until you hit that point and then as soon as you need to decompose the problem into pieces and no longer can any individual understand it all um the the way that people work on the system just just breaks you could you can no longer identify issues because there's nobody who sees both sides you know both of the causes of a given issue um so back in the mid 90s you could imagine that somebody understood the entirety of Microsoft Word but it's descendant however many years later is probably unmanageably complex and and so it just it's like a difference of of type not just a linear scaling problem or even an exponential scaling problem but just fundamentally broken absolutely I mean as soon as you go from one person to two people the quality goes down right everybody knows or not I mean a lot of people are familiar with the the mythical man month ideas about scheduling as team size grows like you know two people don't program twice as fast as one person because there's there's an interface cost but they could be maybe almost twice as fast but you know seven people is not seven times as fast as one person because yeah all these costs coordinating right those costs though are not only in time they're in quality of understanding and quality of the resulting output right you know programmers who have experience probably can relate it's like you program some stuff and if you're if you're good at engineering you're architecting for future plans and you're like oh I designed this thing this way because if we ever want to do this other thing we can just you know rotate this thing by 30 degrees and like do the thing and then someone comes along later even if you're still on the team I don't know who doesn't understand that and then they go do a whole bunch of stuff to make the thing happen that would have been like you know 10 minutes or whatever and this is common right and you try to you try to solve this problem by having good communication but that's very difficult you know then then everybody spends a lot of time in meetings and everybody's demoralized and and then they're not productive because they're spending all their time in meetings and then you need more people right like if you spend 50 of time in your meetings you need twice as many programmers except you need more than twice as many because twice as many is not twice as fast so like things start to spiral pretty quickly yeah

Channel: gamedev cuts

Views: 18,978

Keywords: gamedev, game development, programming, development, design, game design, programmers, game engines, gaming, thekla, jonathan blow, jon blow, jai, software programming, software development, small team, indie team, the witness, braid, game engine, low level programming, indiedev, programming language, developing games, software is in decline, programmer, software is slow, software engineering, software performance, software complexity, abstraction layers, software abstraction

Id: 6jaVyckxjsA

Length: 5min 35sec (335 seconds)

Published: Wed Mar 29 2023