24 Apr
2009
24 Apr
'09
3:39 p.m.
A bit of the conversation so far:
Warren:
Neither do I. On the other hand, I tend to think hardware progress
has been TOO fast, and that software, because of the speed of the
hardware, is immensely sloppy and inefficient, to a degree I find
amazing. Some years back, I was looking at a setup for a Microsoft
programming environment. It came on five CDs, IIRC, and I couldn't
help thinking of Turbo Pascal for CP/M, wich came on a single
floppy, and had an editor, compiler, and debugger in about 56 K of
programming space. The efficiency factor difference is stunning. I
believe that a bit more time at each 'watermark' of hardware
progress would result in tightening of software efficiency to
improve product performance, rather than just waiting for the next
generation of PC hardware to hide one's poorly-written code. Again,
that might just be me...
Teo:
Go get an embedded computer or program your phone of you like simple
hardware and simple software.
Dave McGuire:
Pardon me for jumping in, but...it's not a matter of "simple",
it's a matter of efficiency and good design. Warren hits the nail
on the head above. This is one of the biggest reasons why I don't,
and probably won't ever, delve into the Windows world. Most of the
less-clueful programmers work in that world (please don't flame,
that's very different from saying that all of them are less clueful)
and they tend to be extremely wasteful of resources.
You've got it, Dave. I only deal with Windows because I've had clients
who will pay me for it, and for the occasional odd device for which
Linux drivers do not exist. My main computer, now, sadly, down for a
while, is a Linux machine. "Simple" is not the adjective that I like,
it's "elegant." I've always liked the idea of a Small-C type language,
one that generates assembly language programs as output. That allows
one to get around an inefficient compiler and do the critical parts to
the best of the machine's ability.
A benefit of the tiny CP/M and similar computers was that one pretty
much HAD to pay attention to bytes and cycles -- or one's program was
useless, or wouldn't even run. I'm reminded of the comment by Blaise
Pascal, paraphrased from the French: "I apologize that this letter is so
long - I lacked the time to make a shorter one." Good, tight, efficient
code takes longer, or takes more skill, to write -- or both. But, I
claim it's worth it. Perhaps obsessive concern about efficiency doesn't
pay, but the apparent total lack of concern for efficiency detracts from
the useful nature of the software, and from it's reliablity.
Teo:
I think hardware progress has stalled for a long time, instead of
new architectures or new CPU designs we generally just have die
shrinks, multiple cores, and new material to make the same old thing
a bit faster (mostly spinning its wheels or bogging down in GUI hell).
Dave:
Too true. I like to think of that as an architectural convergence of
sorts. We've learned a LOT about processor architecture since the early
1970s, and many of today's architectures have become more similar as a
result. Ideas that seemed good at the time but failed in practice have
fallen by the wayside, the importance of register count is now
understood, etc etc.
Of course now we've got lots of people using one of the 1970s
throwback architectures with many of its disadvantages and bad decisions
still intact, but that's another matter.
Right, guys, but when I spoke of "progress" in hardware, I was NOT
speaking of cleaner architectures, but of greater speeds in the same old
architectures, so that bad coding isn't as evident. Heck, if ONLY the
world had moved to the Motorola 6809 when it was first available, it
would have provided impetus to continue to improve microcomputer
architectures, rather than just pouring more silicon into a bad (or at
least primitive) original design. I think this point has reached
consensus here. <Grin> I *ALWAYS* prefer the elegant method over the
brute force method. Just don't forget that the brute force method DOES
work, though... and is often cheaper and easier.
Peace,
Warren