Is it me or does Hardy run like a pig?
Ignazio Palmisano
ignazio_io at yahoo.it
Thu Oct 16 10:43:00 UTC 2008
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.
More information about the kubuntu-users
mailing list