I might argue that this has less to do with programming language selection, and more to do with hardware. Or at least, that hardware was the catalyst for this back in the day. All I know, is that in my lifetime, the biggest inflection point I've seen was when hard disks became "large" (relative to the size of programs) and cheap/viable.
No doubt that this is a major contributing factor but it's not really a justification for sloppy coding. Now that data storage is bountiful, we can use this space but how we use it really determines the general direction programs go.
My point is that most of the day to day programs we use do not need to be as large as they are to provide the functionality they provide. I love to point out uTorrent as an example of a modern program coded efficiently and intelligently. It provides all of the functionality of a more bloated program like Azureus (done in java) and yet its one executable file about 800KB in size, while Azureus is bloated pig by comparison.
If there is a reason to use the extra space, use it...but filling it up simply because it is there is still a bad practice.
Since space is cheap, as you point out, most people are willing to live with this.
An anecdotal data point: compiling my current work-in-progress (an OS kernel) with -O2 instead of -O0 adds about 200kbytes to the final size.
I have nothing against increasing the size of a program IF it provides tangible benefits...but the linux kernel is what, about 25 MB? An increase in size of 200KB is less than 1%...if it provides more than 1% increase in performance then wouldn't it be a worthwhile tradeoff? On the otherhand, if said "optimization" caused the file to grow by 50% it wouldn't be such a great deal.
I'm sorry man, but that's just wrong. Not having to manage memory manually makes you lazy? The system I'm currently working on consists of a Silverlight front end with about 350 classes and 200 controls in it, a web services tier with over 150 endpoints, two SQL server databases, a content repository with 8 terabytes of digital music files, and a data transformation layer that moves around 10 GB/day to/from various partners, most of it transformed in one way or another as it passes our door. It's all written in C#, none of it is simple, and none of the people who work on it are lazy. Not one single aspect of this system would be made better in any meaningful way by writing it in an unmanaged language, and yet I guess according to you we should do that, and expand the investment in the project from 6 man years to 8-10 man years.
That is a seriously flawed view of our business. I'm inclined to short the stock of any company you work for.
That which you described above is all well and good, but if you had the right team of coders doing the same thing in C or C++ you could probably get the same level of performance on less hardware.
A real-world example of a game-changer due to efficient coding is the Qmail MTA (SMTP Server). Before Qmail most hosts were using sendmail to process and receive email between servers. Sendmail was a clunky, buggy and inefficient MTA that did its job slowly and ate resources like they were made from bacon.
Along came the somewhat eccentric DJ Bernstein who gave us Qmail, and suddenly a mail server struggling to do 100,000 messages per hour at 20+ load could doe 1,000,000 per hour and the load dropped below 5. He also made tinyDNS which trumps BIND in performance and security, but due to it being user-unfriendly it never really caught on. What I found very amusing is the BIND developers trying to play-down tinyDNS because it lacked features like DNSSEC, which it does not need, because unlike BIND it never had the security holes that allowed for cache poisoning or DoS attacks. So yeah, just because BIND is the most widely deployed DNS server does not make it the best...although Qmail is still the most widely used MTA hands down.
So we can liken your above example of using C# to Sendmail, and mine is obviously C/C++ => Qmail. You come off as being very complacent, like you are sold on the whole idea of C# being "good enough" whereas my idea is "how can we make this better/faster/more efficient".
Facebook
Twitter