Re: gEDA-user: Languages etc

[Al Davis <ad82@xxxxxxxxxxxxxxxx>]

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.