Learning Computer Science via Assembly Language

johnnyb writes " A new book was just released which is based on a new concept - teaching computer science through assembly language (Linux x86 assembly language, to be exact). This book teaches how the machine itself operates, rather than just the language. I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language. Those that do tend to understand computers themselves at a much deeper level. Although unheard of today, this concept isn't really all that new -- there used to not be much choice in years past. Apple computers came with only BASIC and assembly language, and there were books available on assembly language for kids. This is why the old-timers are often viewed as 'wizards': they had to know assembly language programming. Perhaps this current obsession with learning using 'easy' languages is the wrong way to do things. High-level languages are great, but learning them will never teach you about computers. Perhaps it's time that computer science curriculums start teaching assembly language first."

Comments

Linux x86 assembly?

[agm]

Is "Linux x86 assembly" any different to any other kind of "x86 assembly"?

Re:Linux x86 assembly?

[dysprosia]

I think what is meant is programming in assembly under Linux. Programming in assembly under Linux is different than say programming in assembly under DOS/Windows, for example.

Re:Linux x86 assembly?

[perky]

On that same note, I consider that as one of the better arguments against OO code - It simply does not map well to real-world CPUs, thus introducing inefficiencies in the translation to something the CPU does handle natively

maxim: cycles are cheap, people are expensive. For the *vast majority* of software it is significantly better value to design and build a well architected OO solution than to optimise for performance in languages and methodologies that are more difficult to implement and maintain. Who cares if it's not very efficient - it'll run twice as fast in 18 months, and will be a lot cheaper to change when the client figures out what the actually wanted in the first place. But I guess you already knew that.

Re:Linux x86 assembly?

[afidel]

True. This topic, however, goes beyond mere maximizing of program performance. Pur simply, if you know assembler, you can take the CPU's strengths and weaknesses into consideration while still writing readable, maintainable, "good" code. If you do not know assembly, you might produce simply beautiful code, but then have no clue why it runs like a three-legged dog.

About .1% of code needs to be so optimized that CPU architecture matters. For the other 99.9% speed improvements are much more likely to come from algorithmic improvements. Not only that but real world experience shows that code written in ASM is NOT maintanable, the indepth knowledge of a specific architecture is fleeting while knowledge of most high level languages lasts a LONG time.

Re:Linux x86 assembly?

[Anonymous Coward]

For the *vast majority* of software it is significantly better value to design and build a well architected OO solution than to optimise for performance in languages and methodologies that are more difficult to implement and maintain.

Embedded Systems?

I guess there goes the vast majority.

Re:Linux x86 assembly?

[HeyLaughingBoy]

Did you ever stop to think about what the world would be like if people actually wrote optimized code all the time?

Yup. There'd be no software.

Re:Linux x86 assembly?

[PylonHead]

And what software there was would be impossible to modify.

Re:Linux x86 assembly?

[pla]

For the other 99.9% speed improvements are much more likely to come from algorithmic improvements.

Gack! I perhaps have phrased myself rather poorly. Throughout this entire thread, I have not meant to refer to writing even a single line of actual assembly code. I don't mean that humans can do it better than compilers (though often true, for small sections of code), I don't mean that asm always runs faster than the comparable C (again, often true), and I don't in any way mean that asm reads more clearly than a high-level language (about as false as they come).

Perhaps an example would help...

In C, I can make a 10-dimensional array (if the compiler will let me) as a nice, easily-readable organization of... Well, of something having 10 dimensions (superstrings?). I can make a pointer to a structure that contains an array of pointers to linked lists (which sounds obscure, but I can imagine it as a straightforward way to implement, say, a collection of variable-length metadata on a set of files). I can choose to have my loop indices run in row-major or column-major order, with no high-level reason to choose either way.

From an assembly point of view, I realize exactly the hellish task involved in dereferencing the first two example. I realize that row-major vs column-major ordering has a significant impact on the quantity of dereferencing needed. Even further, I realize that by choosing row-major or column-major indexing, I can ensure cache integrity, or obliterate it.

The specific examples I just gave perhaps seem absurdly obvious to any decent programmer. But countless other, more subtle, differences in how I would choose to lay out my code, come from an understanding of what the compiler will likely do with that code, and how the CPU will eventually have to deal with it. Rather than having a superficially obvious relation to the CPU, such choices would look more like stylistic preferences than careful decisions with significant implications to performance.

How about the size of an array, for example? Sometimes using a power of two will help immensely (if it allows a constant shift vs a multiply), and sometimes it will hurt immensely (if you plan to use it such that almost every access competes for the same cache line). Things like that, which a high-level-only programmer simply will not know without experiential (ie, programming in assembly) knowledge of the underlying architecture.

Re:Linux x86 assembly?

[geekoid]

it's the same excuse when people say "all programs have bugs". While that may be true*, it has become an excuse for sub-standard programming, applications, and has let managme ship products befor they are done.

If applications were built like this in the 70's, we wouldn't have a computer industry.

I do not believe that needs to be true, and should become less true as the software industry matures. For some reason it doesn't seem to be maturing.

Re:Linux x86 assembly?

[Ralpht]

Well architected OO solution ???????? You mean bloatware don't you? As well, 'well architected' and OO are contradictory terms. If you hand craft in assembler, you then will get well architectured code. Even though it may take 10 times as long to write, it will be 100 time more efficient and a hell of a lot smaller (assuming the programmer is competent in assembly and a OO language). As for running twice as fast in 18 months - no way. Like I mentioned before, bloatware effectiveley prevents newer code from running faster on faster machines. Using assembler, code will automatically run faster on faster machines, it's the nature of the beast because it directly translates into machine code. Bloatware OO caode eventually does as well but nowhere as elegantly or efficiently as assembler. If its not very efficient, then its done by a piss poor programmer. I'd rather have a programmer working for me who is efficient even though (s)he is slower, not someone who slaps crap code together quickly because the oo language allows him to.

Re:Linux x86 assembly?

[gweihir]

Not only that but real world experience shows that code written in ASM is NOT maintanable, the indepth knowledge of a specific architecture is fleeting while knowledge of most high level languages lasts a LONG time.

That is not the point. The point is that knowing one assembly language gives far more insight into what higher level languages actually do. It is, e.g., very difficult to explain the actual workings of a buffer-overflow exploit to somebody without any assembly knowledge. Or what a pointer is. Or what pageing does. Or what an interrupt is. Or what impact the stack has and how it is being used for function arguments. Or how much memory a variable needs....

The only processor I know that actually made assembly programming almost a c-like experience was the Motorola 68xxx family. On the Atari ST, e.g., there were complex applications writen entirely in assembly. Today it would indeed be foolish to do a larger project in assembly language, but that is not the point of the book at all.

Bottom line: You need to understand the basic tools well. You don't need to restrict yourself to their use or even use them often. But there is no substitute for this understanding.

Re:Linux x86 assembly?

[Breakfast Pants]

To me, not teaching assembly in a CS major would be insane. It would be like teaching physics without any of the history of how it was discovered and without showing how to derive the various equations from the more fundamental equations. My first 3 semesters were in java. My fourth semester I was in a C, Assembly, and an intro ECE class and I am very glad that I was. The combination of these 3 classes at the same time was great. Sometimes it is a lot more helpful to learn why something works or how something works than just learning (heard countless times in my java classes) "Oh don't ask questions about that, its not something you need to know. Java handles this for you automatically." If you want it to only be taught like that thats great; just don't expect any of your students to ever create the next java.

