"Nobody programs in machine language" (was: Modern

It was thus said that the Great Fred Cisin once stated: I would expect that an expert driver would need to have an understanding of how the engine relates to the rest of the car, in addition to understanding how the transmission and breaks relate. Yes, understanding how the car works overall helps, but the ability to rebuild an engine? I have to be sold on that one ... In 1992 when Doom came out, it only had two (2) routines hand coded in assembler---the rest was in C. Algorithmic optimizations, which is where you now get the most benefit. An extreme example would be replacing a bubble sort with quick sort (for a sufficient amount of items to be sorted). I remember several years ago working on a project (in C) that wasn't as fast as the previous implementation (also in C). Instead of reaching for assembly (which I could have done) I instead profiled the program---finding out which parts of the program where the actual hot spots instead of my guessing where the hot spots were. I basically converted seven small routines into macros (inline the code, instead of having a function call overhead) and easily doubled the speed, bringing it into line with the previous implementation (which had fewer features by the way). Was I helped with my knowledge of assembly? Possibly in writing the intial code. With the optimization (for speed)? I don't think so. Do I regret learning assembly? Not at all, I think it made me a better programmer, but that's me. I think the reason assembly isn't taught anymore is that industry (or academia) don't see it worth the time and effort to. Right now, the most expensive component in programming is the programmer, and anything to make the programmer more productive is seen as a good thing, and the one thing that makes a programmer productive is working with higher and higher level languages. Another example. A project (play project really) I worked on I started with Perl (one to learn the language). Text munging language and it took perhaps eight hours total to get it to the point I like it. But its sluggish on my development system (166MHz AMD 486). I then spent perhaps twice the time (16 hours, maybe 20) rewriting it in C (because I can). Vast improvement in speed---two, three orders of magnitude but part of that comes in Unix systems programming, and using a trick or two (like mapping a file directly into memory instead of reading each line, for one thing). But ... my programming expertise isn't exactly cheap and in a company setting, unless there were extenuating circumstances, the Perl version would be fast enough on modern hardware (where on modern hardware, it's the hardware itself that gives the two, three orders of magnitude). And the money paid me to write it in C can instead be put towards faster hardware. I would contend that it's cheaper to buy the faster hardware than to keep me on staff (or rather, it's more cost effective to have me doing other things than translating Perl into C). And now a days, who can afford to have a C programmer on staff? A friend of mine works at Sportsline (2nd only to ESPN for sports related news on the web). They have a Perl program to generate stats from the web server logs and to process a single day it takes nearly 22 hours. Sure, they could hire a programmer to rewrite their log processor in C and (depending upon the programmer and the complexity of the processing) reduce the runtime of the program. But then they have to keep someone around that knows C (or C++ or ... ) and that's an expense they probably don't want to incure. Perl programmers are cheaper, as is hardware. Trade-offs. Right now, the optimization being done is developer time and expertise. Faster with less skilled programmers. Or in other words: Good. Fast. Cheap. Pick two. -spc ("Premature optimzation is the root of all evil." ---Donald Knuth)