Re: [comphist] Lost arts from the 8 bit days.

[Thomas D. <te...@cy...>]

Sorry for so many copies of that. The server said it didn't send,
then I saw 3 copies went through. Hopfully that's fixed now.
Crappy power, and a broken UPS :)

Eric S. Raymond wrote:
> Thomas Dodd <te...@cy...>:
>>But the art of small code, using neat trick, like the unused bits
>>of one variable for bools and condition registers is not done now.
>>Imagine most x86 programmers trying to write code with just the
>>6502 register set (A, X and Y).
> 
> 
> I am *glad* this kind of programming is dying out.  And I say that as
> somebody who did a lot of it back when it was necessary.  I'll say
> this once:
> 
> 	MAINTAINABILITY IS MORE IMPORTANT THAN EFFICIENCY

I would agree in most cases.
But efficient code doesn't have to be unmaintainable.


> No, that wasn't the case fifteen years ago, or even ten.  Machines were
> too constrained.  But today, if I were managing a project and caught anybody
> doing tricks like you describe, I'd chew him out but good.  There is such
> a thing as being too clever in the wrong direction, and this is it.

But, you learned a lot from that. Sure, it would be overboard today,
except in embeded devices, but the skills are still usefull. Instead
bits in a byte, it could be bytes in a structure. Or accounting for
cache line length. Also important is knowing *when* to use it, and
documenting it, since comments in the source don't take up space
in the object code.

But it's good to know how to trim the code when needed. Like a few K
from fitting in one ROM, and the next size up is 2x the cost. Ignoring
the memory footprint is not a good thing. Should I always allocate the 
biggest structure I might need, or should I use only what I do need. In
the bloated world today, no consideration of memory is given.

Should I use if-else or case? Do I these the most common case first or
last. Can I reduce the number of branches by changing the tests? Knowing
the hardware (and compiler) are impoortant there.

Documenting what is done is even more important when you use non-obvious
methods. But the methods have valid uses. Look at perl code. It can be
effecient and understandable. It can be ineffecient and impossible to
follow.

And we've all seen bloated code that is neither effecient nor
maintainable. Having looked at OO.org and Mozilla, I would have
nightmares if I ever saw Windows98/Me/XP or MS-Office.

	-Thomas