Also, you do know that compilers are written by programmers don't you?

Re:Linux x86 assembly?

[texaport]

Assembly has little to nothing to do with either programming or computer science anymore. Computer science (IMHO) deals with the study of software engineering and algorithms

If it truly is a science, then someone who finishes a Bachelors and Masters program in Computer Science had better be capable of contributing to the advancement of this field.

This could be through the development of new languages, in which case I hope they know a thing or two about assembly in the first place.

Otherwise, a couple of Computer Science degrees would simply mean someone is a techno-wonk, a professional student, or just a technician rather than a professional engineer/scientist.

--
Disclaimer: 90% of the programmers out there do not
need a Computer Science degree, and 90% of the jobs
out there for developers don't need CS graduates

Re:Linux x86 assembly?

[YouHaveSnail]

I have yet to see a project where more than a handful of objects from older code would provide any benefit at all, and even those that did required subclassing them to add and/or modify over half of their existing functionality.

Have you never used a decent class library? Writing reusable classes requires a much more careful approach to design and implementation than writing classes for one time use, and most people can't afford to spend that kind of time. The power of reusability lies in the fact that I can go out and buy a library of useful classes and feel pretty good that the code therein has already been well tested, usually at much lower cost and higher quality than I could produce myself.

Whether it's building a user interface with PowerPlant, Cocoa, or MFC, or manipulating data with STL, the amount of code that I reuse far exceeds the amount that I write myself.

Re:Linux x86 assembly?

[John Courtland]

It also gave me a better appreciation for optimization. The cycle counting, the instruction scheduling, cheap tricks that save 30 cycles here and there (like SHL a few times instead of Multiplying). I miss having that sort of control. Coding for DOS was always a learning experience too, becuase you basically had to write an OS everytime you wanted to do anything non-trivial.

I learned Asm before I learned C, and I must say that was a good way of going about it. I'm glad I don't view C as some sort of "hocus pocus", and I never did. Everything just made sense. Now-a-days you've got Joe Blow with dollar signs in his eyes and his shiny new degree in using Java, who doesn't understand the little black box he's entering commands into.

It sort of pisses me off, because I don't want to put gay little buzzwords in my resume like C#, or Java, or .NET. I should be able to put down "Assembler: x86, z80, s/390" and the idiot HR guy should know everything else is a simple matter of syntax.

Re:Linux x86 assembly?

[Kosgrove]

I disagree. Someone with a PhD should be capable of contributing an advancement to the field. Someone with a masters should show exactly that - a mastery of the concepts in computer science or software engineering. And someone with a bachelor's should not be expected to be able to develop a new language.

