{"id":26011,"date":"2015-02-25T04:26:26","date_gmt":"2015-02-25T09:26:26","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=26011"},"modified":"2019-02-11T08:58:47","modified_gmt":"2019-02-11T13:58:47","slug":"a-new-programming-language-for-games-annotated-part-1","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=26011","title":{"rendered":"A new programming language for games, Annotated: Part 1"},"content":{"rendered":"<p>Jon Blow is the designer of <a href=\"http:\/\/braid-game.com\/\">Braid<\/a> and one of the first of the new-wave indie auteurs.  Back in September of 2014 he made a video talking about his ideas for a new computer language focused on game development. <\/p>\n<p>I wanted to write about this when the video came out, but I was <a href=\"?p=24604\" title=\"Something in the Water, Part 3\">in the middle of a move<\/a>. Then there was Christmas. Then <a href=\"https:\/\/www.youtube.com\/watch?v=FoGnDgqNGkk\" title=\"Reset Button: Playstation3 \">other projects<\/a>. But now almost half a year later, I&#8217;m finally coming back to this. His project has moved on and I don&#8217;t know where it is now, but it&#8217;s this first video I want to talk about.<\/p>\n<p><table class='nomargin' cellspacing='0' width='100%' cellpadding='0' align='center' border='0'><tr><td><iframe loading=\"lazy\" width=\"1024\" height=\"576\" src=\"https:\/\/www.youtube.com\/embed\/TH9VCN6UkyQ\" frameborder=\"0\" allowfullscreen class=\"embed\"><\/iframe><br\/><small><a href='http:\/\/www.youtube.com\/watch?v=TH9VCN6UkyQ'>Link (YouTube)<\/a><\/small><\/td><\/tr><\/table><\/p>\n<p>That&#8217;s an hour and a half talk about why he thinks game development needs a new language, why the existing languages don&#8217;t quite cut it, and a few things he thinks the new language ought to do. It&#8217;s pretty heavy-duty in terms of technical jargon, so if you&#8217;re not a coder I don&#8217;t know if you&#8217;ll get much out of it. <\/p>\n<p>I&#8217;ve seen people criticizing his suggestions saying that other languages already do what he wants, or that he&#8217;s not qualified to design a language. I&#8217;m not really qualified to comment on that and not really interested in that debate. I&#8217;m more interested in his talk as a sort of &#8220;Everything annoying, frustrating, inefficient, or scary about the C languages&#8221;. <\/p>\n<p>So I want to comment on what he&#8217;s said, and I&#8217;m going to do my best to say it in language that should be comprehensible for non-programmers. We&#8217;re not so much discussing his language ideas as using them as a launching point for talking about things that make programming less fun.<\/p>\n<p>Consider this a consolation that we didn&#8217;t get an annotated version Carmack QuakeCon address last year like we have in <a href=\"?p=20541\" title=\"Quakecon Keynote 2013 Annotated: Part 1\">years past<\/a>. Sadface.<\/p>\n<p>Timestamps are approximate:<\/p>\n<p><!--more--><\/p>\n<h3>1:00 Inertia keeping us using C++<\/h3>\n<p>C++ is very much the language of AAA game development. Lots of languages have come along over the years, but nothing has really challenged it. The inertia comes from a lot of factors that form a positive feedback loop that keeps C++ on top:<\/p>\n<ol>\n<li><strong>Lots of libraries.<\/strong> There are tons and tons of C++ toolkits, libraries, and code snippets floating around in the wild. Do you need a sound library? Font loading? Access to rendering hardware? Support for gaming controllers? You don&#8217;t need to write that code yourself, because there&#8217;s a really good chance that someone else has already solved the problem and provided the source code for free. Of course, adding their code to your project is often <a href=\"?p=9557\" title=\"Object-Disoriented Programming\">a lot harder than it ought to be<\/a>, but spending six hours pulling out your hair playing &#8220;dependency scavenger hunt&#8221; is faster than writing everything from scratch, even if it is a dumb miserable way to spend an evening. <\/li>\n<li><strong>Lots of programmers.<\/strong> Since C++ is the big important language, everyone learns it. Which makes it easy to hire people to work on your project.\n<li><strong>Lots of help.<\/strong> Yes, answers to forum questions often take the form of <a href=\"?p=21365\" title=\"How to Forum\">abusive condescension and nerd peacocking<\/a>, but at least a C++ programmer can get their question answered after their tag-team humiliation. If you&#8217;re using one of the more obscure languages, then you might not get any answer at all<span class='snote' title='1'>You&#8217;ll still get mocked, though. Mostly by jackasses asking, &#8220;Why didn&#8217;t you use C?&#8221;<\/span>.\n<li><strong>No dominant alternative.<\/strong> It would be one thing if there was another language out there to play Pepsi to C++ Coke, or could be the Apple to the C++ Windows. But there&#8217;s no clear contender. Java is good for some tasks, Python is good for others, but none of the challengers works as a broad general-purpose language. And that&#8217;s fine. There&#8217;s  lot of value in specialization. But that focus helps drive the C++ feedback loop of ubiquity.\n<\/ol>\n<p>When creating a new language, you can either break from the old ways entirely&#8230;<\/p>\n<p><strong>You fool! Nobody is going to give up the universe of libraries to screw around with your language! It&#8217;s useless!<\/strong><\/p>\n<p>&#8230;or you can try to have some sort of compatibility with C&#8230;<\/p>\n<p><strong>You fool! If people wanted C they would have just used C! You&#8217;re just dragging those old problems into the new language! It&#8217;s useless!<\/strong><\/p>\n<p>&#8230;or you can whine about how much C sucks and not do anything about it. That&#8217;s sort of the strategy I&#8217;m using.<\/p>\n<h3>3:30 Not a Big Agenda Language<\/h3>\n<p>We run into a lot of really common problems in programming, and every once in a while someone invents a language that tries to solve one of these problems. Blow offers two examples of &#8220;Big Idea&#8221; languages. Functional programming, and a language where buffer overruns are impossible. <\/p>\n<p>Taking the last one first:<\/p>\n<p><strong>Buffer Overruns are impossible.<\/strong><\/p>\n<p>A buffer overrun is when you allocate space for N objects, but then try to interact with some object greater than N. If I create a buffer of 20 space marines in memory and then (because I&#8217;ve got a dumb bug in my program) I try to do something with space marine #25, then I&#8217;m actually reaching into a block of memory beyond what I set aside. What is in that space of memory? Maybe some other stuff. Maybe garbage. This leads to crashing and random behavior. It&#8217;s a pretty common mistake, and so we&#8217;re always looking for ways to protect against it. Some people are even attempting to solve this by inventing new languages where you can&#8217;t do it. <\/p>\n<p>Making buffer overruns impossible sounds useful, but it doesn&#8217;t magically stop you from writing bugs. If I access space marine #25 in my list of 20, I&#8217;m still making a mistake. The language might give me #20, or it might ignore all the stuff I attempt to do to #25, but I&#8217;ve still made a programming mistake. Maybe I&#8217;d rather have the program crash so I can find the bug. If I was dealing with a list of bank customers instead of videogame space marines, then maybe I REALLY don&#8217;t want the program to attempt to quietly carry on. <\/p>\n<p>So protecting against buffer overruns is an interesting feature in a language, but it&#8217;s not something everyone wants or needs. And different people might have different ideas on what the protection should do.<\/p>\n<p><strong>Functional programming<\/strong> is an approach to programming that tries to solve the problem of unmanageable complexity. Modern software projects &#8211; and games in particular &#8211; are terrifyingly complex beasts. You might be dealing with millions of lines of code that manipulate thousands of different ideas, and it&#8217;s not at all possible for any one programmer to understand how the whole thing works. Consider this pseudo-code:<\/p>\n<pre lang=\"c\" line=\"1\">\r\nvoid SpaceMarineUpdate ()\r\n{\r\n  if (fire_button == PRESSED) {\r\n    FireBullet ();\r\n    num_bullets = num_bullets - 1;\r\n  }\r\n  if (num_bullets < 1) \r\n    Reload ();\r\n  \/\/We should probably add some movement and animation code in here as well. \r\n}\r\n<\/pre>\n<p>So if the player is holding down the fire button, then shoot a bullet and subtract 1 bullet from our current supply. Then on line 7 we see if the gun is empty. If so, we trigger a reload. <\/p>\n<p>However, what this programmer is overlooking is the staggering number of side-effects that happen inside of FireBullet (). Maybe the bullet hits a red barrel, which blows it up, which kills our space marine. So let's say the player uses their last bullet to shoot a barrel to kill themselves. In that case, they would die on line 4, and then line 8 would cause the SpaceMarine to begin reloading, even though they're currently DEAD. That's at least buggy behavior, if not a crash.<\/p>\n<p>This kind of thing happens all the time. In the above example, maybe the programmer should have done a check right before attempting to reload to make sure the marine was still alive. The problem is that it probably didn't occur to them that it was possible for FireBullet () to result in death<span class='snote' title='2'>I mean, other than the hundreds and hundreds of other space marines this space marine is trying to kill.<\/span>. Once a project gets above a certain size, it's impossible to know all the things that might happen when you call <code>FireBullet ()<\/code>. That one function might cause thousands of lines of code to execute before it's through. Stuff will blow up, particles will be created, sound effects will start, and things will be damaged or killed. These are called <strong>side effects<\/strong>. These systems are not part of a space marine (much less a bullet) but they are changed when a bullet is fired.<\/p>\n<p>Functional programming attempts to fix this. In a completely functional program, no side-effects are allowed. In a completely functional <em>language<\/em>, no side-effects are <em>possible<\/em>. When you call SpaceMarineUpdate (), it doesn't change any part of the game state. Instead, the program creates a new SpaceMarine object with new properties, and some other part of the program (the one that called <code>SpaceMarineUpdate()<\/code>) will (one assumes) replace the old one with the new. The program has to say to the SpaceMarine (), \"Here is a bullet. Shoot yourself with it and then return a copy of yourself exhibiting the result.\" <\/p>\n<p>It's actually really hard to get stuff done, and I'm not even sure how you go about handling actual side-effects that need to take place. (Like people getting killed by splash damage from exploding barrels.) And it's not clear to me how you're supposed to go about creating bullets and things. <\/p>\n<p>Functional programming is a new idea. It needs to be proven and we need to figure out how \/ if we can use it to model complex games with lots of inter-connecting systems. It might be big someday, but right now it's not ready for AAA development. <\/p>\n<p>So I just spent 1,500 words on the first 3 minutes of video. Don't worry. It goes faster after this. This series will continue until I make it through the whole thing. Probably about three parts. Maybe.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Jon Blow is the designer of Braid and one of the first of the new-wave indie auteurs. Back in September of 2014 he made a video talking about his ideas for a new computer language focused on game development. I wanted to write about this when the video came out, but I was in the [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"class_list":["post-26011","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/26011","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=26011"}],"version-history":[{"count":2,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/26011\/revisions"}],"predecessor-version":[{"id":45742,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/26011\/revisions\/45742"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=26011"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=26011"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=26011"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}