Time and time again this topic is brought up. The basic concept that is usually dredged up is that programming in Assembly results in programs that are faster than if the program was written in another language. The logic then goes that, since the goal of programming is to give the best user experience, and since a fast program is a pinnacle part of that user experience, that all programs should be written in assembly, and anything else is a waste of time.

It does have some interesting points. However I think it fails to take into consideration a few key facts. First, If you write a program in Assembly language, it doesn’t make it automatically faster. Even an experienced Assembly Programmer can be “defeated” in this manner by a Compiler in the manner of Optimizations; the only time a experienced Assembly Programmer can best a compiler is for very small, performance critical code.

Now that said, is there an ideal case to explore? is it possible to write, say, a Word Processor, using pure 100% Assembly? Yes. is it Possible to write that Word Processor using 100%, fast as possible fastest algorithms written by the best Assembly Programmers in the world using the most advanced Assembly Programming techniques? Yes.

So what is stopping us?

Time. Time heals all wounds, but it’s also necessary to write all programs. Microsoft Word and many of it’s early competitors(WordPerfect, PC-Write, etc) were all Written in C. WordStar- which was already on the market- was written in Assembly language. So what happened? Well, first, Because Wordstar was written in Assembly, it was instantly more difficult to maintain than the competitors, and also harder to add features too; it would take a grizzled, experienced Assembly programmer several years of hard time and experience working with Assembly to become as effective at maintenance and feature additions as an Intermediate C Programmer. Additionally, the attempts by those behind Wordstar to make it as portable and maintainable as possible caused them to lose their lead to WordPerfect; While WordStar developers spent time rewriting Wordstar or making major changes to run on different platforms, WordPerfect could practically recompile and get it working on those other platforms; so in that time, they could make changes, add features, and basically used that to grind WordStar into the dust- a forgotten product. Basically, writing anything in Assembly takes more time than the same thing in another language. This is both because there is more mental baggage for the programmer to remember and keep track of, but often even if you knew exactly what you had to type/write, writing the Assembly version could take twice as long simply because there might be twice as much code (and let’s be honest here, twice as much is a conservative estimate).

It’s unnecessary. if you have a product written in Assembly, that is hardly a selling point in and of itself. Customers don’t really care what language your program is written in, as long as it works. It doesn’t matter if you spent 3 months fine-tuning your Assembly approach to sorting a spreadsheet to be a full three seconds faster with the same data as the leading competitor if your product is missing some other feature that the customer needs.

The approach early on (when Wordstar start up) was basically that you needed to write Assembly to get things working well on the hardware of the time. Over time, Compilers got better- Early compilers compiled code terrible and had very few good optimizations, if any. As time went on, the compiler writers- who are, by definition, experienced in Assembly- added in various optimizations. Eventually, writing a program in C became feasible. Even so, many Assembly programmers refused to acknowledge this. Early versions of Windows had significant portions written in Assembly; the first version was written entirely in Assembly, if I recall correctly. Over time, however, portions of the codebase were switched to C. Why? Because they no longer needed to be in Assembly; the maintenance costs of keeping them in assembly outweighed the nearly imperceptible speed improvements over a C equivalent, and having more of the codebase in C streamlined the build process. Some might argue that this inexhorable switchover to C from Assembly contributes to each version of Windows being “slower” But that is not the case. The reason each version of Windows appears “slower” than the last is more that is is designed to run on modern machines, and take advantage of the features of modern machines. This means that the OS designed for yesteryears machine is going to run faster on yesteryears machine than a newer OS, by and large. Most of the C versions were not perceptibly slower than their Assembly counterparts. At any rate, the feature additions in each new version would be more likely to make things “slower”; Windows 95, for example, was slower than Windows 3.1 on equally configured machines simply by virtue of Windows 95 having a more “protected” environment; Pre-emptive multi-tasking subsystems, even those as relatively primitive as those introduced in Windows 95, take their toll. Windows NT 3.1, which looked similar to Windows 3.1, had requirements not unlike Windows 95, and it was a fully pre-emptive, protected memory environment system.

There is something infuriating about the idea that we should be chasing this ideal of a Program- or entire Software ecosystem- written entirely in Assembly that is fully optimized, and given the lala-land nature of the dream, I can only surmise that the Assembly is self-fixing and contains zero bugs. I think the infuriating part is that it manages to suggest the impractical while also trivializing everything that I do. I mean, is it possible to write a entire program in perfectly optimized Assembly? Yes. But it’s not practical for any number of reasons. One analogy I use is that, well, consider the perfect Car analogy all to often used with Software.

Surely, Cars would provide a better roll-cage to protect individuals if they were made out of tungsten. Tungsten is the strongest metal- just as Assembly is the “fastest” language. But we see this analogy goes further. You see, Tungsten is also quite expensive in processing time as well as machining. There are also innumerable issues including it’s heavier weight (which could correspond to the fact that Assembly language will always be longer than another language by definition).

And the end result? When you look at a car made with stainless steel, and one made with Tungsten, a person is going to go for the one that is cheaper, and if the cheaper one also has seat warmers, well, damn- why would they want the other one?