"They stem from:
1. Reality. Programmers don't get to set deadlines and decide whether a software is in a state to be released or not. Managers do. And as a rule of thumb, the latter does not listen to the former."
Not all the time. It just depends on your manager. For instance, my manager listens to me. I actually program in assembly for a living, and I have no problems meeting my deadline. The source code we have runs in the 10MB-11MB range. I have no problems updating and maintaining that code.
"2. Poor/ lousy/ (add your negative adjective here) programming. If you can write a 1MB+ bloatware in C, Pascal, (add your language here), etc., chances are you will do so in assembly too (or maybe you won't be able to get it working at all). The "bloat" part of the software is not added by the compiler, it's added by the programmer. Same for bugs."
Well anyone can be stupid and write bloatware. What the assembler programmers are saying is that if you really want to make your code run fast and efficient, knowing how the processor works can really help you write effective code. That doesn't necessarily mean you have to write in assembler to learn that. However, after learning assembler I write faster C code now, because I really understand how the processor works and what C commands get turned into what assembler commands. So it really lets me take advantage of that. For instance did you know that on the P4 shifts are slow? So using shifts in C or any other language is slow. So if I know my program is going to be running on P4's I try and avoid shifts in the code if possible. C<<4.
"Assembly language has such a bad rep not because people are lazy or ignorant, but because it's not efficient to the *programmer*. No amount of advances can make it as easy to code and maintain as a higher-level language. C (or C++) is often considered to be the lower limit, because at this level, it maintains "human readability" even in large projects and yet I can be reasonably sure that the compiler will do a good job if I write my code properly. Why learn assembly if I can spend half the time and effort in C and the compiler can then do a better job than if I had written in assembly? OK, so even the best compilers have their blind spots but overall they shouldn't be worse than the average programmer in churning out code. (BTW, I used to learn assembly, and have learnt quite a bit about optimizing assembly code by playing around with compilers.)"
I already answered this above. We maintain our project which is is 10-11MB of assembler code. It is easy to maintain and add new features. The code is well documented, and we have several levels of quality control that we use. Second, assemblers are now starting to be more C like. Check out the masm32 project or the GoAsm project ( you can do a search on the web for either). It is closer to programming in C. Third, there are a lot of tricks you learn about optimizing in assembler. I used to write slower assembler code than what the C compiler could generate. Now, I have yet to see a compiler generate faster code than I can in assembler. Also you made the comment about large projects being hard to speed up 2-3x. I also disagree with that. Profiling your code is important. I like to download open source projects on the net and speed them up using assembler. The last one I downloaded and sped up, I got a 10x increase in speed over their C implementation. And he was saying that MS Word is just an example of bloatware/poor programming. Writing a super fast MS Word isn't the point he was making. He was saying it should have been done in a more efficient manner.