The lost art (Was: The VAX is running
ethan.dicks at gmail.com
Tue Apr 7 15:49:42 CDT 2009
Someone on the list (whose attribution wasn't passed on)
>> But aren't those books written with assembly as the language for the
>> First, how could anybody get anything done with an assembly
Hmm... as one who has written plenty of embedded application code and
firmware (boot ROMs) and quite a bit of user application code for
8-bit, 16-bit, and 32-bit processors for money (and 12-bit processors
for fun), all I can say is you must be new.
The short answer is one instruction at a time like a composer writes
symphonies one note at a time. The overall effect is stunning, even
if a single note/single instruction doesn't do much.
>> And second, it isn't even for a "real" machine. It is
>> something he cooked up. So you read the book and you didn't even learn
>> to program a real computer. Where are the marketable skills?
Perhaps in building the skills to take a real-world problem apart into
solvable components and abstract the steps necessary to produce a
solution? It's something I see novice programmers struggle with.
This comment reminds me of an idea put forth in Rick Cook's "Wizardry"
series about a Cupertino programmer summoned to a land of magic and
dragons. He, in essence, creates a language and compiler for magic
spells. At one point, he describes the difference between himself (as
a programmer and a person from a technological world) and the wizards
of his new home from the standpoint of how their styles of "magic" are
different. The traditional wizards study for years and years to learn
a spell _exactly_ because they don't understand every nuance that
contributes to the spell working. They see "this tree" or "this blade
of grass" and seek to understand just that one instance. They can't
generalize into class: tree and instance: this tree.
One can learn "a language" or "a computer", but when that language or
that vendor or that architecture fades from prominence, it's a lot
harder for that person to keep current than learning how "languages"
or "computers" work with each different one being an instance of a
I myself know plenty of compiled languages and plenty of scripted
and/or interpreted languages. I don't really worry about learning one
more or twenty more. I "grok" the underlying concepts. The specifics
are merely window dressing.
More information about the cctalk