4 ms·

If the OP had been asking questions, I might. Instead, they were posting unfounded, authoritative, nitpicking negativity ("the Command interface wasn't a good r

If the OP had been asking questions, I might. Instead, they were posting unfounded, authoritative, nitpicking negativity ("the Command interface wasn't a good replacement") against what looks to be a reasonably good book. I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal.

gravypod 9y ago
> unfounded, authoritative, nitpicking negativity After seeing shadowmint's reply I understand why the "Command" organization is a good idea. Like shadowmint I don't see Jump as being a good example. The examples in this book make it difficult to see why this is a good idea. If the examples of this book are taken to heart and directly applied then I think the code of the resulting game would be unwieldy. It seems the only people who understand what the author is trying to show are the ones who actually have experience in the field where they've constructed these methods of scaffolding already. If this book is directed at programmers who are not game developers yet then this book as not succeeded. As a programmer, who's spent more a quarter of their years on this Earth in the field, if I can't get the sense of why a pattern shown in this book would be useful then I think there's a problem. The book is not effectively reaching it's intended audience: programmers who are not game developers or who are new to game development paradigms. I think my point still stands. For what the example is showing the Command interface isn't an appropriate replacement for the if-else tree. I still think an Event system is a better choice for dispatching an action to handlers. It seems like real game developers also feel this way (see BatFastard's comment). > against what looks to be a reasonably good book A good book can have a few bad examples. A good book also requires many revisions. This is more so when you're talking about technical books. Do you think the first revision of the Art of Computer Programming was perfect when published? There are many hexadecimal dollars out there to show you that is not the case [1]. > I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal. If you refuse to look at valid criticism and just go strait to saying "Oh HackerNews is so negative! That's why people are agreeing with you!" then you're going to be avoiding a treasure trove of good information out there. I've had much harsher "criticism" of my work levied in person by people I actually know and instead of putting on blinders I addressed it and ended up with a better product in the end. [1] - https://en.wikipedia.org/wiki/Knuth_reward_check https://en.wikipedia.org/wiki/Knuth_reward_check
- ghusbands 9y ago
  I should be less abrupt. For that abruptness, I apologise. However, I think that you might want to consider the effects of the decisions you make and the size of your generalisations. You have a problem with a particular application of a particular example in a particular chapter of a book, on a technique you don't fully understand, and provide wider comments that explicitly undermine the whole book, that may well dissuade people who could benefit from reading it.

gravypod 9y ago

> unfounded, authoritative, nitpicking negativity After seeing shadowmint's reply I understand why the "Command" organization is a good idea. Like shadowmint I don't see Jump as being a good example. The examples in this book make it difficult to see why this is a good idea. If the examples of this book are taken to heart and directly applied then I think the code of the resulting game would be unwieldy. It seems the only people who understand what the author is trying to show are the ones who actually have experience in the field where they've constructed these methods of scaffolding already. If this book is directed at programmers who are not game developers yet then this book as not succeeded. As a programmer, who's spent more a quarter of their years on this Earth in the field, if I can't get the sense of why a pattern shown in this book would be useful then I think there's a problem. The book is not effectively reaching it's intended audience: programmers who are not game developers or who are new to game development paradigms. I think my point still stands. For what the example is showing the Command interface isn't an appropriate replacement for the if-else tree. I still think an Event system is a better choice for dispatching an action to handlers. It seems like real game developers also feel this way (see BatFastard's comment). > against what looks to be a reasonably good book A good book can have a few bad examples. A good book also requires many revisions. This is more so when you're talking about technical books. Do you think the first revision of the Art of Computer Programming was perfect when published? There are many hexadecimal dollars out there to show you that is not the case [1]. > I understand that blithe, negative comments tend to rise to the top on HN, so I guess it's normal. If you refuse to look at valid criticism and just go strait to saying "Oh HackerNews is so negative! That's why people are agreeing with you!" then you're going to be avoiding a treasure trove of good information out there. I've had much harsher "criticism" of my work levied in person by people I actually know and instead of putting on blinders I addressed it and ended up with a better product in the end. [1] - https://en.wikipedia.org/wiki/Knuth_reward_check https://en.wikipedia.org/wiki/Knuth_reward_check

ghusbands 9y ago
I should be less abrupt. For that abruptness, I apologise. However, I think that you might want to consider the effects of the decisions you make and the size of your generalisations. You have a problem with a particular application of a particular example in a particular chapter of a book, on a technique you don't fully understand, and provide wider comments that explicitly undermine the whole book, that may well dissuade people who could benefit from reading it.