Curricula (was: Assembly vs. Everything Else

From: Jay West <west_at_tseinc.com>
Date: Mon Aug 20 08:41:29 2001

I've been following this thread on assembly, thought I'd throw in my 2
millidollars worth...

First, someone said assembler programmers were thought of as "lower rung" or
"lesser" programmers by higher level language programmers. I saw just the
opposite in my experience. All through high school and college and later in
the workforce, assembler programmers were definitely thought of as the
"magic gods", and almost had a mythical status as gurus. Why? Because they
not only understood the program, they understood the machine. An analogy
is - if someone is truely an expert at working on and rebuilding
carbuerators, that doesn't mean that they know much about the car as a
whole - they need to understand the whole car, engine, exhaust systems,
drivetrain, etc. to really make the whole thing "sing". As an extention of
that - note that people who work on carbs almost always know the rest of the
car intimately. Why should programming be any different?

Unfortunately, some higher level programmers that had the capability of
doing in-line assembler thought it a trivial language, because they only
used it for a few instructions to do one particular piece of their code,
rather than designing assembly code from the top down as a standalone
program. This gives them a bad view of what assembler really is all about
and what it can do.

Second, the lack of any assembler understanding by most of todays modern
programmers just slays me. I have seen many kids graduate from college today
that haven't the foggiest idea of what an interrupt is, how a status
register works, or even what an 8250 UART is. This does them a terrible
disservice IMHO. I even talked to one guy who wrote a program years ago in
VB that talked to modems (his program basically set up a poor mans network
over dialup or directly connected serial lines). The truely SAD part was
since he did everything in VB, he really didn't have the slightest clue as
to whos shoulders his code was standing on so to speak. He thought his code
was slick - and it WAS. But packetizing data with checksums in BASIC? That's
fine if memory and cpu power are not a factor in the equation. Not using
assembler where assembler is a good fit breeds exactly the type of thing
that many of us on the list lament - inefficient and bloated code. The idea
is these days, "time to market". Most programmers today would rather write a
subsection of code in VB because that's what they know, even though it could
run 1000% faster and much more efficiently if they had taken the time to do
it RIGHT. Thought processes like this are why windoze takes such huge
resources for a single user, when for example RT11 with 8 user sessions can
be done in 32k or less quite handily.

Many modern programmers argue this - because they think their VB code is
elegent and efficient. The simple fact is (and I don't mean this as an
affront), they are dealing from a position of ignorance. Their code may in
fact be quite elegent. But if they'd take the time to look at the resulting
code that it gets compiled into - the way the machine sees their code, they
would see what a convoluted mess it becomes at Load&Go time. If they took
the time to learn assembler, and actually wrote a standalone program from
top down, then they would be able to compare it with the compiler generated
code and I KNOW the "light would go on in their heads".

All that being said, VB certainly has it's place. However, they might
consider assembler for two reasons (in places where it makes sense) - 1) for
speed, efficiency, and elegence, and 2) for a more well-rounded appreciation
and understanding of their art, VB included.

I myself have learned and programmed in more languages than I can possibly
count, and I for one - would rather program in assembler than anything.
Period. And yes, on occasion where the situation dictates, I *DO* write in
VB.

Regards,

Jay West
Received on Mon Aug 20 2001 - 08:41:29 BST