In general, working Engineers (non-PhD's, software or otherwise) don't contribute to to advancement, i.e. research papers. They work with the tools they're given to solve problems.

Re:Linux x86 assembly?

[wezelboy]

I'm sorry, but saying that assembly language has nothing to do with computer science is like saying concrete and steel have nothing to do with building skyscrapers. The "features" of your high level languages have to be implemented in assembly at some point, and there are tons of crappy ideas that look great on paper but fail miserably because the theoretican had no understanding of architecture or assembly language. Interestingly the opposite happens as well, where a chip designer has an idea that looks great on paper, but fails miserably because they don't have any CS knowledge. Itanium is a good example of this.

Not So New Concept

[andyrut]

Although unheard of today, this concept isn't really all that new -- there used to not be much choice in years past.

While starting Computer Science students off with assembly (without first introducing them to a high-level language) may be a relatively new concept these days, the idea of teaching low-level languages to Computer Science students is not a revolutionary technique whatsoever. Every decent Computer Science curriculum includes several semesters of courses in which assembly language is required, to demonstrate their knowledge of basic computer processes.

That reminds me of a great fortune:

"The C Programming Language -- A language which combines the
flexibility of assembly language with the power of assembly language."

Re:Not So New Concept

[rblancarte]

I was about to say the same thing. I don't think that it is some new "mystical" idea of teaching assembly to students. I am currently taking my THIRD assembly class at the University of Texas. And I know that there are others to take.

I will agree with the parent post, this is not a new concept. Now teaching assembly to beginners, that might be new.

And I don't know if "great" coders know assembly, but I think knowing assembly is a useful tool in being able to program efficient code. If you understand concepts like division, how bad it is, what the computer is actually doing when your C/C++ or whatever language (that is not interpreted) is compiled, then you are well on your way to being able to produce efficient code.

Re:Not So New Concept

[Angry Black Man]

Win32 bit assembly (do a google search for MASM32) is actually closer to a HL language than it is to true assembly. Yet, at the same time it still manages to give you direct hooks to win dll's and whatnot.

Otherwise, true x86 assembly is not THAT difficult to understand. People bitch and complain, but it really isn't that hard. Once you understand the concept of registers and interrupts, there really isnt that much more to it besides learning the commands. It really isnt bad at all.

Re:Not So New Concept

[Anonymous Coward]

This incident raises a question for me. What exactly do the Slashdot editors do?

You would think they would be protective against this sort of thing.

Re:Not So New Concept

[FreshFunk510]

I disagree. Call me a skeptic but when he starts out his review with:

"A new book was just released which is based on a new concept .." He feigns disassociation with the book. He could've easily said "My new book was just release..".

Re:Not So New Concept

[ca1v1n]

Starting CS students in assembler isn't a new idea either. It's an old idea that some guy recycled, wrote a book about, and advertised on slashdot. Why are the old guys who started on assembler "wizards"? It's easy. Back then there weren't that many people doing it, and it was really hard. Anyone who stuck with it had to be really good.

Now for my own rant on the topic:

My first programming classes at the University of Virginia had me programming in VHDL and m68k assembler. This wasn't the intent of the curriculum or the CS faculty at all, but rather a result of some schedule conflicts and a first year advisor who wasn't in the CS department and didn't know any better. It was a disaster. Normally students here get their first taste of assembly in a course that works its way down to it from the high-level languages they'd been introduced to first. My pain with assembly distracted from the course material on architecture. I learned more about efficient programming during two lectures on C# than I did while banging my head against the desk writing m68k assembler.

Anyone who has benchmarked the C++ standard template library extensively will tell you that using the fairly complicated, safely implemented data structures are incredibly fast. Using an STL deque as an array, without any deque operations, is actually faster than using an array, which is the same in basically any machine-code language, be it C++ or assembly. The STL vector is even faster.

Moral of the story? Compilers are amazing. This has not always been the case, but it is now. Writing code in assembly results in a product that takes forever to create, is less likely to correctly handle special cases, is impossible to debug, is unreadable to those who did not write it, and often is slower than compiled high-level code. In fact, JIT compilers are getting good enough that bytecode languages are nearly as fast as well.

It's true that assembly can often be used to get a bit of a speedup. This is why game developers will often write everything in C or C++ except for 3 or 4 functions that they'll implement in assembly. The advantages that high-level languages give for correctness vastly outweigh any miniscule performance gains in almost all circumstances. Assembly's advantages in compactness are becoming moot too, as embedded devices are now capable enough to run full-fledged operating systems.

Aside from teaching architecture though, assembly does teach an important skill to CS majors though, and that is staying up all night to find a one-line bug that is making everything go wrong.

Re:Not So New Concept

[Monty]

They teach Scheme, which doesn't have OOP, but allows you quite easily to implement your own in a good page of code. As for LISP in general, maybe you should read up a little on it before you talk about it....

See Common Lisp and CLOS.

This doesn't turn people off of computer science, IMO-- quite the opposite, it allows them to focus on the problem solving aspect of CS before getting down to the nitty gritty of having to deal with complex syntaxes in other languages and low-level optimization.

This brings in another point.... Programming is all about problem solving, so why should a beginner have to worry about doing it step by step according to some arbitrary machine's low-level instruction set? It's like telling someone to learn to build houses by building his first house using only his hands and a forest-full of trees. It's educational in a masochistic way at best. It's wrong to omit it completely, but still better to teach later in education, I think....

Somewhere in the middle...

[shakamojo]

My Grandfater worked for IBM in the 70's and 80's. He did all his coding in assembly and machine language. His motto is "Anyone who doesn't know machine language has no business using a computer."

There has to be a happy medium IMHO, and I think this is a great start. While my Grandfather was on the cutting edge of the PC revolution, he now has trouble figuring out email, etc, because he operates at too LOW a level (and I feel that he now has no business being online!). Then you have the users who have the same problems because they operate at too HIGH a level (AOL, etc...). The majority of programmers nowadays fall about smack in the middle of these two groups, but I'd argue they should be a little closer to the lower levels than they currently are.

I learned LOGO and BASIC as a kid, then grew into Cobol and C, and learned a little assembly in the process. I now use C++, Perl, and (shudder) Visual Basic (when the need arises). My introduction to programming at a young age through very simple languages really helped to whet my appetite, but I think that my intermediate experiences with low level languages helps me to write code that is a lot tighter than some of my peers. Let's hope this starts a trend, it would be great if more young (and current) programmers appreciated the nuts and bolts!

Re:Somewhere in the middle...

[Saven Marek]

I learned LOGO and BASIC as a kid, then grew into Cobol and C, and learned a little assembly in the process. I now use C++, Perl, and (shudder) Visual Basic (when the need arises). My introduction to programming at a young age through very simple languages really helped to whet my appetite, but I think that my intermediate experiences with low level languages helps me to write code that is a lot tighter than some of my peers.

I'm with you there. I learned C, C++ and assembler while at university, and came out with the ability to jump into anything. Give me any language and I can guarantee I'll be churning out useful code in a VERY short amount of time.

Compare this to my brother, 12 years younger than me who has just completed the same comp.sci course at the same uni, and knows only one language; Java. Things change, not always for the better. I know many courses haven't gone to the dogs as much as that, but many have. I'm not surprised the idea of teaching coders how the computer works is considered 'novel'.

I can see a great benefit for humanity the closer computers move to 'thinking' like people, for people. But that's just not done at the hardware level, it's done higher. The people who can bring that to the world are coders, and as far as I'm concerned thinking in the same way as the hardware works is absolutely essential for comp.sci. Less so for IT.

Re:Somewhere in the middle...

[line.at.infinity]

LOGO is a horrible language. It tells you very little about how the PC works. You don't get to find out how many bits are required to store an integer, for example. LOGO doesn't have types. You can do weird things like "PRINT FIRST (1 = 1)" which prints "t" because that's the first letter in true, the value returned by (1 = 1). The benefit of learning assembly is that you have to know about how the memory and CPU works. You don't get the same advantages if you learned LOGO(which is an interpreted language) instead of Assembly.
LOGO is primarily marketed towards educational institutions. It is hardly ever the language of choice in the world of business.

Re:Somewhere in the middle...

[Snoopy77]

I learned C, C++ and assembler while at university, and came out with the ability to jump into anything. Give me any language and I can guarantee I'll be churning out useful code in a VERY short amount of time.

I'm in a similar position. Started with C++ and have since picked up Delphi, Java, PHP and other scripting languages without a problem. But don't get too cocky. We have both found picking up similar languages no problem but I will guarentee that you WON'T be churning out useful code in LISP in a short time.

Re:Somewhere in the middle...

[binary paladin]

Yes, but for little kids who have a really hard time with abstraction, LOGO is excellent. LOGO was the first language I learned even though I didn't even realize what I was doing was programming. I thought I was just drawing. However, I was drawing via an instruction set rather than free handing. Mind you I was about 7-years-old when I picked up LOGO.

LOGO is not for building applications, it's for teaching kids how to give a computer instructions. I've been tutoring some kids in HTML and CSS, ages 12 and 8. I forgot how much harder it is at that age to think in abstractions. When I try to explain broad concepts rather than concrete specifics, they have trouble following. That is why LOGO is excellent for what it was designed for.

There might be a couple kids that age that could learn assembly, but odds are most simply aren't developed enough to get it. Your mind simply isn't normally designed to operate at that level at that age. LOGO works there because the tasks are very specific with results a kid can see and understand.

I cannot believe you got modded "insightful" for making a statement like, "LOGO is primarily marketed towards educational institutions. It is hardly ever the language of choice in the world of business."

Well no kidding. Incidently, carrots are vegetables and not fruits.

Programming or CompSci

[Sebastopol]

Sounds more like a programming book than compsci book.

writing an RB tree or an A* search an assembly would be a huge pain in the ass, if you ask me.

compsci is a large part about data structures, how to choose the right datastructure, how to get the most out of an algorithm by picking the best datastructure, etc...

but i didn't read the book, so i'll just go back to my websurfing now...

Re:Programming or CompSci

[Anonymous Coward]

I'd take it a step further and say that Computer *Science* is about doing research in topics such as Systems, PL, AI, Algorithms, or the Theory of Computation. Being a great programmer is something else, although you have to be a fairly good programmer to make it in many tracks of CS grad school. (But programming doesn't matter as much for theory or algorithms students. But it's key for systems people)

But yeah... I'm not writing support vector machine code in assembly. It's so not happening. (But learning assembly as an undergrad was worthwhile and I'm glad I did. But I'll probably never program in it again because it's not terribly valuable for an AI grad student. If a high level lang is too slow for an inner loop, I'll ask my advisor for a faster machine. If a faster machine won't cut it it's probably because the complexity makes the problem intractable for large datasets)

Re:Programming or CompSci

[dilettante]

I think it's a good idea in comp. sci. *because* it's a pain in the ass. I certainly agree that assembly language is not the easiest or most efficient language for implementing certain algorithms and data structures. I also think it's very instructive to understand why.

I did learn assembly language first. I wouldn't claim to be a wizard (although i'm certainly an old-timer); but i concur with the premise that learning assembly language makes you a better programmer *and* computer scientist. Assembly language exposes you to the basic architecture of the computers that most of work with, and i believe that helps one to understand everything from why certain data structures are preferable in certain situations to basic computational complexity.

Re:Programming or CompSci

[rskrishnan]

Well thats a good point - assembly is not that great for a complex data structure ..... but on the other hand a commercial db kernel like say Orcl - has a good deal of assembly code that deals with the most elementary stuff like say a spin-lock, or a latch etc - and also for some of the routines used to insert/update/mod a b-tree (and it's cousins). So essentially it's used to tweak a VERY heavily used codepath, thus shaving off a decent percentage of time. Of course it'd be CRAZY to implement the whole B* in asm - might as well jump off a cliff!

Good idea, Bad Idea

[lake2112]

Good Idea: First teaching simple programming fundamentals through a simple to understand language. Then, confuse the hell out of a student with assembly Bad Idea: Teaching CS by starting with one of the most cryptic languages around, and then trying to teach basic CS fundamentals. There are already problems with people interested in CS getting turned off by intro/intermediate programming classes. Imagine the retention rates once my CS100 class is taught in assembly.

Re:Good idea, Bad Idea

[RAMMS EIN]

``Bad Idea: Teaching CS by starting with one of the most cryptic languages around, and then trying to teach basic CS fundamentals.''

I completely disagree. Assembly is actually one of the simplest languages around. There is little syntax, and hardly any magic words that have to be memorized. Assembly makes an excellent tool for learning basic CS fundamentals; you get a very direct feeling for how CPUs work, how data structures can be implemented, and why they behave the way they do. I wouldn't recommend assembly for serious programming, but for getting an understanding of the fundamentals, it's hard to beat.

Re:Good idea, Bad Idea

[pla]

Then, confuse the hell out of a student with assembly

I disagree. Personally, I learned Basic, then x86 asm, then C (then quite a few more, but irrelevant to my point). Although I considered assembly radically different from the Basic I started with, it made the entire concept of "how the hell does that Hello World program actually work?" make a whole lot more sense.

From the complexity aspect, yeah, optimizing your code for a modern CPU takes a hell of a lot of time, effort and research into the behavior of the CPU itself. But to learn the fundamental skill of coding in assembler, I would consider it far less complex than any high-level language. You have a few hundred instructions (of which under a dozen make up 99% of your code). Compare that to C, where you have literally thousands of standard library functions, a good portion of which you need to understand to write any non-trivial program.


There are already problems with people interested in CS getting turned off by intro/intermediate programming classes.

You write that as though you consider it a bad idea...

We have quite enough mediocre high-level hacks (which I don't mean in the good sense, here) flooding the market. If they decide to switch to English or Art History in their first semester, all the better for those of us who can deal with the physical reality of a modern computer. I don't say that as an "elitist" - I fully support those with the mindset to become "good" programmers (hint: If you consider "CS" to have an "S" in it, you've already missed the boat) in their efforts to learn. But it has grown increasingly common for IT-centric companies to have a handful of gods, with dozens or even hundreds of complete wastes-of-budget who those gods need to spend most of their time cleaning up after. We would do better to get rid of the driftwood. Unfortunately, most HR departments consider the highly-paid gods as the driftwood, then wonder why they can't produce anything decent.

Hmm, okay, rant over.

Re:Good idea, Bad Idea

[Darth_Burrito]

I wouldn't recommend assembly for serious programming, but for getting an understanding of the fundamentals, it's hard to beat.

One problem that I've found with many CS programs is that they put the knowledge ahead of the motivation for the knowledge. Teaching assembly first would be a prime example. The teachers may believe that this will provide a simpler and more understandable foundation in which their students can learn to program. However, none of the students can actually do anything remotely useful in assembler. Therefore they will exhibit remarkable indifference to the subject matter.

If they were being taught in a language like Java, C#, or even Perl, then they would be working in languages which they could use to produce useful programs. The utility of the knowledge gained would motivate them more than the fear of getting a bad mark. At least that's just the way my own brain works....

New?

[Sloppy]

A new book was just released which is based on a new concept - teaching computer science through assembly language

Uh, assembly language for teaching isn't exactly a new idea. Knuth's AoCP books used MIX, a "fake" assembly language, even though easy-to-read languages (e.g. ALGOL) were already around at the time. And he wasn't even trying to teach fundamentals about computers work -- he was teaching higher-level stuff, algorithms in those books. Think about just how weird that is.

Perhaps this current obsession with learning using 'easy' languages is the wrong way to do things.

That depends on what you're trying to learn. I think someone with a CS degree should have a deep understanding of things, and should have at least some experience working in assembly language, managing memory, writing compilers, etc. But that doesn't mean that high-level languages are a bad idea when they're learning higher-level concepts. Do you want someone wasting their time remembering what is being stored in what register, when they're learning how to write a web browser? Of course not: you want them to be thinking about the real issues at hand.

nah

[galacticdruid]

I don't think that's necessary. Unless you need assembly, why spend the time? I think your time would be better spent working on object oriented concepts and the guts of programming in general, ie: variables, conditionals, types, etc. etc.

just my 2 cents

Re:nah

[kreyg]

Well, that was kinda covered, but...

It's not necessary, and learning OO concepts will serve you very well, but given two equally competent OO programmers, but only one who knows assembly, I know which one I would pick.

In my line of work (games) - or any real time programming - understanding what's going on under the hood is vital. It also vastly aids in debugging, because sometimes dropping to the assembly level is the only way to figure out what's going on (particularly if you're getting a crash in a library you don't have the source to).

We also still do a small but significant amount of work in assembly (paralell vector calculations and the like). It's the superstars who know assembly and can actually do everything their job requires.

Assembly language IS EASIER

[Anonymous Coward]

The think concepts of registers and memory locations and stack pointers and branching is easier to understand in assembly. You can teach a simple subset of instructions. It was the way I started back in the day. I scratched my head more later learning C, etc. I guess its just the opposite to kids these days.

Probably a bad idea

[Geeyzus]

I think this is a bad idea, for a couple reasons.

1) Difficulty - Assembly is harder to learn (and create meaningful programs with) than C++, or Java, which is replacing C++ in a lot of college curriculums. This means that students will be spending more time learning assembly, and less time learning about complicated algorithms and the things you really should be learning about (since languages change but algorithms are standard).

2) Job practicality - 99% of CS grads aren't going to use assembly in their day to day jobs. They will most likely be programming in Java, or VB, or some web language (PHP/ASP/etc). Maybe some C++. But unless you are doing something that requires the control that assembly can provide, like real-time software or game engine development, you simply aren't using assembly at work.

If it's harder to learn/teach, and you won't use it after you graduate, I can't see the point in teaching it at universities.

Mark

Re:Probably a bad idea

[Total_Wimp]

The idea isn't to actually use the language but rather to learn it to help you understand other languages.

It's like learning Latin. Nobody actually uses it, but it can give you a deeper understanding of the languages that are based on it.

TW

A good idea

[swtaarrs]

I agree that assembly language should be taught, but not necessarily as the first language. BASIC is a good tool for teaching higher level programming ideas like conditional statements, loops, etc... Once those concepts are understood, C should be taught. I was a fairly proficient C programmer before I learned assembly (68k), but even then assembly helped me understand much more about the inner workings of C and what lines of code do. Instead of just knowing that code I write works, I now know why it works and I am able to do much more advanced things with a low-level knowledge of programming.

Teach architecture, not assembly

[wan-fu]

It's pointless to teach assembly as a method of creating "star programmers" -- all you'd do is teach people how to write a for-loop but in ten lines instead of three (in a higher level language). The real benefit that people get from being good assembly programmers is understanding the inherent problems/benefits of a certain processor architecture and that's what lets them generate good, optimized code for the platform they are engineering for. Teaching assembly may provide some insight into that but all it really does is teach a new language. Teaching the architecture would give the student real appreciation of what's going on and how to build efficient code. Because think about it: assembly only describes what the architecture is capable of doing.

Great concept.

[shaitand]

I started out learning to code in asm on my c64 and I'd have to say it was a very rewarding experience.

Anyone who disagrees with this probably doesn't have much experience coding in assembler to begin with. Asm really is fairly easy, the trick is that most who teach asm actually spend too much time on those computer concepts and not enough time on actual real coding. It's wonderful understanding how the machine works, and necessary to write good assembler but you should start with the 2 pages of understanding that is needed to "get" asm at all.

Then teach language basics and THEN teach about the machine using actual programs (text editor, other simple things) and explaining the reason they are coded the way they are in small chunks. Instead of handing a chart of bios calls and a tutorial on basic assembler, introduce bios calls in actual function in a program, most of them are simple enough that when shown in use they are quite clear and anyone can understand.

After all assembler, pretty much any assembler, is composed of VERY simple pieces, it's understanding how those pieces can be fit together to form a simple construct and how those simple constructs form together to create a simple function and how those simple functions form together to create a simple yet powerful program that teaches someone programming. Learning to program this way keeps things easy, but still yields a wealth of knowledge about the system.

It also means that when you write code for the rest of your life you'll have an understanding of what this and that form of loop do in C (insert language here) and why this one is going to be faster since simply looking at the C (insert language here) concepts doesn't show any benefit to one over the other.

CompSci's about more than that...

[Svartalf]

It's about optimal instruction usage, language design, automata, and a lot more. It's about optimal computing all the way around.

Re:Whatever

[jhoger]

A lot of software work is at a smaller scale. If 60% or so of software's lifecycle is maintenance, and there's a lot of software out there, and also since many software projects are very small, I'd venture to say that process is almost irrelevant for plenty of work.

Being knowledgeable about low level operation of the machine will take you farther, since you won't have the fear of getting down to the bare metal to figure out a problem. And assembly language is important there... but also things like debuggers, protocol sniffers, etc. Anything that lets you get to the bare metal to figure out a problem will get you to a solution quicker.

Process and modern design concepts are important for large projects and at the architectural level.

X86??? OMG that sucks...

[walt-sjc]

Of all the processors out there, yes the x86 is common but it has to be one of the WORST instruction sets - one of the most difficult to work with.

Is it just me???

I DO think it's a good idea to be teaching assembly, not so sure as the core of a comp sci program however. I started playing with assembly fairly early, on 6052, z80, and then later with 68000 and IBM 370. It's good to know, but I would do major stuff in it anymore. That's what high-level languages are for. You only drop to assembly when you have to for speed or space.

emulator

[bcrowell]

When I was a kid, I first learned BASIC on a TRS-80, and then learned Z80 assembler. (There were no compilers available.) Thirteen-year-old me had a really hard time with asembler at first. For example, I thought preprocessor defines were like floating point variables that you could modify at runtime.

Assembler-first might work with beginners if it was on an emulator where they could see exactly what was happening, and there was no way to crash it. Otherwise, I just don't see the point of making things harder.

Of course if you really want to make it hard, you hand every twelve-year-old kid a copy of Knuth and a hardware implementation of Knuth's hypothetical processor. Then our generation could be completely assured of job security.

It depends where you want to go in CS

[use_compress]

There are a million fields in CS-- you can view them as points on a line that stretches from engineering to mathematics. The people who work in architecture are at the most extreme end of the engineering section. If you want to go into systems programming or into architecture, then I can see how would want to base everything off of asm. But if you specialize in ai, or algorithms, or theory, you really don't encounter assembly that often... for the most part, the need isn't there to develop extremely high performance, system dependent apps. In these fields, you could do of a cs curriculum (through graduate) entirely in Matlab, Prolog and ML. The emphasis is on the mathematical structures the program represents over how the computer actually deals with them.

Re:Not necessarily the mark of a great programmer

[fitten]

I agree. It's rather unfortunate that one of the most ugly, ungainly, and hacked ISAs out there is also the dominant one. There are some assemblies that are a pleasure to use, though. The 68K line and almost all of the load/store ISAs are nice to use. Some of the older *really* CISC ones are OK too.

Ugh... x86

[iamdrscience]

For anybody on here thinking about broadening their CS horizons, I would recommend not learning x86, at least not first. A simpler, RISC(-ish) instruction set is really the way to go. It's a lot more enjoyable to program in. Some good choices are maybe z80 or 68k (program your TI calculator maybe?) or Microchip's PICMicro microcontrollers (most models have under 35 instructions to learn).

Learning x86 isn't a bad idea, and for most nerds programming assembly that's probably where it will be most useful, but I just think it's a better idea to start off programming ASM on something a little more enjoyable so that you can really learn to appreciate it before diving in with x86.

Learn assembly first, by all means

[John Jorsett]

I understand C much better than I would have had I not learned assembly language first. I think of C as a somewhat-more-abstract version of assembly. It has that "down to the bare metal" aspect in much of what you can do with it, particularly pointers.

Not the point!

[www.sorehands.com]

The point is the understanding of the workings of the machine. When I was in school, we had to take a computer architecture class which included using AND gates to make counters and such.

My first IBM PC job was C, but I had to learn 8086 so that I could debug since there was no source level debugging when using overlays.

Anyways, how do you find a compiler bug, if you can't read the code the compiler generates?

Re:Forget Computer Science!

[sydb]

Well said. Computing is not a science.

By definition. Science is the application of a rigorous discipline in an attempt to understand nature. Computing has nothing to do with understanding nature and everything to do with implementing logic in physical systems.

This is not to degrade computing. In fact, computing is provably correct as it is based on logic. Science is a statistical endeavour in which nothing is proven, but theories are constructed which demonstrate usefullness and have not yet been disproven. Computing is, however, built on the results of science.

Maths is a branch of logic. Science is a branch of logic. They are of course cross-fertilising. Computing is so close to father logic as to be almost indistinguishable - it's just a way of logic happening in acceptable time scales.

Of course, you might disagree.

Cheers!

Re:Disclosure: The submitter is the Author.

[FreshFunk510]

Furthermore Slashdot should make it a policy for people who submit their own books/publications to reveal that they are the author so that there is no conflict of interest (sort of like how News channels who report news on their parent company or subsidiary always say so explicitly). I think that's only fair to the readers of Slashdot and it won't make us feel like we're being scammed into buying someone's book.

Teaching assembly good, but perhaps not x86...

[GrahamCox]

...or any modern high-powered CPU, it's just too complicated to write good, clear, effective code. That's why we have compilers.

I think learning assembler is a great insight into an understanding of computers, but the old 8-bit CPUs were a lot easier to get a grip on, no pipelines, caches or parallel execution units to worry about. The C-64 was what I cut my assembly teeth on, and I still think that sort of machine is ideal.

To this end, I feel a great learning aid is a programmable emulator which can be run on a modern machine with all the nice bells and whistles, but the "chip" at its heart is something like a 6502 or 6800. The emulator environment can make the machine operation clearly visible, such as providing a graphical display, showing step by step what the "CPU" is doing. In fact the CPU doesn't even need to be real, it can be a made up device that exhibits some idealised characteristics. The system can support other devices too, such as a virtual text or graphics display that the emulated CPU can work with, memory chips, and virtual I/O devices (e.g. port adapters that show the port and DDR state as graphical LEDs etc).

About 10 years ago I developed such an emulator as a university project, and took it to a working demonstration level. Unfortunately I never did any more with it, but it was a good proof-of-concept and many of the CS profs saw it and felt it would make a great learning tool. Maybe it's time I resurrected it and finished it off/rewrote it. I'd be interested to hear from anyone with ideas about what sort of features this sort of aid should have.

My original design featured a drawing area where the system could be built from a set of predefined parts - CPU's, memories, I/O, then connected together (using dragged bus links) to create a memory map of the system. The instruction set of the CPU could be defined, which in turn was intended to generate an assembler for that CPU (this part I never got finished - I think if I started over I'd just stick to a fixed instruction set and hence a fixed assembler). In the running phase, the CPU was shown as a diagram of a generic CPU, showing all the registers, data paths, etc. This was updated and animated in real time as the user's program ran, and could be single stepped. It also had interrupts,which was pretty cool - watching exactly what happened when an interrupt occurred (the I/O adapter unit featured a timer/counter register which would cause an interrupt, or you could just click an "interrupt" button on the screen) was truly enlightening, especially as you could watch the stack being graphically pushed and popped as it happened! Naturally with all this graphical activity going on to show the working, it was pretty slow, but as a learning aid definitely good enough. I implemented a variety of animation levels to help speed things up. User's machine code programs could write characters to a 40x25 emulated text display at around 10cps, to give you an idea. This ran on a Mac with System 7, at the time typically having a 25MHz 68020. A modern machine would probably be able to do all this and turn in a half-decent emulation performance to boot.

