[EMAIL PROTECTED] wrote:
A *teacher* could give you correct software to study. Instead of reading a lot
of verbage in your calculus class perhaps you could read 50% text and 50% high
level code that does derivatives and integrals symbolically.
Given current programming languages, I don't imagine this would be a win.
However, *if* you can write software there is *no doubt* you
understand something.
And I'll disagree with that.
I'm currently writing a Scheme interpreter while I learn
Scheme. At some future date, if and when I finish it, there will be no doubt I
know EVERYTHING about the behavior of Scheme right?
No. That will only be true if (a) your Scheme interpreter is correct,
and (b) it's written in terms of something (i.e., in a language) you
understand everything about, and (c) you don't forget anything along the
way.
I've written programs that rip open macromedia director data files and
do calculations on the parts. That doesn't mean I understood macromedia
director or its files. I learned just enough to figure out when each
item got stuck on the screen or the speakers, which is what I needed to
know for that particular project. Heck, I had source listings, and the
thing was so evolved that it was incomprehensible.
I exchange data right now with other companies. I send them some XML,
they don't decode things like ", then they echo it back to me with
added fields, with incorrect quoting. I'm pretty sure they know
virtually nothing about using XML for data exchange.
Ever gotten a crappy set of requirements(*) that didn't actually match
what the customer(+) actually wanted? Ever get requirements where the
customer didn't know what they wanted, and you programmed around for a
while until you got what worked? Did the first versions prove you
understood everything about the subject?
Did you ever introduce a bug into a complex program you were working on,
because you forgot how some other part of the system was working? Did
you, at the moment of introducing the bug, understand everything about
the functionality there?
I've seen complex network protocols involving loss and reordering of
messages with multiple concurrent streams of interaction, implemented by
someone who had never heard of a state machine. The software showed a
*glaring* lack of understanding.
Have you ever seen the software that drives a pipe organ? Does reading
the software tell you how to play the pipe organ? Do you think if you
got specs that told you how to drive the hardware interfaces given a
sequence of bytes encoding particular notes, you would be able to write
the software? Afterwards, would you be able to play the pipe organ?
Have you seen software that runs devices? Or factories? Could you read
the software that runs an industrial robot and deduce from that what the
robot is building, do you think?
Have you looked at the layout of silicon and metal that goes into making
a CPU? Does that tell you everything you need to know about how the CPU
works, how to program it, why it does what it does, and why the wires
are spaced and routed like they are?
Could you implement AES (the encryption standard) from the specs? Having
done that, could you describe what AES does and why? Does it give you a
good insight into how to write another piece of encryption software, to
the point where you would trust it with secrets?
**
Software encodes understanding without necessarily imparting it. To the
extent that it encodes understanding without imparting it, reading the
software gives you only the most primitive type of understanding, namely
the understanding of the symbolic manipulations the software does. You
might be able to understand it enough to refactor it, but that doesn't
mean you could have created it.
That's why taking a large piece of code and changing all the variables
and functions to have random names makes it much more incomprehensible.
Formally identical, yet completely different from an understanding point
of view. Unless you know what the author meant the variable to
represent, the formal manipulations on it are meaningless(&). The only
way to understand the software from *reading* it is to reconstruct the
mental state of the author when *writing* it.
Sure, software is a lot more demanding. But unless the software is
correct, complete, and written entirely by you, its completion doesn't
mean you understand.
To the extent that you only implement a particular layer, you only
understand that particular layer in terms of the layers above and below.
Being able to put together a game in the Unreal editor doesn't mean you
know anything about how computers work, how physics simulations work,
how graphics cards work, how game AI works, how the hardware works, ...
It just means you understand your particular level. I don't see that as
any better understanding than you'd get by writing it on a piece of
paper and handing it to someone else to draw.
(*) ... using the term loosely.
(+) ... using the term loosely.
(&) E.g., global variables aren't "bad". They're only bad if they
mean different things at different times in their lifetimes,
just like local variables. Most programmers don't have the
discipline to ensure that, tho.
--
Darren New / San Diego, CA, USA (PST)
On what day did God create the body thetans?
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
