Hi, I'm not sure sloppy is the correct word, although I just saw this article http://news.bbc.co.uk/1/hi/technology/8261272.stm and towards the end they say:

Quote: That level of concentration on things have been lost today when you have things that are many megabytes or even gigabytes in size

Do you believe this to be true, even when considering development on consoles?

Quote: "We crafted every single byte and would work for hours just to free up three or four bytes so we could put in a new feature or ability.

"That level of concentration on things have been lost today when you have things that are many megabytes or even gigabytes in size," he added.

Go craft 4,700,372,992 bytes, one at a time, then report back here. Thx! [wink]

"Sloppy" is a loaded term, really we've just shifted priorities. When you've got gigabytes of hard drive space but a customer breathing down your neck asking for new features to be delivered yesterday, then of course you're going to choose the option that's quickest to code, usually at the expense of storage or runtime efficiency.

Similarly, when programs are small and designs are rigid then you can code a lot more directly and space efficiently. A game designed and programmed by one or two people is small enough that you can actually hold the whole program in your head at once - which means you can cut corners and do all kinds of tricks to make it more space and time efficient. But as soon as you start adding more people then those go out of the window and you've got to code in ways that may be less efficient but are more robust and maintainable. You have to work with only a subset of the whole program in your head at a time, which means you start making defensive copies, or providing limited access to certain internal data objects, so that someone else (who's working with a different subset of the whole program) doesn't end up breaking everything as soon as they change a single thing.

Every programming project has different priorities, and given current hardware it's not surprising that space and time efficiency has dropped down a notch or two in all but the most extreme of cases.

Also, it's simply unnecessary, by and large, to make such efficiency efforts. Your program is very unlikely to live or die by a saving of a few bytes or a couple of instructions here or there*. If your software sucks, it's probably going to be down to a major architectural problem rather than that time you used a full int when a short would've done.

*obvious exceptions for stuff like networking or low level programming, where these matter more.

"Encouraged" is also a loaded term. "Permitted" or "enabled" would be more accurate.

My father still gets annoyed by code that could easily be made more efficient. Of course sometimes he resorts to writing a routine in assembly even if it really won't speed things up that much.

Back when computers had a few K of memory, efficiency was more important. Today not so much. If people can get away with not putting in a lot of work making code that isn't 'sloppy' they won't.

The main issue is that software nowadays is, by and large, several orders of magnitude more complex than 1, 2 or 3 decades ago.

The more complex the software, the more counter-productive micro-optimizations become. Not only in programmer efficiency but in actual *execution* efficiency: try implementing the map-reduce algorithm in assembly. Now scale that to hundreds of thousands of systems to handle Google search.

This is directly analogous to microprocessor design. Processors are no longer designed on the transistor or logic gate level - instead, we use specialized software that builds upon higher blocks of functionality. Wasteful? Yes! But what if you waste a few hundred thousand of transistors when your budget is two billions?

Without these 'sloppy' tools, modern processors wouldn't be possible.

Without inefficient, 'sloppy' languages (PHP, Java, Python, Ruby), 'sloppy' programmers and 'sloppy' multi-gigabyte storage requirements, the modern web wouldn't be possible.

Sometimes I feel that way with PC games. A scenario: Go back 5 years and get a top-notch computer and a graphics-intensive game, so that the graphics are the bottleneck for any efficiency (they usually are anyway). The game runs great. Go to the present day and keep the same machine, which is now outdated. Install a lower-end modern game that has the same graphical ability as that 5 year old game -- it doesn't look any better. In fact, it could even look worse. I betcha that the new game will run horribly choppy on that old machine even though, in theory, it shouldn't be more intensive than the 5 year old game that runs great on the same machine.

What I think the real answer is with any two games, one is going to be programmed better than the other. I remember when I bought Half-Life 2, the game looked beautiful and ran super smoothly, while some other games released at the same time weren't as graphics intensive but ran choppy.

Cost rules everything.

It's cheaper to push out less efficient programs faster than it is to take longer making more efficient programs. It's also lots cheaper to hire a poor programmer to make an inefficient program than it is to hire and/or train a good programmer. For the vast majority of programs the hardware is such that you can be grossly inefficient (by the standards of "back in the day") without the end user caring enough to not buy your program.

Like pretty much every other debate concerning the level of quality of a product it comes down to the fact that if people would refuse to buy crap there wouldn't be so much of it. The games industry has the added bonus that rampant fanboyism will sell a ton of crap - as long as you keep the shiney front and center, give them an outlet to bitch, and keep the patches coming at a rate that keeps hope alive then they will buy.

I don't know, it seems to me that if you can find a use for those few hundred thousand transitors that were wasted or speed up a routine that's called thousands of times a second by a couple microseconds that there'd be some sort of benifit. But I supposethat people are just so used to their computers being too slow due to their own ineptitude that inefficient programming isn't really an issue to them. It's all fine though. Our bad habits today will come back to haunt someone else in the future. They always do.