Hacker News Reader

Comment by 0xbadc0de5 | Hacker News Reader

Having watched Casey's Handmade Hero series since day-1, I've always found him to be highly skilled and insightful. While not a game developer myself, learning from his approach to first-principles software development and code optimization has paid dividends in my day to day work nonetheless.

View on HN

I've found him passionate and smart. But rarely right.

Like him bashing SOLID principles. It read like a man arguing against hammers, and instead suggesting using drills (which is fine if you need to drill a hole but bad advice if you want to hammer a nail). Like yeah, SOLID is over used and over-stated, but they were invented to stop certain set of problems.

Not to mention that the “S” in SOLID is closely related to what he is talking about here, namely that a software component ought to be related to only one specific source of changes – i.e. a box in an org chart – in order to minimize the risk of it being changed badly and consequently break something. This implies that you should have a connection between the org chart and the code, in order for the changes in the code over time to not constantly break the code.

With both Casey and Jon Blow I find that if I mentally prefix what they say with "When developing AAA games..." then they are almost always right. Much of it doesn't transfer far outside that domain.

What are you talking about? Neither one of them has ever shipped a AAA game.

I think it's charitable to read that as shipped a relatively performant game.

Actually the funny thing is that Braid's CPU usage was always kind of high for what it was doing. Not sure about The Witness.

The emperor definitely doesn't have any clothes though when it comes to either one of them.

Yeah his claims about good and bad are too unconditional and generic. He always looks at it from his specific vantage point and then declares something categorically bad which ticks me off cause its so dogmatic and lacking of contextuality.

The most bizarre part is that he took issue which the Liskov substitution principle which is just the intuitive definition of what semantic subtyping means. This isn't some crazy clean code "functions should have less than 20 lines" dogma, subtyping without semantic subtyping is just nonsensical.

> SOLID is over used and over-stated, but they were invented to stop certain set of problems.

The problem is, when was it ever shown they solve any problem? Where are the measurements showing less dev time or less bugs or better performance? Where even is an algorithm to show your software is SOLID? People can't even agree on what those mean.

SOLID is for long-term development and use software. Games are developed during a relatively short time, and then released, and then not changed very much. The next game is developed independently, as a separate project and effort. SOLID is meant to alleviate continous development where changes and new features are constantly needed. Game development does not easily fit in this mold.

Tell that to World of Warcraft. Really is hilarious just how goddamned clueless most of the comments in this thread are.

Please don’t misunderstand me; I really think that SOLID is good to follow. My comment was more meant to express understanding for people having doubts about SOLID in situations where the SOLID principles don’t give as much of an obvious benefit.

I would say it's more like a builder arguing against building codes. A high-quality building can certain be built without them, but sticking to some known formulas makes sure that everyone working on it is able to anticipate what others are going to do. It also makes sure that the building won't collapse, though this aspect doesn't really apply to software.

Software has gotten a lot more complicated since the 1990's and from my experience, projects where design patterns are used effectively run a lot more smoothly than those where they're not used or not used effectively. It's great when you can open a project from 15 years ago and say "Actually, the code isn't too bad!" because the developers followed some rules of thumb.

I agree with Casey that these rules of thumb aren't going to lead to higher-quality software from the end user's perspective. I doubt that they're going to make it worse though, unless they're blindly followed.

On the other hand, Casey's been working on Handmade Hero for almost a decade, and has what amounts to an overengineered debug room with less actual gameplay complexity than you'd find in any framework tutorial. Meanwhile actual game developers would pick up a framework, use all those abstractions and libraries Casey finds unnecessary and surpass Handmade Hero in an afternoon.

There's something to be said for not wasting time on things that don't matter to anyone but yourself, and code aesthetics is often one of those things.

He works on HH for about 2 hours per week.

That's still far too much time for far too little progress. Six hundred videos and counting, each over an hour in length. What is there to learn except how not to develop a game, much less (as I recall him claiming) a AAA quality game.

That's not true. He works on it offline, and honestly, even if he did only work on it 2 hours per week, it's STILL not as far along as it should be by now for a supposed game development "guru." You got hoodwinked.

What's hilarious is that if you actually look at the code he's written for it, it's a horrible ball of spaghetti. The whole thing is a scam. Just because HE says "this is bad code" doesn't mean it's bad, and just because he wrote it, it doesn't mean it's good. Most people would find the clusterfuck he wrote unmaintainable, and the funny thing is that it doesn't even really DO ANYTHING YET.

The goal of Handmade Hero is to show how to do everything from scratch, not how to make a game as fast as possible using existing technology. I agree that the game is currently light on the gameplay side of things, but he said countless times that he doesn't like gameplay code and that he's an engine programmer. I don't know if you watched a lot of episodes, but actually, each hour of him programming is full of complicated stuff which is hard to follow, but he does that in the blink of an eye. Each time you think that you understood something, he starts doing something way more complicated and he always nails it. Look at how many programming streamers are able to speak 2+ hours continuously without any cut. Most of the youtubers have to look at their source code written before turning the camera on to be able to retype it during the video! Even for a simple Tetris or something!

I'm curious to know what you think is unmaintainable in his codebase. Sure he uses alternative little-known techniques for say, memory management, but once you know what is going on, the code is pretty clear I think.

He posted an issue about the Windows terminal being slow, and proposed simple things to speed things up. What happened? The Windows Terminal team declared that what he proposed is an entire doctoral research project that would be a massive investment. He did the freaking thing in 2 days and said that it's "nothing" and "very simple". The team then apologized for being dumb and is now working on implementing his idea, that they described as "original" and "very valuable"

I have no opinion on them as this is the first time I see them but their misrepresentation of Amdahl's law bothered me as their version makes it incorrect to the point of being useless. Here's how they present it:

  T(n) = b + (T(1)-b)/n

  T(n): Time to run task for n parallel threads (workers)
  b: Time it takes to run part of task that can not be parallelized

  Therefore:

  T(inf) = b

This misses the cost of coordinating between workers. It also removes the key part of it being a theoretical limit of the speedup as resources increase.

Their attempt to simplify it makes the new version dangerously wrong if you take their word for it.

Less wrong:

  T(n) >= b + (T(1)-b)/n

Or even (but now it's not really Amdahl's again):

  T(n) >= b + (T(1)-b)/n + C(n)

In fact, for many problems T(n) > T(n-1) for some n, as at some point C(n) > (T(1)-b)/n

This is not really "a more subtle improvement", "new version", or "refinement". It was known in the field in the 70s. That is, Brook's Law can apply to parallelized computation, not just to teamwork. Which OP observes but still doesn't make them see the errors in their previous assertion.

Reply on news.ycombinator.com