Curricula (was: Assembly vs. Everything Else

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