“Back in my time,” you hear the old, or frequently not-so-old, engineer, remark, “we did not need these newfangled high-level languages. We wrote it ourselves, in C. If we keep using C, instead of these memory hogs,” he (it’s usually a him) goes further to maintain, “our applications will run at blistering speeds on these new CPUs and bigger memories everyone have. We will be a miracle in our own time.”
Tempting, isn’t it? Just do things the good ol’ ways and what was once an application that could barely be run at all will now be, in modern terms, an itty bitty implementation which does not take any resources. Why not do it? Why should we expand to fill all available resources? Is Bill Gates actually sitting up in his manor, the way many imagine him, and cackles with glee as he says “consume more resources! let’s put out .NET, and add a malloc(2GB) right in the initialization code, just for one. Our friends at intel will be grateful forever.” If so, why is the open source world going along with it, moving in droves to Python, Ruby and PHP, and using “memory hogs” like compiz and GNOME? Are they so blinded by the will to be “just like Microsoft” that they copy the mistakes, too?
Perhaps not. Perhaps there is an actual reason for programs to expand. Maybe not all modern programmers are lazy bastards who are not willing to work as hard as their ancestors.
So, here’s a list of answers to the “uphill, both ways” argument:
- Some programmers can’t write in C. Perhaps a few years ago, they wouldn’t be able to be programmers at all. Now, with the expanding need for programmers, maybe they are able to do a mindless “programming” job (VB front-ends to Access or RoR interfaces to MySQL) that is actually useful to someone. Less people unemployed, more people contributing to society.
- Writing in C takes too long. If a competitor uses some language in which it is faster to bring something to market than C, he’ll win by default. This applies, of course, to classical commercial applications as well as to open-source applications (which depend on development mindshare to succeed).
- Writing in C is too buggy. People, all things about the same, prefer to use a program which crashes less, and when it crashes, does so in clean understandable ways which are recoverable. Using something other than C makes these easier.
- People *want* the program to *take resources* and *give them something useful in return, like features they did not have back when all programmers had to walk uphill both ways. They bought the new CPU and memory because they expected to accomplish more. If showing more data, auto-calculating things and rendering more accurately takes more resources, a user will be happy to “waste” his resources on these.
This is not to say C, C++ or even assembly no longer have their place. Of course they do. Sometimes using C is the only choice that makes sense, sometimes it is just better than alternatives. But the mere mention that “we used to write this in C a few years ago, and it worked fine” should not be an argument. If you’re not willing to use the best tools for the job, you can bet that someone else is, and all other things being equal, they are going to create something which is better and more popular than you — and they don’t give a rat’s tushy that a few years ago, using Python in this place was not practical. It is now…
Moshe'z 
I think your article is beautiful and well-written. What I think above all is that programmers should still be using best algorithms and best practices even though the language they use may not be the “best”. We might have hardware to waste, but that doesn’t mean that we should be using less efficient algorithms.
I disagree. It absolutely means we should be using less efficient algorithm if they have no discernible impact on the user and they result in cleaner, simpler code or a more modular architecture.
It is the first time I’ve heard a real live person say what you just said.
Even if there is no discernible impact on the user, one implementation may take orders of magnitude of time more than another implementation. Doesn’t anyone care about using less energy anymore? Especially now that oil is running out? I hope that our politicians and doctors and lawyers and other scientists don’t have the same outlook as you regarding efficiency. It seems that we have become a victim of our own success at improving hardware.
I am all for cleaner code and a more modular architecture, but I doubt that if competent persons were doing the implementation, a change of algorithm would make the architecture any less modular or the code less clean. Complexity of code has nothing to do with how modular the architecture is or how clean the code is. Code thousands of lines long can still be clean and modular.
So the deciding factor IMO, would be the simplicity of the code. I certainly agree that better algorithms usually cause more complex code. I think programmers should be trained professionals and behave as such. If a programmer was worth his salary he should be able to implement any sort of algorithm without needing the resulting code to be simple. Is it that you want any newbie to be able to understand and write the code which will run our banks and weapons? I certainly would not want that. It is probably a philosophy like yours that has caused our modern software to be so buggy and vulnerable to exploit. An untrained programmer simply does not have the capacity to write proper code and we shouldn’t be trying to make it easier for them to try. You don’t see many untrained people handling things which are dangerous to them (like poison, electricity, power tools, etc.), but they do programming since they can get away with it if they mess up. I absolutely abhor that concept.
I guess that in the end you will win, since it is capitalism which (unfortunately) drives this world. Time to market is more important than the quality of the final product so your philosophy would be used. More and more I guess there will be no place for people like me who strive for efficiency and conservation of resources (whether it be computer hardware, or oil and food for our children). As long as we are happy with our programmers being less and less intelligent, then we will continue to live at the mercy of crackers and other black hat individuals. The governments of the world will intervene eventually, but maybe only after a poor implementation costs lives.
Vincent.
Oh, really?
In my world, “acting as a professional” means “acting in my company’s best interest”. This means I absolutely should make sure that my code is as easy to understand as possible. I find it impressive that you managed to argue that obfuscated code is more secure, but in my world, easy to understand code is more secure and more robust. You seem to have a problem that companies operate for a profit, but even open source code written by non-profits seems to exhibit the same mindset. You are frustrated that my attitude will “win”, but this is do to programmer attention being a constant cost, while costs of running software (even in the face of climbing energy costs) keep going down. It is probably more efficient to run datacenters on nuclear power or in deserts where solar energy is abundant rather than trying to change how software is written.
You say easy to understand code is more secure and robust. In its simplest form, you are proposing that this easy to understand code:
$input = $_GET[‘username’];
Is more robust and more secure than:
$input = mysql_real_escape_string($_GET[‘username’]);
That is a travesty.
I agree with all of what you say after that. My main issue is that if we can get away with using a less efficient algorithm, then so be it, but we must not use less efficient algorithms simply because we do not have the know-how or understanding to implement the more efficient ones.
I am familiar with the concept that the programmer’s time is more expensive that the CPU’s time, and one way or another we will be bound to it. I say let that decision be taken by the programmer from a strict cost saving model, rather than it being because the programmer is too dumb to do the implementation any other way.
In summary: If highly-trained and competent programmers use an inefficient algorithm to make their code simpler to understand and maintain then good for them. But if poorly-trained programmers do it because they can’t understand anything else, then that’s bad for the industry.