On Friday 23 September 2005 01:48 pm, Dave McGuire wrote: > On Sep 23, 2005, at 9:31 AM, Robert Thorpe wrote: > > used properly. Java programs that are slow are mostly slow because > > ... 1) Java programmers often program in a way that's prone to be > > slow, they > > generalise things a lot, they write programs that produce a lot of > > objects and need a lot of GC. > > I have to speak up in agreement here. I'm a procedural programmer > (C, mostly) but I've worked on quite a few Java projects over the > years. I have narrowed this problem down to programmers whose first > exposure was to object-oriented languages like Java or C++.
This is not true. Given a choice, I prefer someone who started an object oriented language, all else being equal. But someone who only knows from that first course, and nothing else, is a big problem, regardless of language. > Thinking > *exclusively* in object-oriented terms tends to result in > unbelievably inefficient code, because computers are inherently > procedural things, and pretty, nicely-abstracted object-oriented code > gets turned into a most decidedly procedural instruction stream at > the time of compilation or execution. Thinking exclusively one way leads to problems. There are many ways to look at a problem. Forcing everything to one way, or blindly avoiding an approach both are bad. > One example of this problem is a commercial database application > that I worked on about three years ago, written in Java. The primary > developer was an exclusively object-oriented guy. He wrote a method > that executed a JDBC query to retrieve a list of names from the > database, and another that retrieved the entire record associated > with a given name. Then he wrote another routine which used the > first method to get the list of names, then iterated over the list > calling the second method to get all the records for all names. It > took forever, and was a major bottleneck in the system. Of course > the right way to do this was with a single query, which is how I > rewrote it to solve the performance problem. The guy had NO clue > what I was doing. That last sentence is true, and would still be true if he used C, guile, or anything else. Object oriented is not the problem. Incompetence is. > The world is filled to overflowing with Java and C++ code that > does stupid things like this. and C, Pascal, Fortran, scheme, python, .... If I left out your favorite language I apologize. > Isolation and abstraction from > hardware is a good thing, but too much of it results in the need for > multi-GHz-clocked processors to do the same work we did twenty years > ago with 4MHz clock rates. > > The point that never seems to enter these peoples' minds is that > computer processors are procedural things, not object-oriented > things. A little knowledge about how computers actually *work* would > result in much, much faster Java and C++ code in the world...but > people don't seem to want to go to that much trouble, likely because > writing REALLY FAST code doesn't often get one's name mentioned on > slashdolt. One thing I like about C++ is that it is object oriented when I want it to be, and procedural when I want it to be. With STL, I can even treat it as a logic language or a functional language when that seems better. I can define a class so its objects have one appearance, but are very different inside, so I can have both readability and speed. Don't blame the language.
