4 ms·

A comment thread from a couple years ago that resonated with me: https://news.ycombinator.com/item?id=11087399 https://news.ycombinator.com/item?id=11087399 I

A comment thread from a couple years ago that resonated with me: https://news.ycombinator.com/item?id=11087399 https://news.ycombinator.com/item?id=11087399 I watched about a dozen Handmade Hero episodes, and I was a bit annoyed that every session resulted in a random hunt to fix a bunch of bugs because there was not sufficient abstraction. It wouldn't be so bad if the abstractions were upcoming, but Casey seems to have an aversion to abstraction and I stopped watching because I grew bored of watching him jumping around in a bunch of files trying to figure out what memory write caused an issue at run-time.

deleted 9y ago
[deleted]
segmondy 9y ago
So? Watching most folks code is the most boring thing ever. Very few people are entertaining to watch. Abstractions get in the way when one is hacking.
skadamat 9y ago
This is not uncommon in game development. Jonathan Blow and others have spoken at length about why game development is different than web development or other types of software engineering (not in a condescending way but in a "it's different, here's why" way): - https://www.youtube.com/watch?v=JjDsP5n2kSM https://www.youtube.com/watch?v=JjDsP5n2kSM
nbm 9y ago
In order to really start talking about it, we'd need to see someone writing something of similar complexity and longevity live in the same amount of time, and see whether they've spent less time to get to the same place. With the same restrictions of course - relatively little dynamic memory allocation, and hitting frame rate consistently on the lowest supported platform.
jackmott 9y ago
I've gone through the first 20 and don't think you are accurately characterizing them. Maybe 2 or 3 of them involved significant time hunting down a bug. You would likely still encounter bugs while building the abstractions to not have bugs. It might be neat if you could pick out a particular example and show how your approach would have avoided the problem or be quicker though.
kristoff_it 9y ago
That's the exact point of HM. Abstractions come from the knowledge gained after wrestling with problems, not as a form of premature optimization. And this is especially true in games because you need to get all abstractions right otherwise the game will be limited and/or not performant enough. In many other programming fields you don't get punished for adding a few abstractions that are not strictly necessary, so usually other programmers are used to abstracting things away fairly early (eg in OOP: properties vs public variables, ...) because they're free as long as you don't overuse them. Also you should keep in mind that the stream is educational so Casey sometimes takes the scenic route before getting to the point, and he's both implementing the engine and designing it, so sometimes he doesn't know yet what he wants exactly.
- k__ 9y ago
  I'd say you're right if we'd talk about a junior dev, but not when talking about a seasoned senior.
  - abiox 9y ago
    this isn't really an issue of "junior" or "senior".
scallywag802 9y ago
I've watched roughly 90% of the series to date and I'm happy to report that this "jumping around in a bunch of files trying to figure out what memory write caused an issue at run-time" is infrequent, at best. Occasionally there's a gnarly wild-ponter-esque bug that takes an hour, and very occasionally two, to debug, but the vast majority of the time on the series is spent writing new code and refactoring old systems that need to use some new feature. I actually find it amazing that sometimes 400 hours of programming and 2 years later he goes back to code written in the first few weeks and is fairly easily able to modify it to work with a new system that's just been implemented. EDIT: Formatting
ksk 9y ago
The entire point is to show him code an entire game in C from scratch without using libraries, for educational reasons. Given that, what would you like to change and why?
cubano 9y ago
C certainly isn't the language where one expects to encounter deep abstractions, is it?
SeanDav 9y ago
If you writing complex code, you are going to be having bugs, abstractions or not.

deleted 9y ago

[deleted]

segmondy 9y ago

So? Watching most folks code is the most boring thing ever. Very few people are entertaining to watch. Abstractions get in the way when one is hacking.

skadamat 9y ago

This is not uncommon in game development. Jonathan Blow and others have spoken at length about why game development is different than web development or other types of software engineering (not in a condescending way but in a "it's different, here's why" way): - https://www.youtube.com/watch?v=JjDsP5n2kSM https://www.youtube.com/watch?v=JjDsP5n2kSM

nbm 9y ago

In order to really start talking about it, we'd need to see someone writing something of similar complexity and longevity live in the same amount of time, and see whether they've spent less time to get to the same place. With the same restrictions of course - relatively little dynamic memory allocation, and hitting frame rate consistently on the lowest supported platform.

jackmott 9y ago

I've gone through the first 20 and don't think you are accurately characterizing them. Maybe 2 or 3 of them involved significant time hunting down a bug. You would likely still encounter bugs while building the abstractions to not have bugs. It might be neat if you could pick out a particular example and show how your approach would have avoided the problem or be quicker though.

kristoff_it 9y ago

That's the exact point of HM. Abstractions come from the knowledge gained after wrestling with problems, not as a form of premature optimization. And this is especially true in games because you need to get all abstractions right otherwise the game will be limited and/or not performant enough. In many other programming fields you don't get punished for adding a few abstractions that are not strictly necessary, so usually other programmers are used to abstracting things away fairly early (eg in OOP: properties vs public variables, ...) because they're free as long as you don't overuse them. Also you should keep in mind that the stream is educational so Casey sometimes takes the scenic route before getting to the point, and he's both implementing the engine and designing it, so sometimes he doesn't know yet what he wants exactly.

k__ 9y ago
I'd say you're right if we'd talk about a junior dev, but not when talking about a seasoned senior.
- abiox 9y ago
  this isn't really an issue of "junior" or "senior".

scallywag802 9y ago

I've watched roughly 90% of the series to date and I'm happy to report that this "jumping around in a bunch of files trying to figure out what memory write caused an issue at run-time" is infrequent, at best. Occasionally there's a gnarly wild-ponter-esque bug that takes an hour, and very occasionally two, to debug, but the vast majority of the time on the series is spent writing new code and refactoring old systems that need to use some new feature. I actually find it amazing that sometimes 400 hours of programming and 2 years later he goes back to code written in the first few weeks and is fairly easily able to modify it to work with a new system that's just been implemented. EDIT: Formatting

ksk 9y ago

The entire point is to show him code an entire game in C from scratch without using libraries, for educational reasons. Given that, what would you like to change and why?

cubano 9y ago

C certainly isn't the language where one expects to encounter deep abstractions, is it?

SeanDav 9y ago

If you writing complex code, you are going to be having bugs, abstractions or not.