I agree with the author in that Learning Assembly Language Is Still a Good Idea. However, I disagree that it's a good idea to be writing almost anything in assembly language, unless you're writing device drivers or operating system kernels. We'll start with the benefits. It's important to understand how the machine works; it gives you better insight into the system. It will help you understand how to use libraries and abstractions; what code they generate and the effect of your choices on performance will be. Programmers who understand the abstractions they are using are better programmers, period. The best programmers I think understand them all (all the way down to hardware, at least in some sense; all the way down to the wire when writing network programs, etc.).
However, I'm not clear on when it would ever be a good idea in most circumstances to actually write assembly code in a production project because it's
The level of optimization that assembly provides is just not appropriate for most software projects. It doesn't really matter how fast your "fooBar" routine is if someone calls it like this: fooBar(new BigGiantObject()) in a loop 10,000 times, where BigGiantObject() has an expensive constructor. Knowing assembly will help you understand why this is a bad idea, which is good, but writing it in assembly will not make it much faster. You want to take advantage of the fabulous abstractions that exist today. Assembly language disallows that. Yes, you can call those libraries, but then you're just writing the glue code in assembly, which isn't going to buy you much performance. Plus maintenance programmers will shake their head at what you've done, and probably throw it out anyway as long as they can.
So knowing assembly language helps you write faster, better code. Just don't write it. Given all things equal between 2 programmers, I'd hire the one that knows assembly, unless he/she wrote assembly code in their interview.
Libraries and high level constructs are not crutches of inadequate programmers, they are abstractions, and abstractions are at the core of what we do, so problems can be simplified enough to solve.
As a final example, one of the comments on the artice (search for OCR) has an example. I highly doubt that the time and effort spent micro-optimizing assembly code was better for the business than just upgrading the PC's. The cost was probably about the same, if not less to upgrade. Not to mention, assembler was probably not necessary. I bet by rewriting the same sections in c++ or c using similar techniques would have provided very close to the speed benefit. I'm sure it was a fun excercise, but it probably was not the most appropriate thing from the point of view of the business. I think dropping into assembly language rarely is.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site
or contact me at rob at big dis dot com.
See my writings on: