Jonathan Blow on why C++ is a bad language for games

the answer is that C++ is a really terrible terrible language um so it would really help us to get off it as quickly as we can but here's the funny thing right despite the fact that it's such a terrible language games use it you know in if you talk about lower-end games you know there's games obviously in browsers or that use C or something but the highest performance games that render the most uh impressive things and have the most complex simulations all use C++ still it's the year 2018 right C+ plus is from the 1980s it's been modified a little bit but the idea for the language was come up with in the 1980s so uh why do we still use it and the answer is because despite as as terrible as it is it still does something right that's very basic that almost every other language that's been made since then actually gets wrong so I'm going to talk about some wrong ideas that have been happening uh for the past few decades um I'm going to start with maybe what is the most basic one uh this is an attitude that I think uh came out of academic circles but it's percolated through industry and it's everywhere now and it's an idea about okay what should a language help you do it should help you be a more uh powerful and expressive programmer who can get more things done quickly and they work better and how do you do that well uh there's some kind of idea that's like climbing to heaven or something where like the language lets you express higher and higher level things and uh we don't care about like implementation details like like where memory comes from or how much time things take really except in very uh broad uh scoped algorithmic uh measurements um because implementation details are complicated to think about and they slow you down and if you didn't have to think about those implementation details that's much less work to do and you're more productive so the idea here is that you know somehow the job of a programming language is to put you in some kind of magical space where you're just programming with magic and clouds and Daydreams and stuff like managing memories or managing memory you don't think about like what your data structures even look like you don't need to know and all that stuff and uh the way that I've stated this it's obviously making fun of the idea a little bit but this idea I think underlies uh most programming language designs from the past few decades and it's wrong um but despite the fact that it's wrong there's been some success with it um you know starting in the 1990s I chose the year 1991 a little bit arbitrarily but sometime in the 1990s we started having this trend of a whole bunch of interpreted languages happening so like Pearl and Python and all these things um because the idea was like hey we want to make things that are high LEL C is like a low-level compiled thing interpreted languages like lisp or high level so we're going to do things like that and you know what computers are fast enough that it's not going to matter you're just going to run your script and it's fine it's just going to run interactively fast and nobody will care what language it's in but because our language is going to have all these high Lev features uh it's going to make you a more productive and Powerful programmer so that was theide idea and it actually sort of succeeded uh for a while right but it caused a a problem because um well let me go back and talk about another kind of language for a second right so one kind was the scripting language and another kind is what you know Microsoft has since then called the managed languages you know is maybe starts with things like Java and has since proceeded to things like C and whatnot where uh you know it's supposedly a compiled language but you have a very heavy runtime that imposes performance costs you know maybe it's garbage collected or something but it also has a lot of opinions about what your program is allowed to do and about what implementation details of the machine it's allowed to play with right so those are sort of the two major categories of things and something happened where you know all these languages got made and they actually do have higher level features that help you do things faster right they also are pretty slow languages is and because these things have been correlated again and again in these examples that we've seen over the years many or most people I would say believe or maybe not even believe but just in their mind there's this uh conflation between languages being slow or giving you a lack of control over what's happening and those languages being powerful and expressive and giving you high level uh ability to manipulate things and that's not actually true uh those two things are actually mostly orthogonal so for example you can have a language with most of the features of C but that's as low level as C at the same time it's just nobody's really made that and so we've never seen that example and so our brains don't really understand it right um here's another idea that's wrong uh that most of the world labors under uh and I'm sort of thinking of it as climbing to Heaven part two there's some weird idea that more layers of software is a good thing right so like somebody makes some code like in a library that does some job and then I'm going to make my library that's like a wrapper around their library and it's mostly just going to call their stuff but I'm going to add like 10% on the side right and now you can use my library instead of their library and then somebody else comes along and adds it like another 10% right and you start stacking these libraries enough and then that's not even enough so like now let's make a program that uses all these libraries but like the program itself will not really do the whole job It'll like talk to other programs on the same computer computer over like local sockets to do the rest of the job and each of those programs will have all its libraries right and the idea that people have is like you stack up these layers of code and it gives you something better and better right but I think that most of us know uh who have done a lot of real work that what you get in that case is not really better and better it's actually worse and worse right because the stack is not a well constructed thing it's like wobbly right and if you try to climb up on it it's going to just like fall over and dump you on the floor right so more layers of software you have right the more software you have the harder it is to understand the harder it is to uh be clear about what the interactions are between all the layers for you is someone who wants to debug or modify this but also for the people who wrote it originally right so these layers don't generally couple together perfectly they're sloppy right they move there's lots of times when you're not sure what's really going on and those are magnified as you have more and more layers and then also of course more layers take longer to compile and all those usual problems um there's a lot of other weird assumptions this one isn't exactly about language semantics anymore but people have this idea that in the modern world if you're going to program you need this complicated slow buggy thing called an integrated development environment like Visual Studio or xcode that gets between you and the active programming right so like you can't like program without this thing the job of which is I don't even know what the job is right because it's it's like it's not exactly the debugger the debugger is a separate thing but like it lives there it's not really the editor because you can use a separate editor it's like the thing that knows what files are in the project or something it's it's a weird Frankenstein's Beast actually the main job of which is to make up for the fact that a lot of languages are underspecified and I'll say exactly what that means soon but people have this idea you need this thing and in fact I think the value of this thing is very close to zero or it's actually negative because it gets in your way so much the actual value is in the debugger and the editor right the IDE is just a giant piece of junk um in my opinion people also have another weird idea that uh a programming language should be like a grand ecosystem and if you're going to come up and start using it then you're entering the ecosystem and you get to learn about all these crazy things not even just just about languages actually uh anything now so I was at the GDC this year and I was in the presentation about the Vulcan Graphics API right and the guy puts up this slide multiple slides actually talking about the Vulcan ecosystem and he has all these boxes with lines between them and there's like funny names of what all these like different things are in the boxes and I'm just like oh my God like you just killed all enthusiasm I had for learning about this thing I don't want to learn an ecosystem for a year I want to just put 3D graphics on the screen right so like actually if somebody is making a system that's good for you to use it's as simple as it can be while enabling you to do the job it doesn't force you to like learn all sorts of obtuse stuff in order to do a job but somehow people are stuck in this mindset that that is what it's supposed to be you know it's like it's like when you have a division of a company or a government and it used to have a real job but now its job is to perpetuate itself and make itself bigger right that's what all software projects are now and it's really sad uh so we're getting to smaller and smaller points here but one common one that maybe uh C++ programmers are much more familiar with uh there's all these people saying if you're going to be a good programmer in these languages you should use this thing called raai right or in some other languages like Swift or something like use ARC automated reference counting because it takes care of your memory for you and all that uh and that makes you a good programmer and you don't have to think about these details and have fewer bugs and you have more memory safety and all that and it's like okay you could do that stuff but the cost is actually tremendous right when you do that stuff your program ends up 100 times slower than it should be maybe more and people who are proponents of these techniques will get very upset as soon as I say that because they're like no no no ra like the Constructor Destructor they inline they don't generate that many instructions like the reference count for Arc is just that can get optimized out a lot of the time and even when it doesn't it's small but that's beside the point because the problem isn't the instructions that are generated at all the problem is not the actual code the problem is that conceptually when you program in this way you are thinking about the things in your program as a bunch of tiny little uh isolated units that live in random places on the Heap because like if you've got a reference count and it's going to go to zero what happens well it gets freed what does that mean it gets freed well just somewhere on the Heap is now available for other memory to go well what does that mean well when you're navigating these data structures then they're scattered across the Heap uh and what does that mean it means you're going to miss the cach a lot right so the difference in performance uh between an L1 cache hit and a miss that goes all the way out to main memory is a lot more than a 100 times actually it's several hundreds on most modern CPUs so saying that your software is only going to be a 100 times slower if you do these things is kind of giving you the benefit of the doubt that you like worked in some other optimizations along the way uh but it doesn't just make your code slower it makes it harder to understand right like a lot of the times there are things associated with the destruction or of a resource that are important for program correctness like I need to know when this file is closed because the next step of my program can't validly happen until I know that that's true if you start hiding things like that inside like well we reference counted this thing and it went to zero and when it goes to zero the file closes you don't really know anymore when the file closed or maybe the person who originally wrote the the program did and now you're coming along looking at it and you're like I have no idea what's going on because this is not explicit anywhere right even if that was you who wrote it like three months ago so being explicit about things that are important is good for software quality and hiding those things is bad for software quality uh okay so I could actually go on for a long long time just listening more and more of these things that are supposedly common knowledge about how to program well that I think are completely wrong um but I'll just stop listing them because we have a lack of time and I'll just say Well when somebody sits down to design a programming language um they are doing that because they want to help you right they want to well I mean sometimes uh but but giving the benefit of the doubt right they want to help you they want to make a thing that helps you program in the good way the way that's going to be productive and uh the problem is that they have all these wrong ideas about what that good way to program is right and so if you have an idea that's different from that about how to program you can't actually use the languages designed by these people actually not most of them uh because you'll end up fighting the language all the time because the language is built to support a certain type of programming that you don't necessarily want to do and that's actually why we still use C++ today because C++ actually lets you kind it doesn't put so much of a runtime in the way that it doesn't prevent you from doing very specific low-level things when you decide that you need to do them of course the language is still evolving over time and it's getting crazier and crazier but uh at at this point it's still kind of okay um

Channel: Jonathan Blow Highlights

Views: 50,506

Keywords:

Id: VglTrU5YmRw

Length: 13min 44sec (824 seconds)

Published: Wed Jun 12 2024