Saturday, January 14, 2012

Introduction

Hello all.  This blog aims to share some of the more interesting things I've run in to with programming while also upholding the ideal of keeping things simple.  I'm in the game / simulation programming side of things so performance critical code is the norm for me.  I am not claiming to be an expert by any means, so feel free to correct/debate me at will.  One of the primary purposes is to push myself to look more closely/dig deeper to get a better understanding of what code is actually doing. Expect lots of disassembly, lots of preaching, and other random stuff.

Over the years, I've done all kinds of programming from good old QBASIC to Stackless Python, Java, and pure embedded assembly written for an 8 bit processor. My heart has always been in game programming though, so C++ will be what is generally seen here.  Sure, you can write games in Flash, Ruby On Rails, etc, and it may be great, but pretty much every major title for PC, XBOX, PS3 in the past 10 years have been based on C or C++, and there is a good reason for that.  

If I actually put time into this, and anyone actually reads it, I will try to have a few themes/subjects to hit on regularly. 

Simplicity vs Complexity:
If you can make it simpler, do so.  There are many times problems are complicated and require complicated solutions, but strive for simplicity when possible.  Also keep in mind that not all programmers are as brilliant as you, so when a junior programmer is tasked with adding some new functionality to your clever, complicated solution and turns it in to a pile of crap, you share some of the blame.  

Assumed Optimizations:
Many times I have heard, and assumed myself "oh, the compiler will optimize that", generally with a hint of hopefulness and apprehension. Many times the coder is right, but there are many times where things such as the C++ standard, logic and reason, or silly assumptions prevent this from happening.

OOP for OOPs sake:
Modularity does not equal Object Oriented! Applying a nice set of interfaces and class structures for something that really doesn't need it is wasteful and annoying.  There are many issues with OOP, and unfortunately its taught to students as if it is the only real way to program.  OOP is a way to make it easier on the programmer, NOT the processor.  See Data Oriented Design for more processor friendly methods.

This blog is called the Simpleton Programmer for a few reasons.  Primarily, its so that if I'm wrong about something, I have a good excuse in that I've already called myself a moron up front.  Secondly, I prefer the simple solution in almost all cases. Thirdly, the simple solution can often be the fastest, most portable, most threadsafe, and most scalable solution.  Knowing how to simplify is not always easy, and in many cases the simple solution is just garbage. Lastly, some of the topics will be in depth looks at some very "simple" code.

No comments:

Post a Comment