I disagree

[markov_chain]

Universities are not supposed to be trade schools- they should focus on teaching their students the basic concepts, not technologies-du-jour. The purpose of teaching assembly is not to produce programmers who know x86 assembler, it's to teach the students the basics of how modern computers work.

Having used assembly a long time, and having met both programmers who did and did not learn it, I found that the former benefit from the better understanding of the underlying mechanisms, regardless of whether they actually used assembly at work or not.

Computer Science != Programming

[Michael Odell]

Although I think this may be an interesting book, I think many people confuse computer science and programming.

"Computer science is as much about computers as astronomy is about telescopes" --Edsgar Dijkstra

assembly and hardware

[jonniesmokes]

What I like best about computers is that they are super miniature machines. And unlike mechanical machines, they can do the same thing over and over again - not millions - but 10^20 or so times over and over. And they do this really really fast.

Assembly allows you to get a little closer to the mechanism. And its really nice if your want to know how hardware works. Its especially good if you want to develop robots or gadgets that interface to computers. It's nice to learn about interrupts and flags and such.

That said - if I can use C, Java, Pascal, Basic or anything higher - I will. Because it'll take 1/10th the time. Plus all those wonderful libraries are a lot easier to interface to. Even for programming the little micro controller's, its really nice to be able to do it in C.

