Is it me or does Hardy run like a pig?

[Ignazio Palmisano]

Emanoil Kotsev wrote:
> Knapp wrote:
> 
[snip]
>>
>> There is also a huge shift in how people code. When I wrote code for a
>> C64 we would spend a week going over the machine code to remove a few
>> bytes. Now when I code I go over it and make the code longer so that
>> it is clearer for debugging and maintenance. I also rarely worry about
>> making my code faster or smaller. Why would I waste the time? I have a
>> HUGE hd and LOTS of ram and my CPU is a x2 64 bit monster. Then there
>> are all the new languages. They make coding faster and less buggy but
>> they don't make it more efficient or smaller. A lot of code is now
>> done in Python, an interpreted language. It used to be all done in
>> assemble or C and compiled.
> 
> Thanks for mentioining this. I think it's really the problem and the real
> problem is the mentality behind ... as you said 'I don't care because my
> machine .... '
> 
> Each and every programmer should care about code optimization.
> 
> I think younger programmers who did almost never code in C (they are usually
> using modern scripting language like python) tend to not think too much
> about what they are actually doing at low level
> 
> as a result all of us suffer
> 
> very very sad
> 

I am forced to cite Donald Knuth here, back from the seventies: 
premature optimization is the root of all evil :) the design is what 
must be honed over and over again, the details of the code come into 
play only very late in the game. Knapp said:

"Then there are all the new languages. They make coding faster and less 
buggy but they don't make it more efficient or smaller."

Faster is not more efficient? Smaller as in memory size, I agree, that's 
important, but less buggy, from my point of view, is the jackpot. I have 
done my share of programming in C and debugging other people's C code as 
well, you would not believe the difference that memory management does, 
both for size and speed. Java took care of that (up to a point), and the 
(nowadays little) extra cost is well worth the hours the developers 
would have to spend in hunting for subtle bugs and trying to defend 
themselves against buffer overloads - yeah, that's a battle that's still 
going on.

Shortly ago the lack of resources (as in coder time) for Kubuntu was 
mentioned on this list. There is precious little of it, do you prefer to 
waste it in chasing assembler code through local and far jumps (been 
there, done that, the t-shirt is worn out nowadays), or to allow them to 
step back and realize why <insert very needed functionality here> is way 
too slow?

In a perfect world, the design should be good and the coding should be 
perfect. Sadly, in the real world you need compromises...
my 2 cents,
I.