The progress moves forward in multiple ways. Generally, things like power, memory, bandwidth etc. get cheaper due to the more refined production technologies, but they all do this at different rates. In order to take a proper trade-off decision you should consider not just the price at the moment, but the proportion of prices and their dynamics. There’s not much sense in buying power-efficient lamps, when you have a nuclear plant being assembled in your back yard. This is not a metaphor. This is what my bachelor’s thesis was about. I wrote a program, that did discounted cash flow analysis for illumination. You could select a type of light bulb, specify the installation, replacement and utilization fees, as well as actual and expected power prices, and then it would calculate the present value of the whole investment for you. I played a bit with the data I had and found out that, given Ukrainian power prices at the time, simple incandescent light bulbs were the most cost-effective. They do waste a whole lot of electricity, but electricity was cheap, the light bulbs were cheap, and maintenance was also cheap. Everything was cheap. Of course, the proportion was going to change some day, but at the moment sticking to a hundred years old technology was the right thing to do. About that program though. I wrote the whole thing in assembly. The reasoning for that was just as simple. My own per-hour rate at the time multiplied by couple months of effort was much lower than the value of the skills obtained in the process. In a couple of years, while working on my PhD, I had a job at a small casual game studio. I had the courtesy of working alone on the core code and my design was absolutely barbaric indeed. I never used dynamic allocation because, as I figured out, there is no need in saving some kilobytes of game-play data since a single background picture takes 3 megabytes uncompressed. So I simply allocated all the data I wanted statically in decently sized pools. This eliminated the whole class of programming problems at the cost of memory overconsumption that wasn’t yet even comparable to the size of assets loaded. We had a DSL that had never advanced from the simple interpreter stage. We would do better performance wise with byte-code translation being there, but I measured the lexer overhead and it was about a couple percent of the whole thing. But keeping it very simple, very primitive, we achieved respectful flexibility. Adding features was a matter of extending one huge battery. All at the cost of a performance decrease no one really cares about. if-else Of course, it was only possible because we targeted desktop PCs, and their hardware was way over-powerful for the types of games we made. It was a special market, a special place in space and time, where it paid off to be primitive. But that’s how the economy works —some things get cheaper faster than others, causing disproportions. You can get a competitive advantage by exploiting some disproportion even if it means abstaining from some fruits of progress. It’s just important to realize, that no disproportion is going to last forever. The progress might move forward in different ways, but tends to keep one direction.