I started out as a computer programmer and have found myself branching in both the mechanical and electrical realms. Learning assembly:

"Peter Norton's assembly language guide for the IBM PC" I wrote a disk editor. It took forever - actually - I didn't quite finish. Got about 85% of the way done. Nowadays - I think a microcontroller would be a lot more gratifying.

Excellent Programmers

[RKone2]

I've found that the key difference between mediocre and excellent programmers is whether or not they know assembly language.

You've got it backwards I think. The excellent programmers actually care about what they're doing, and as such have all learned assembly.

Teaching assembly to someone who doesn't care won't turn them into an excellent programmer.

Why don't you ask him?

[Anonymous Coward]

Most programmers who know assembly don't use it much.

Why would you make a claim like this without checking it?

Difference in ideas about CSCI

[WolfPup]

I think whether this idea is a good one or not depends on what the program considers a Computer Science Degree. Where I have taken classes, the philosophy of Computer Science is more the science of algorithms and mathematics rather than practical programming experience. The idea being the research of new and more efficient algorithms or data structures not tied to a specific language . This is more suited towards graduate work in the field of Mathematics and Computer Science.

Some other programs may approach the degree as a professional/vocational type of program preparing the student for eventual work in the field of programming.

Learning assembly may be more beneficial to the student learning as an eventual programmer in that understanding some of the low level work that the computer is doing could be important in programming.

I'm not sure that the mathematics and concept work would help as much considering a lot of the ideas in this is more general and not tied to any specific architecture, so learning the low level process may not help as much.

An (informed) dissenting opinion...

[turm]

I'm a software engineer and I work for a major CPU manufacturer. As you might guess, my job involves a ton of assembly progamming.

That being said, I disagree.

You can learn CS concepts in many ways. It's cute to learn from the bottom up, but it's impractical. I oppose it for the same reason I oppose CS curricula based on underdog languages (like Eiffel, to name one I was taught). I don't care how 'clean' they are, teach something useful.

If runtime efficiency matters, you'll know about it and eventually get down to the assembly level. If it doesn't matter, for the love of god please "optimize" for something that does: like readability, maintainability, extensiblity, portability, modularity, test-ability, etc.

Crappy fast software is still crappy software.

What we're really dealing with here is complexity, and how to manage it. Software engineers design complex programs for complex hardware. You can't possibly know every detail. Thanks to the magic of abstraction, you don't have to.

"Tight" code not always necessary

[James Lewis]

"Old School" programmers tend to have this obsession with "tight" code, and very effecient code that Assembly language programming teaches. The problem is that some of them lose sight of reality, and sometimes they become downright elitist. The author of this book certainly falls in this category. He says, "The difference between mediocre and star programmers is that star programmers understand assembly language, whether or not they use it on a daily basis." Bullshit. Since when did what language you know determine how good a programmer you are?

The fact is, MOST of today's programming requirements do not need tight code. Computers have become so fast that even a few million extra operations isn't going to make a percievable difference. That's not to say that there isn't a need for programmers who can program tight code, but the point is that it depends on the application and the platform it will be running on. Programming a huge text editor program like Microsoft Word is going to need good OO code that is easy to follow. You don't want a C hacker trying to squeeze .00000001 seconds out of the spell checker, making the code unfollowable to normal coders in the process, just because he thought it was cool. The fact is, he probably gets a kick out of writing code few others can follow. Maybe that's worth it for applications that need to be very efficient, but for other types of applications it isn't and it is just selfish of a coder to do that to the rest of his team so he can feel superior.

In the end, how "good" a programmer is depends on how useful their code is and how quickly they can produce it. Usefulness isn't determined by efficiency alone, but by its maintainability and reusabiltiy as well. For some applications, assembly will help you, for others, it won't. Knowing assembly certainly gives you more flexibility, but not knowing it doesn't turn you into a "mediocre programmer". Hopefully, knowing it won't turn you into an elitist bastard like the author. It didn't me :)

Why stop at Assembly language?

[Timbotronic]

The most useful project I ever did in my CompSci degree was writing a compiler. It was written in C and compiled a cut down form of Pascal into PDP-11 assembly language. Taught me a hell of a lot about how data is stored, pass-by-reference vs. pass-by-value and the effect of good code on machine efficiency.

But the one thing that annoyed me in Computer Science was whenever we did the really low-level stuff, the lecturers would say, "We can leave the extra detail to the sparkies (Electronic Engineers)"

So in my final year of CompSci I did Electronic Engineering 100! I highly recommend it to anyone who wants to look below the "high level" of assembly language and see what's actually happening at the chip level. And if you want to get even more detail, there's alway quantam physics...

Huh?

[FreemanPatrickHenry]

A new book was just released which is based on a new concept - teaching computer science through assembly language

I didn't know The Art of Computer Programming was a new book.

Why stop at assembly?

[BlueLlama]

