davean wrote:Processors are getting faster? Thats nice, have you noted that programs are getting slower faster? Interesting, huh? Maybe it is crappy programmers using high level OOP based languages to blame for our slowing computers.
I'd blame the fucking crappy programmers first.
One project (Java) I'm working on, our GUI programming team decided to write 2700 lines of code. To MOCK UP the interface - with no fucking functionality. During the course of my team (the logic team)'s hooking the logic into the GUI, we also optimized (read: REWROTE) the GUI code. The GUI is now 600 lines long, looks exactly the same, and actually functions now. And it's not like the GUI team used some tool to put things together for them - they actually did that mess by hand. Intentionally. Thinking it was the best way.
Some common issues I ran into were:
-Excessive use of class-scoped variables and objects. Literally *EVERYTHING* had class scope, whether it needed it or not.
-NO use of looping or arrays, so craptons of code duplication.
-NO use of returns. Every method's output was stored to a class-scoped variable or object.
-Use of characters as flags. This isn't always a bad thing, but, uh, when the only permissible values of the flag are 'Y' and 'N' you should be using a fucking boolean. Does anybody even bother teaching booleans anymore!? And it turns out that these flags weren't necessary in the first fucking place. Totally. Fucking. redundant.
-Use of STRINGS as flags. For instance, the user can select an "active" object on the screen. When they do this, the flag is set to the name of the object. But why the fuck do we need to do that anyway, when you can just set a fucking object pointer at the active object?
-There were plenty of methods to reset things to defaults when no code existed to change them away from the defaults. And they were all called at every possible opportunity.
-Excessive repainting of the screen. A method call to a GUI object would implicitly invoke a repaint. and then the next line would be an explicit repaint. and then after stepping out of that method, there would be another repaint. Followed by another iteration through the same thing. As opposed to, say, letting the implicit repaints do their thing, or to be safe, just doing one repaint at the end.
-Extraction of strings from objects to populate a drop-down box, and then re-searching all the possible objects to reassociate that string to the correct object. As opposed to... You know, populating the drop-down box with the objects themselves. So what if the toString() method isn't defined - go ask the fucking team responsible for them to define it... LIKE WE DID TO FIX THE FUCKING MESS. It only took 45 seconds for them to do it.
-Orphan code. Lots of it.
-Redundant methods. For example, there's a drawSomePane() - which is invoked when initially contructing the GUI. and then there's a redrawSomePane() - which is line-for-line identical to drawSomePane() - but is invoked every time the pane needs to be redrawn.
We aren't even talking about efficient algorithms here. We're talking about total lack of common fucking sense.
As a result, my team put in 80 more hours than we needed to. Just think about how much that would have cost to fix in the real world, rather than an academic setting. And then think about why, if this were real, we would have been told not to fix it. Now imagine that every major project has at least one team member that does that sort of crap. And then imagine what happens when you have a team DOMINATED by them.
Yeah. Crappy coders can have such a terrible impact that a native app can run worse than an interpreted app. I don't know if you remember Netscape 7 in it's early days. You know, the Netscape that was written in Java. The Netscape/Mozilla team had begun their descent into crappy-coderland, and then decided to try out this VM'd language. The combination of the two elements simply caused NOTHING but slowness. Netscape 3 on my 33MHz 68LC040 (that's a 68040 with no FPU) Mac was WAY faster than Netscape 7 on my 550Mhz K6-2 PC. Thank god they went back to using a native language, or else I'd probably be bitching even harder over in the Browsers thread.
IMO, complicated windowing and GUI toolkits do a lot more to add to slowness than the language, because often, they themselves are poorly coded and all the bells and whistles available to the... slower... developers distract them from thinking about the things that are really important.
