--- Chuck Guzis <cclist at sydex.com> wrote:
For some, that's not sufficient.
Understanding how
a disk drive
works or what goes on over a TCP/IP connection is
essential to them.
TCP/IP is one thing. But knowing how a dd works
today?? If you're writing i/o it's one thing.
Otherwise phew.
I assume 'dd' means disk drive here. Most of the time I use 'dd' to mean
'convert and copy' :-)
Anyway, understanding how a disk drive works would seem to be important
if :
You need to repari a disk drive (perhaps one that handles unusuallu-sized
disks, or which has an odd host interface so you can't use a standard
modern srive to repalce it)
You need to design a replacement for a disk drive (e.g. using flash memory)
You need to read media from said drive
You are designing an improved storage system. Many times old ideas come
round again
You are naturally curious and just like knowing how things work
Nost people will never do any of the above, but that's no reason not to
understnad disk drives if you want to.
One other thing I've discovered time and again (in all sorts of areas) is
that there's a big difference between the ideallised version presented in
most books and the actual, paractical, device. And often it's those
little details that are interesting.
Beginning with a battery and a lamp, then moving
to
experimenting
with semiconductors, then developing logic elements
and finally,
understanding the "guts" of a computer creates a
depth of
understanding upon which to build.
So my vote is for starting simple and building.
If my opinion matters, it's a little too intense from
the get-go. I'd concentrate on the *vagueries* of ic's
and work down as necessary. Even w/assembly language,
just how much of what goes on at the gate level is
I am wodnering why you assume that computers have to be approached from
the software side. Perhaps some people prefer to think in terms of the
gates, and programming is a 'necessary nuisance' to get the final
hardware to do something (if you doubt such people exist, well, I can
assure you you're talking to one).
I would agree that msot, if not all, application programmers don't _need_
to know what goes on at the gate level, just as most hardware designers
don't _need_ to know numertical algorithms. It doesn't mean they
shouldn't look into such areas if they're interested.
useful? Few, make that precious few have any clue
what
goes on in a uP at the level you're talking about.
Sure it would be great for a kid/? to learn how to
build a discrete logic cpu. But that's an awfully
specialized area of computing for most of us.
Amidst the ensuing cries of treason or the like, a
lot of people feel that entering opcodes in hex on a
keypad is a tad *tedious* (polite version). Different
strokes for different folks I guess though. How many
people actually need to program in assembly language
these days?? As time progresses, a lot of the
knowledge that was essential in earlier times will
cease to be a necessity. I know the original question
was posed on a vintage list, but is it necessary to
learn on an 8-bit unit? There may be some good reasons
to, but if at all possible learn on something that's
going to be more relevant to today's environment (and
even that's a stretch in the case of an early pc).
You are, I think, in danger of coufusing details with principles. It's
the difference between understanding algorithms/understanding program
methodology and, say, knowing where to put semicolons in C. If you
understand the former, you are, IMHO a good programmer (and can learn
just about any (procedural) language in a couple of days at most. But
alas far too many people think that 'programming' == 'ability to code in
a particualr language'.
It's actually much the same in hardare. For example, the basic
Eccles-Jordan (flip-flop) circuit can be built with just abotu any 2
devices that can be turned on and off. Triodes (and other valves),
transistors, FETs, relays, and so on. Understnading basicl principles
like that is much more valuable than knowing how to use the current IC
(which will have been sperceded in a couple of months anyway).
-tony