First year Electrical Engineering students at the University of Texas at Austin take an Introduction to Computing class that starts with the transistor and uses a book written by Yale Patt, a prof at UT that often teaches the class. The class then teaches how transistors can be combined to make memory circuits, how you store data when represented by bits (2's complement, floating point, ASCII text). You then learn to write basic programs for a simplified computer in actual binary machine code and actually run the code on a simulator developed by students in the advanced computer architecture class. By the time you get to programming in assembly you think it's a relatively high level language and are glad to have it.

The successor to this class picks up where this one leaves off and teaches C from assembly up with an emphasis on what actually happens when you compile, allocate memory, and other things that a lot of students overlook. C++ is introduced in a later class, as well as algorithms, etc.

I personally think that I am a much better programmer for having learned in this manner. I took a senior level class in the UT Computer Science Department (which teaches assembly much later in the game) and found that far too many students, including some that were about to graduate, still didn't understand the fundamental differences between handling text data and binary, non-text data in higher level languages. Most still seem to think code executes in a white fluffy cloud and wonder why on earth 119 + 133 = -4 in their program and think '133' == 133.

Best assembler

[rs79]

The 68K instruction set is better than most of them, although if memory serves the Z80000 was even better.

But, I still contend the best all time machine language was the PDP-11 instruction set. If anybody knws what they think was a better one I'd love to see it.

Re:Disclosure: The submitter is the Author.

[Anonymous Coward]

I'm guessing you're him since you're posting AC

lol, whatever. No, I'm not "him." I'm another "him" and I don't have a book to sell. But I am forced to figure out a way to make a living on my own because the "job market" has made it clear that my 10 years of experience and college degree don't amount to FUCK. I wish this had been explained to me before I spent the 20 years and $20,000

Don't whine to me about trying to make a living or trying to pay the bills. I've been unemployed for over 12 months within the past 2 years.

Oh, please. I've been unemployed for three years straight. I couldn't get a job painting shit buckets after watching my "skills" and "experience" lightly dipped in piss batter and skillfully tossed into a shit swamp.

The job market has found a perfect way to destroy human potential with nothing more than a resume. So that leaves us with somewhat fewer choices. And I'm FUCKING tired of seeing people who work their ASS OFF being called "scam artists" because they set up a cash register somewhere.

Just because you've got it tough doens't mean you can break the rules.

"Break the rules." What rules? Who made up the rules? Where can someone refer to them? I think it's "oh, it's got a price tag on it, therefore it's a scam."

If this person wants to resort to those means, go right ahead.

WHAT means? He says "here's a book about Assembly programming" and everyone screams "scam artist." It's a crock.

Who cares about learning about computers?

[jsburke]

> High-level languages are great, but learning them will never teach you about computers.

Who cares? Knowing about computers per se isn't important; knowing how to use computers to solve your problems is. For this, high-level languages are best.

Re:Actually, they DON'T.

[Ungrounded Lightning]

Well-designed CISC instruction sets (like PDP11, VAX, and 68k)

Okay, you had me up to that sentence. It's my understanding from people I know who actually used VAX assembly, that it was a bear. Especially if you had to decode the assembly by hand. It had variable length opcodes, which if I remember right, a single instruction could extend to be upwards of 60 bytes. Oh, and that's not to mention, the 11 different addressing modes, which could be mixed and matched on all three operands (dest, left data, right data). Because all instructions could store directly back to memory, it was a bestie to create.

Call me crazy, but somehow that much mixing and matching just doesn't sound like [fun].

I didn't actually use the VAX instruction set - though I did use the PDP11's - both writing and reverse-engineering. They were both designed by the same guy (Gordon Bell) or teams he lead. I'm prepared to defer to people who actually dealt with it that the VAX instruction set was difficult.

But in the case of the PDP11 (where the few-instructions, lots-of-address-modes style came into its own), the plethora of modes actually simplified the job of the assembly programmer (and the reverse engineer). I can tell you this from experience.

Multiple address modes shrank the job of understanding the instruction set by splitting it into two parts - the much smaller set of base instructions than you'd need without the symmetry, and the small set of addressing modes. Rather than having an explosion of special purpose instructions with their own addressing modes, you have an explosion of combinations of the members of two small sets. Once you learned the two sets, the proper combination to achieve the result you wanted was obvious.

The tricks were few - and brilliant.

- The indirect-increment and indirect-decrement modes let you use any register as a stack pointer or index register, for instance. The "official" stack pointer was just the one that was implied by certain other features: interrupt and subroutine calls, primarily.

- With the program counter as one of the general registers, applying indirect-auto-increment to it gave you inline constants.

- The indirect and indirect increment/decrement addressing modes made any register a pointer. (They also led directly to the ++, --, +=, and -= operators of the C language.)

- The register+offset mode and base/offset duality gets you to particular elements of an argument array, or index into a fixed-location array.

and so on.

If you understand a few things about C (Array/pointer duality, walking arrays with auto-increment, etc.), you have exactly the understanding you need to grok the modes of the PDP11 instruction set. (Which is hardly surprising: I understand that much of C was inspired by that instruction set.)

Your analogy is incorrect, amoung other things

[xtal]

I race cars, albeit not professionally. You are very incorrect.

Being able to tell your crew that you think your car is leaning out under hard accelleration or that your suspension is too stiff or unbalanced is made easier if you understand the physics and engineering involved. Most professional race car drivers know a very great deal about these things indeed. Unless you are born rich, most dedicated racers build and repair their own cars and know a great deal indeed about the tools of their trade.

I have an EE degreee; I was taught how to build registers from logic gates; how to build counters and adders from those; how to form the basics of a primitive cpu and implement one in vhdl; how to program x86 assembly; I was also taught how the electrical signals interact to make those things possible; the physics of semiconductors and the things that make those logic gates possible. All of those things have made me able to more effectively program computers on a high level. Why would we expect less from a CS program? Computational engines, computers, are the things that drive the CS profession. I would expect anyone in the field to be intimately aware of their theoretical underpinnings.

Ironically, they have also made me a much better driver as I am intimately aware of the workings and how to tune my car's EFI system than most may be.

Would you go to a doctor who has never taken chemistry? Didn't think so.

Compilers do this

[lunachik]

Modern compilers are smart enough to perform many of these optimizations, and sometimes obsfucating your code can even interfere with their ability to recognize optimizable situations.

Computer Scientists aren't programmers

[smoon]

The problem is that computer scientists don't make good programmers and vice-versa. If you're good with code and hunker down to write lots of programs, then you tend to clash with the all-theory-no-code camp that delights in big-O notation and graph theory. Of course there is a lot of middle ground, but in general the PHd professor types that staff CompSci departments I've been in tend to have stopped learning about computers as soon as they finished their doctorate and instead concentrate on internecine politics, incomprehensible papers, and teaching the occaisional class (leaving most of that to T.A.'s who actually teach the class and understand how to compile programs).

Meanwhile the coder types graduate with a B.S. or maybe a masters then go into commercial development shops and crank out code, forgetting as much as they can about red-black trees and other subtle CompSci concepts.

So if you want to crank out programmers, then assembly is probably a good thing. God knows I learned a lot from the assembly classes I took.

If you're trying to scare students away then assembly is also a good tactic. Nothing like a good hex dump to get some non CompSci students eyes to glaze over. Sort of like making people take Biology or Physics, but instead of teaching about cells and newtonian motion, jump right into the finer points of quantum mechanics or amino acid chemistry.

