Yesterday, I wrote about The Future of Cars According to (Disney in) 1958. This reminded me of a conversation I had, about two decades ago, when I was a freshman in college. One of my majors was computer science (at the time I was tripple-majoring in Math, Computer Science, and Philosophy) and I was speaking with a senior who was also a computer science major. We were discussing Windows versus Linux. I can’t recall exactly how it came up, but he said, very confidently, that in 10 years neither Linux nor Windows would exist any more, both having been replaced by something completely new.

Twenty years later, both Windows and Linux are going strong, though the writing is on the wall for windows and it is gaining ever-more Linux-like features. (Including, recently, a way to easily install Linux within a virtual machine.) Which brings me to the title of this post—the future is notoriously difficult to predict. And I’d like to consider a few of the things which people tend to get wrong.

Adaptation

For some reason, people tend to think of current companies, products, etc. as either completely changing or completely static. Which really amounts to the same thing—the idea that whatever comes next will be completely new. And yet, this is rarely the case. Not never, of course, but rarely.

What prognosticators tend to leave out, here, is the market forces which operate on technology. Most people don’t like completely new interfaces; that means a lot of learning for marginal benefit. Far preferable are modifications to existing tools, so that the amount of learning requires is in proportion to the benefit received. An extra button or two is a small price to pay for new capabilities; having to learn all-new muscle memories for mostly old capabilities and some new ones is a price which is usually too large.

In many cases there is also the issue of interoperability. Computers benefit tremendously from backwards compatibility, but so do tools. A drill which cannot take normal drill bits renders one existing collection of drill bits worthless. Or worse, drill bits which can’t be chucked into one’s drill collection renders one’s drill collection worthless—and one generally as more money in the drills than in the bits.

These are powerful forces which tend to make new technology look and feel like old technology wherever possible.

And of course, people don’t like going out of business. Those who already have tools are motivated to improve them in order to stave off replacements—and this often works.

Technology Changes, Human Beings Don’t

Another place where prognosticators often fall down is that the human beings who are served by technology don’t change. We still have two eyes, two hands, are social, need to eat and sleep, etc.

So for example people look at the steering wheel, see that it’s been around for a long time, and think “that’s due for a change!” What they don’t consider is the problem at hand: we need a control interface to a car which translates fairly large movements into fairly small movements (for precision) while still allowing large movements, but where large movements are impossible to do by accident. This interface needs to control one dimension (left-to-right), should be usable for long periods of time without fatigue, and should be operable without looking at it. The steering wheel does all these things and does them well. Joysticks, nobs, and other such video-game replacements do at least one of these things poorly. It is of course possible that other sorts of interface will be made that can do the job just as well, but how much better is it possible to do the job, given the limitations of human physiology?

There’s a related example in 3D movies. Some people take 3D as the next obvious step, since silent movies to talkies went well and black-and-white to color went well and low-definition to high-definition went well. But what they miss is that all of these things made movies more realistic. Stereoscopic 3D information gives us distance information—and for typical movies these distances are almost always wrong for our viewing. Granted, they would probably be about right for The Secret of Nimh (which is about mice) in a 50″ TV about 10′ away—if the director would refrain from close-up shots. If you watch a movie, you will realize that there is almost no configuration of movie shots and TV size/location that will make the distance information to the characters correct for the viewer. Worse, if it were, instead of an immersive world of photographs, you’d have a window you’re looking through onto a stage play. The Nintendo 3DS had this problem, with its tiny screen—looking at it one had the feeling of watching a tiny animated diorama. It was novel, but not really interesting. The problems here are that the human being is simply not being taken into account.

Which is why, incidentally, the filming of 3D movies using two cameras at approximately eye-distance apart has all but been abandoned. Instead, 3D is (essentially) painted into a scene in post-processing by artists, who artistically fake the 3D to make it look good when viewed. I’m told that this can really help with scenes that are very dark, making it possible to distinguish dark grey blurs from a black background. This is adapting the technology to the realities of the human being, which is why it’s actually successful. But it’s also quite expensive to do, which greatly limits the appeal to viewers since it translates into much higher ticket prices.

Better Implementation Often Trumps A Better Idea

This is one of the more under-appreciated aspects of technological change. A mediocre idea implemented well is often superior to a good idea implemented in a mediocre way. I’m not just referring to actual fabrication; ideas for technology are themselves developed. Mediocre ideas which are developed well can produce better results than good ideas which are not much developed.

Perhaps the best example of this I can think of is the x86 processor. It has what is called a Complex Instruction Set. This is in contrast to the ARM processor which has a Reduced Instruction Set. (These give rise to the acronyms CISC and RISC.) The x86 processor was developed during the days when CISC was popular because computer programs were largely hand-coded in machine instructions. The complex instruction sets saved the programmers a lot of time. The trade-off was that it took far more silicon to implement all of the instructions, and this resulted in slower CPUs. After the advent of higher level languages and compilers, the idea of RISC was born—since a program was generating the machine instructions anyway, who cares how hard a time it had? The trade-off was that the compiler might have to do more work, but the resulting CPU used far less silicon and could be much faster (or cheaper, or both). In the modern environment of all programs being compiled, RISC is clearly the better approach to computing. And yet.

Because Intel CPUs were popular, Intel had a ton of money to throw at the engineering of their chips. AMD, who also manufactured x86 processors, did too. So RISC processors were only a little faster and actually significantly more expensive. And then something interesting happened—Intel and AMD figured out how to make processors such that they didn’t need nearly so much silicon to implement the complex instruction set they had. In effect what they did was to introduce a translation layer that would translate the complex instruction set into a series of “microcode” instructions—basically, internal RISC instructions. So now, with x86 processors being interally RISC machines, the penalty paid for supporting a RISC instruction set is an inexpensive translation layer in hardware—a pentalty which generally isn’t paid unless the complex instructions are actually used, too. And compilers generally don’t bother with most of the complex instructions.

The result is that ARM processors have a small advantage in not having to do translation of opcodes to an internal microcode, but this usually takes only 1 step out of the 12 execution steps in an x86 pipeline anyway. And Ahmdal’s law should always be born in mind—the maximum improvement an optimization can produce is the total execution time of the process being optimized. That is, eliminating 1 step out of 12 can produce at most a 1/12th improvement.

But then modern Intel and AMD CPUs also do something interesting—they cache the results of decoding instructions into microcode. So this decode penalty is only paid for code that isn’t executed very often anyway. The most performance-critical code—tight loops—don’t pay the decode penalty. As I said, a better implementation often trumps a better idea.

(People familiar with x86 versus ARM may point to the difference in performance on mobile phones, but this is really about what the respective CPUs were designed for. x86 processors are designed for achieving the maximum efficiency possibly at high power draws, while ARM CPUs are designed to achieve the maximum efficiency at low power draws. ARM CPUs are therefore better in very low power draw environments but simply cannot be scaled up to high power draw environments. There is no power configuration possible in which an ARM processor will come close to the single-threaded performance of an x86 processor. The tradeoff they make for the low-power efficiency is that they cannot be scaled up. This has nothing to do with technical superiority of either x86 or ARM processors, but the fact that they’re designed for extremely different workloads and environments. The thing which Intel and AMD need to be careful about is that the amount of processing power which they can provide at 15W, 35W, or even 60W may simply be far more than is necessary in a laptop (since the tasks which laptops are asked to do is becoming more standardized as the development of software slows down), at which point ARM might eat their lunch not because of technical superiority but because of its capabilities becoming a better match for a changing problem-space.)