While this book seems to get a lot of praise (as it deserves, obviously), I wish the style of teaching complex programming topics walked me through the pain of making something work, exploring a few alternative solutions, showing the tradeoffs, and then after the pain has been experienced by the learner, a proper solution is finally introduced and recommended. IMO it's a much more powerful technique for teaching if you walk the learner through the pains first, then arrive at a solution, and tell them that "you've just invented the game loop!"; i.e. the concept is given a name at the _very end_, not defined at the beginning as a solution to a pain the learner never experienced. Unfortunately very few books/tutorials take this approach.
This, I think, one of the fundamental challenges of teaching software architecture or other higher-level engineering topics. A lot of architecture boils down to:
1. Here's an obvious simple way to solve a problem, X.
2. If you do X at scale, much later, you will run into pain.
3. So here's Y, which seems weird and non-obvious but solves the same problem as X without the pain.
It's really hard to teach people step 2 when they haven't experienced it first-hand. You can walk them through scenarios, but most scenarios small enough to fit in a reasonable amount of prose feel fake and contrived.
Even when this does work, you can end up with a generation of programmers that cargo cult Y without any real understanding of the original problems it avoids from X. Look at, for example, how "goto" is now a boogeyman in programming well beyond the narrow concrete problems Dijkstra had with it.
For many of the chapters of the book, I try to walk readers through the problems of simpler approaches as well as I can, but it's a continuing challenge. There really is no substitute for experience.
Thanks Bob, I appreciate your response. To be honest, I haven't read the entire book. However, I looked at the table of contents, and it appeared to be a run-down of well known game design patterns. For someone who wants to get educated on those patterns, that's probably fine. For someone new to the topic of game programming, they're probably going to benefit from the style I described, e.g. hand-holding them in creating a game from scratch, progressively going from simple to complex after understanding the pains along the way, introducing new concepts as needed and just-in-time. So this may have been just an issue of understanding who's the audience of the book.
That being said, the point about doing X at scale wasn't my issue. Take for example programming language books and/or documentation. The typical approach in almost every book/guide is teaching you about syntax, data types, control structures, etc. While this is valuable information, it's not usually what a person new to the language is looking for. What they're looking for is (most probably) what is unique about this language in solving specific domains of problems. New to Erlang? You probably should be introduced to a problem that deals with concurrency and reliability, and get walked through an example of how Erlang can solve it elegantly. New to Python? You should probably be introduced to a problem that deals with manipulating data, and get walked through an example of how Python can help you wrangle data easily. Etc.
> For many of the chapters of the book, I try to walk readers through the problems of simpler approaches as well as I can, but it's a continuing challenge.
Please continue to do so. I'm sure the praise you get for your book is well deserved, and part of the reason is your approach to teaching the patterns.
> There really is no substitute for experience.
Agreed. And part of the teaching style I'm advocating for is making the learner "earn" the skill by showing them the way, not the destination.
Reminds me of high school ceramics were we would have to grab two pieces of plexiglass and place our clay in between and use a pin roller to flatten our clay. If you wanted thinner sheets of clay you would continue the process with thinner pieces of plexiglass.
What we didn't know was that there was a slab roller sitting next to us all along that the teacher hadn't mentioned during the start of the course.
Through natural progression of working on "advanced" projects, we were then introduced to the slab roller as it cut time to focus on the new techniques we were learning.
The teacher essentially did that for the remainder of the course and the ones that stayed behind to learn a bit more were able to use the shortcuts before the others because they were progressing on their off time.
I also experienced that the most intuitive way of learning things, is to follow the natural evolution that led to it.
For example, you can teach people programming with higher level languages. But if your goal is to fully understand programming (as a professional programmer), you can start with the oldest discoveries and work your way into more recent years. That way you are able to grasp the full scope, know benefits and drawbacks, etc. You are also less likely to make the same mistakes of the past.
This is a great point. Kind of off-topic now; do you know of any books that take such an approach? The subject doesn’t matter, as I’m more concerned with the pedagogy in this case.
The one that springs to mind for me is Functional Programming in Scala.
Joe Armstrong does this in Programming Erlang: Software for a Concurrent World. Its extremely effective, and pulled me through each chapter by forcing me to continually look at how the solution could be improved.
For a great example of this, I'd recommend reading The Inner Game of Tennis by Tim Gallwey (or watching the lecture if you can get your hands on it).
It's essentially taking a coaching mentality towards your writing, letting the reader take the steps themselves to feel confident in it, and then only afterwards telling them what they are actually doing (e.g. in that context, properly serving).
It's a fantastic process and the book, of course, explains how it works in the context of teaching tennis.
