Re: gEDA-user: Languages etc

[Olgierd Eysymontt <olgierd.eysymontt@xxxxxxxxxxx>]

I think that more powerfull machines have made more easy to many people
get into the programming world, I'd like to forget machines are
procedural (easyly done in a some GHz big machine) but of course I
don't, I learned the old way Basic -> pascal -> C -> C++ -> ......
->java -> python ....

I think we should not care about the power of the machines needed for an
EDA system as it will always be lower than the power needed by a web
browser, or do you still pretend to browse in ascii ?

Things have changed in the last years, now you can embeed and
interpreter in you code (I do, I use jython http://www.jython.org/ in 2
softwares), a database, and many thing more, now you can make software
many order more complex than before, and that's thanks to better
languages.

Parts of one of my projects goes on a PIC microcotroller, programmed in
plain C and ASM, so I know what's been in both worlds and I can tell you
Java have many defects, can be more or less propietary, but it's a
concept by it's own, besides that, there a so many code wroten in Java
that makes very easy to learn the languaje and do a very good job, same
as with C or C++, but with 30% the effort.

Of course, at the end, everything is a matter of taste.

Hoping not be flamed this time,

Olgierd

On Fri, 2005-09-23 at 13:48 -0400, 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++.  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.
> 
>    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.
> 
>    The world is filled to overflowing with Java and C++ code that does 
> stupid things like this.  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.
> 
>              -Dave
> 
> --
> Dave McGuire            "You'll have to be a lot more specific than 
> 'that
> Cape Coral, FL              girl last night.'"    -Ted McFadden
>