Growl
Ok, first of all there are some serious misconceptions about programming from A) those who never have or B) those who didn't live through the various eras.
I've been programming for 32 years now. My first program was written on a 1962 IBM 1130 that was 15 years old when I made my first feeble attempts to teach a machine.
When you have 8k of core memory, a card reader and a damn typewriter-style user input/output device, you learn efficiency. So I know how to write efficient code. Efficient for the *machine*, that is.
Not so efficient for the *user*, of course. Or the programmers who have to follow you later on and make changes to your oh-so-efficient program.
And I stayed in the game through the structured programming wars. And the object-oriented wars. And watched each and every fad that's come and gone since then.
Not one of the people complaining about bloat knows what that means. They *think* it means the program takes up too much room, runs too slowly, or has "useless" features.
Not true.
I will admit there are some programs that truly are bloated. But not the ones most people consider. In fact bloated code tends to die quickly.
There are always tradeoffs in programming. What is simple efficient code for the machine is complex and hard to use for the user. The user demands a GUI? Fine. The GUI code is 10 times the size of the program underneath--and that's not bloat.
The GUI is too slow? It takes up 60% of the available resources? (Disk, RAM, CPU?) Tough. Could it be made more efficient? Perhaps, but at what cost?
1) Money. Got gobs, next?
2) A huge problem domain--GUIs are big because they *have* to be big. OK, got gobs of programmers because of gobs of money. Next?
3) Maintainability. Not only is the problem domain huge, it's *complicated*. It takes real expertise to write simple, elegant code that avoids obfuscation. Ok, hire *GREAT* programmers with said gobs of money. Next?
4) Maintainability and code efficiency more often than not are mutually exclusive. Increasing one *decreases* the other. Ok, got gobs of--wait, what?
Like any engineering problem software engineering is a study in trade offs. The old saw about "Good, fast, cheap, pick any two." is dead right.
So your program has to be:
1) Machine efficient
2) Easily maintained
3) Affordable
4) Fit to purpose--for a widely diverse audience that can't agree on which features are useful and which are not.
5) Easy to use--ideally with NO training of the user.
6) Income generating so you'll be around in 3 years to keep doing what you're doing.
Name *ONE* program in the history of the world that meets all 6 of those criteria. Just one. Oh, and a choice everybody agrees with...