I'm James Hague, a recovering programmer who has been designing video games since the 1980s. This is Why You Spent All that Time Learning to Program and The Pure Tech Side is the Dark Side are good places to start.
Where are the comments?
Life is More Than a Series of Cache Misses
I don't know what to make of the continual stream of people in 2015 with fixations on low-level performance and control. I mean the people who deride the cache-obliviousness of linked lists, write-off languages that aren't near the top of the benchmark table, and who rant about the hopelessness of garbage collection. They're right in some ways. And they're wrong at the same time.
Yes, you can do a detailed analysis of linked list traversal and realize "Hey! Looping over an array is much faster!" It is not news to anyone that different languages have different performance characteristics. Garbage collection is a little trickier, because unfortunately there are still issues depending on the situation, and not all that rarely either.
I could take a little Erlang or Scheme program and put on a show, publicly tearing it to pieces, analyzing the inefficiencies from dynamic typing and immutability and virtual machines. There would be foot stomping and cheering and everyone would leave convinced that we've been fooling ourselves and that the only way to write code is to frame problems in terms of cache architectures.
And then I'd reveal that the massively inefficient Erlang program takes only a couple of milliseconds to run.
Back in the 1990s I decided to modernize my skills, because my experience was heavily skewed toward low-level C and assembly work. I went through tutorials for a number of modern languages before settling on Erlang. While learning, I wrote programs for problems I did in college. Things like tree manipulation, binary search--the classics. And while I remember these being messy in C and Pascal, writing them in Erlang was fun. I'm not giving up that fun if I can help it. Fun is more productive. Fun leads to a better understanding of the problem domain. And that leads to fast code, even if it might be orders of magnitude away from optimal when viewed through a microscope.
There is an exception to all of this. Imagine you're an expert in building a very specific type of application. You've shipped five of them so you've got a map of all the sinkholes and poorly lit places. There's a chance, maybe, depending on your background, that your knowledge transcends the capabilities provided by higher level programming languages, and you can easily crystallize a simple, static architecture in C.
But until I'm that expert, I'll take the fun.