On the other hand, for 2nd year CompSci students, Assembly is probably a good thing to get out of the way. It really sucks, for example to take economics for 4 years only to learn at the end "just kidding, reality is too complex to model so these are all just gross oversimplifications." Sort of like thinking programming == Java then finding out how it all _really_ works.

Re: Don't program at all

[d34thm0nk3y]

lesson 1: never listen to radio shack employees, you would probably get better advice from some random homeless people on the street, at least one of them is probably an out of work software engineer these days

lesson 2 (for the grandparent): It could just be that doing basic for 3 years prepared you to do asm, which obviously has a steeper learning curve. Also, you just did the same thing to the great grandparent that the stupid HS teacher did to you, conratulations on being a complete hypocrite.

CS != uber-coder degree

[Senior Frac]

Perhaps it's time that computer science curriculums start teaching assembly language first.

It's more critical they actually teach computer science first, instead of programming. A new CS hire, assuming their school was worth a damn, can learn a new language. I want to know if they have the math background to understand the problems that will be handed to them and that they have the ability to self-learn.

Re:Computer Science Curriculums

[rthille]

Yes, but most likely if you're doing programming on an x86 you won't be using assembly except to read the compiler output when you think it has a problem.

and 68HC11 chips may not be the latest and greatest, but I'd bet they still get spec'd in lots of embedded products (where you would be using assembly)

You're a little bit confused.

[Jerk City Troll]

Computer science isn't "knowing computers on a deeper level." Computer science is algorithms and lots of math. Computer scientists don't care about how a computer works. They don't care about the language either. They are interested in data structures and how to work with them. What language is in use is really unimportant, be it Java or Assembly.

Assembly for speed?

[DonGar]

I have say that trying to program in low level languages, or worrying about the details of the machine archtecture has usually been (in my experience) counter productive in terms of efficiency.

I'm not saying that there aren't places where low level details aren't critical, but for the most part they just draw attention away from the thing that has the most impact on performance.

Application Architecture.

The choices of algorithms and data structures are far more important than any low level details. But low level details are more fun, and tend to make us feel more manly or guruly or something so we tend to focus on them instead. In practice I find that using low level languages or super optimized tools make it hard to worry about high level structure, so the structure gets ignored.

I once worked on a project in which people were seriously freaking out over the performance hit in using virtual functions while parsing the configuration file.

At the same time, the application (a firewall) was performing multiple linear searches through linked lists of several hundred items per packet. These searches were very carefully optimized, so they had to be fast... (sigh). When I switched the system to use STL dictionaries (and later hashes), total throughput jumped three fold, yet some of the developers were worried about the cost of the templates and virtual functions used.

The fact that the algorithm is more important thatnthe details of implementation is a lesson that everyone (myself included) needs to keep getting pounded into them, because it's so easy to forget.

There are places where assembler and hardware details matter a great deal. But they are usually places that contain a lot of repetition that can't be removed algorithmically. Graphics are the obvious example.

A recent example:

My brother in law gave me one of those boards with pegs in which you try to jump your way down to a single peg remaining. I have no idea what it's called, but anyway....

I decided to be cute, and wrote a 100 line python scrpt over lunch to find all possible solutions. I was suprised when it hadn't found a single solution by the time I was finished eating. I was a lot more suprised when it hadn't found anything by the end of the day.

So I killed it and started in optimizing for performance and tweaking and trying different things. This kept me occupied over lunch for a couple of weeks, but didn't produce anything else. Finally I started doing some analysis of the problem. The first thing I found was that the search space (for the board I had) was roughly 10**18.

I didn't matter how much I tweaked the details of my search, it wasn't going to find very many solutions in less than a century (actually, it looks like a naive full search will take several thousand years).

So, after wasting several weeks of lunch breaks, I have redefined the problem. Find A solution, and rewritten my search to use a heuristic. I finished everthing but the heuristic at lunch a couple of days ago. The new system will take 100 or even a 1000 times as long to perform a jump, but I'm expecting to find a solution before I'm dead.

So, don't get bogged down in the details of an implementation. They won't usually take you very far.

Then make it binary!

[Anonymous Coward]

Why don't we just learn to code in binary? If we really want to get to know the computer, then binary is the only way to go... Computer Science is as much about computers as Astronomy is about telescopes. While knowledge of assembly would be useful, I don't think it is absolutely necessary. I know that several CS professors at my university don't even know any programming language, because it's not what they really do. They write algorithms to solve complex problems more efficiently. If learning Assembly helps with that, then fine, but I don't think it's absolutely necessary for CS. Now engineers, that's another thing...

Re:Forget Computer Science!

[Paolomania]

By definition. Science is the application of a rigorous discipline in an attempt to understand nature. Computing has nothing to do with understanding nature and everything to do with implementing logic in physical systems.

You sir, have confused Computer Science with Computer Engineering. In actuality, Computer Science research ends up a massive agglomeration of Mathematics, Statistics, and Physics. Computer Science attempts to understand nature in many ways, both with and without the assistance of a computing tool: by understanding the nature of different questions and how difficult they are to answer (language theory, complexity theory, etc.), by attempting to find algorithms that mimic the natural phenomenon of a mind (vision, agents, etc.), by motivating numerical simulation of natural phenomenon (photorealistic rendering, inverse kinematics, etc.)

Of course, you might disagree.

Of course.

Re:I think Jon von Neumann would agree, learn ASM!

[foonf]

According to legend, towards the end of his life von Neumann was having graduate students hand-assemble programs he had written into machine code. They decided to write an assembler to do the work automatically, and he was apparently quite unhappy about it, not seeing any reason for a higher level of abstraction than machine language and viewing the diversion of time to write an assembler to be a waste. So he might not exactly approve...

But learning assembly != learning architecture, and with the x86 it is probably counter-productive since you have to explain afterwards what the processor really does behind your back when you use memory operands, string instructions, etc... Understanding the architecture is important, but assembly language in and of itself is not that important, and x86 is an especially bad choice.

Assembly = excellent programmer ?

[cr_nucleus]

I fail to see the causality here. How does "excellent programmers know assembly" translates to "teaching assembly to everyone will make everyone an excellent programmer" ?

Does it also means that you can't be an excellent programmer without knowing assembly ? Well that certainly depends on how you define an "excellent programmer" but i think it's quite quick of a conclusion.

That said, if assembly can certainly be harsh for newbies, the lack of abstraction can certainly be helpful in some cases. But appart from that, i'm not sure that it will change much from the current situation (as good or as bad as you want to see it).

Really Simple Machines instead....

[16K Ram Pack]

My first machine was a Timex/Sinclair machine. My second was an Amstrad 8256.

As a kid, I did a lot of stuff on them, mostly just tinkering. Some of the things I did were to do with like building a multi line input system like I'd seen on a mainframe at college (so you could tab to fields). It was all built in BASIC, but from it, I understood the concepts behind things.

Re:Assembler and the dragon book ...

[multipartmixed]

The Dragon Book, while one of my favourites (...as I glance over and see it nestled between K&R pre-ANSI 2nd ed. and Tannenbaum's OS book..) is certainly not a good *intro* to programming book, which is what the article is about.

Take a proficient programmer who knows an HLL and assembler, feed him the Dragon Book and you _will_ have a better programmer in the end, though. So your point is certainly valid, but the timing of that book's intro should be carefully planned in a curriculum. If you're not proficient with an HLL, and at least halfway competent in some form of assembler, it will totally fuck you up.