The annotation continues…
6:00 Garbage collection.
In C++, you have manual memory management. You need to request enough memory to hold all your space marines. If you need more marinesWho doesn’t? you have to allocate more memory. When you’re done with a marine, you have to tell the system you don’t need that chunk of memory anymore. You can’t ever make a mistake, because using memory you’ve freed causes a crash. Using memory you haven’t yet obtained causes a crash. Trying to free the same bit of memory more than once causes a crash. And forgetting to free memory causes a memory leak where your program will consume more and more until it crashes.
And by “crash” I mean, “It might crash or it might malfunction badly somewhere later and you’ll have NO IDEA where it all went wrong.”
Garbage collection is where the language itself manages your memory for you. When you’re done with a space marine, you just forget about him. At some unknown point in the future, the garbage collector will run. It will eat some processor cycles and figure out what bits of memory you’ve allocated but are no longer using, and it will free them for you. But you don’t control when GC runs, and it has some performance cost. So, right in the middle of your high-performance game you might have this random process kick off at an inopportune moment.
This is the stuff of flame wars. I’ve seen people claim that garbage collection is terrible and slow, and I’ve seen people claim that it’s super-fast and complaining about GC performance problems is merely ignorance and superstition. I strongly suspect it depends on what you’re trying to do and how your program uses memory.
I don’t know personally. The only GC language I’ve used is Java, and I wasn’t doing anything resource-heavy at the time.
I’ve often wondered how feasible it would be to offer a language with garbage collection, but have the GC only run when you allow it. Something like, “Here’s five milliseconds”, do as much as you can in that time.”
I don’t know enough about how garbage collection works under the hood to know if that even makes sense, but I think it would be a really attractive compromise between “manage memory yourself” and “have the program devour an unknown number of CPU cycles at an unknown point in time”.
The game Continue?9876543210 is all about a videogame character who is no longer in use and is trying to escape the garbage collector. I didn’t play it, but Chris did:
13:00 I think making a compiler is easier than making a AAA game.
A compiler is a program that will take your code…
1 2 3 4 5
100 REM BASIC WAS A FANTASTIC EARLY LANGUAGE. 110 PRINT "Shamus Young's BASIC program of text-spewing." 120 PRINT "For best results, direct the output to a printer" 130 PRINT "that belongs to someone else. Screw trees!" 140 GOTO 100
…and turn it into an executable that anyone can run. It’s a program that takes source code as input and other programs as output. Blow is suggesting that making a AAA program is much harder than making a program that makes other programs.
On one hand, this sounds sort of audacious. On the other hand: Given the amazing number of programmer-hours that go into these games, it stands to reason that they would have to be more time-consuming than a compiler. In the old days, compilers were often one-person projects.
Having said that, I suspect (with no experience to back it up) that the trick of making a good compiler isn’t in getting it to work, but getting it to work well. It’s not that you need a lot of hours, it’s that you need lots of iteration. You release it, people use it, find problems or ambiguities, you make improvements. Repeat. Forever.
I don’t feel any big need to make my own language, but I’ve often thought it would be a very good self-educational project to make a compiler.
17:00 Joy of programming.
Blow makes the case that a good language will be fun to use and that we’ll be more productive simply because there will be fewer days when you get demoralized by confusion. Writers get writer’s block. Programmers get daunted by complexity and the dread of untangling something incomprehensible.
And I think he’s basically right: There really are “quality of life” issues when it comes to dealing with difficult code and unsatisfying solutions. Can a new language fix this? Making a new language to make programming more comfortable is like a writer that stops working on his book to remodel the room where he does his writing, in hopes that the new setting will make him feel “more motivated”. It’s probably not actually worth the trade-off in terms of time, but it can sound really appealing if you find yourself stuckAnd if you ARE stuck, it’s probably a good way to fill the time.. And I often find myself stuck.
He says this new language should be “designed for good programmers”, which touches on a long-standing debate we have in language design. Programmers make mistakes. Most of our mistakes fall into a very small number of different categories. The same mistakes pop up again and again, and so sometimes languages are designed to protect us from making those blunders. But protection is often restrictive in some way. I don’t care if you’re talking about body armor, training wheels, airport security, speed limits, or bounds checking on arrays, when you’re being protected you’re usually also being hindered in some way. This doesn’t mean that protection is bad. It just means that in some cases you might prefer to live dangerously and go without the protection. We wouldn’t want to replace all scissors with safety scissors, and in the world of videogame programming, we might not want to hinder our good coders to help our bad (or inexperienced) ones.
There’s a bit of an interruption in the presentation here when Blow realizes he labeled the graph wrong and he feels the need to fix it. (Which I totally understand.) But I don’t want that to distract from the point he’s making, which is something too many young programmers don’t grasp. Heck, I think old programmers have trouble with this concept. The problem he’s talking about is that program complexity takes a massive toll on productivity. In the first two days of a project you’ll feel like a miracle worker who can do anything, and in the last two days of the project as the codebase sails over the event horizon of human understanding, you’ll struggle to change even simple things without creating a dozen bugs. It’s the reason so many projects ship lateThis is why programmers have the adage, “The first 90% of the project takes 90% of the time, and the last 10% of the project takes the other 90% of the time.. We tend to make our time estimates in those early days before things get out of hand.
This is based entirely on my own gut feeling, but I have the sense that if you could actually plot the complexity / cost dynamic on a graph for real, you’d see the cost rise on an exponential curve. As you approach the limits of the programmers ability, the time cost shoots up drastically. If this is true (and not just my own bitterness over too many projects that got away from me) then any change that can bring the complexity down a couple of notches could have a huge payoff.
Again, I’m not endorsing his languageI haven’t even caught up on his later presentations to know what his language is like.. I’m just saying that runaway complexity is a real problem and that the payoff might be bigger than it seems. A 5% reduction in complexity might result in more than 5% reduction in cost.
 Who doesn’t?
 And if you ARE stuck, it’s probably a good way to fill the time.
 This is why programmers have the adage, “The first 90% of the project takes 90% of the time, and the last 10% of the project takes the other 90% of the time.
 I haven’t even caught up on his later presentations to know what his language is like.
A look at the main Borderlands games. What works, what doesn't, and where the series can go from here.
Philosophy of Moderation
The comments on most sites are a sewer of hate, because we're moderating with the wrong goals in mind.
Video Compression Gone Wrong
How does image compression work, and why does it create those ugly spots all over some videos and not others?
PC Hardware is Toast
This is why shopping for graphics cards is so stupid and miserable.
There are two major schools of thought about how you should write software. Here's what they are and why people argue about it.