Slashdot Mirror
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."
Is "Linux x86 assembly" any different to any other kind of "x86 assembly"?
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."
Isn't that what Knuth did with his ASM language? I believe it was a synthetic assembler for a hypothetical stack machine -- hence the name ASM - Abstract Stack Machine.
The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
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!
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...
https://www.accountkiller.com/removal-requested
Knuth's The Art of Computer Programming was illustrating the algorithm in an imaginary assembly language.
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Real programmers learn machine code.
What you meant to say was that your new book has just been released. If you're going to pimp your wares on Slashdot, at least put an appropriate disclaimer on. That said, I completely agree with the premise of the book. I've met a lot of mediocre programmers, and a few good ones. But I've never yet met a real star that didn't have some background in assembly language programming. Personally, I haven't written anything in assembly in well over a decade. But that fact that I can do so if needed makes me a better programmer, and I'd recommend it to any aspiring coder as a key skill to learn. I wouldn't say IA32 is a particularly nice introduction (I'd start with a cleaner, simpler architecture, such as 6502), but it is at least widely available to anyone that wants to study it...
"The invisible and the non-existent look very much alike." -- Delos B. McKown
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
we are all one consciousness experiencing itself subjectively - bill hicks
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.
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
I'm not a great programmer, but I never really understood programming -- especially C programming -- until I took 68000 assembly. It also took a digital logic course so I could imagine how a processor was built. It's just abstract manipulation of symbols until you can imagine exactly how your printf("Hello World!\n"); gets broken up into neat little binary chunks.
ps. Don't make them learn x86 assembly. I think that's banned under the Geneva convention.
Toronto-area transit rider? Rate your ride.
http://savannah.nongnu.org/projects/pgubook/
It's also being used at Princeton
I agree with the sentiment that knowing assembly language maketh a programmer, in some circumstances. It allows a deeper understanding of how certain languages work "under the hood", and how to debug errors that may not be so easily detected by than just staring at code. Knowing C and assembler, for instance, is a good match in my eyes.
It may not be so important though, if you're a database programmer, or if you're dealing with high-level languages such as Java or something.
assembly is the great monster that requires fresh blood every year, or the great darkness will fall upon the land. i myself have never dabbled in assembly because i don't like living in an hp lovecraft nightmare.
For those of you insane enough to take the plunge, check out this FREE online introduction course (no reg, don't ya love it). The guy who wrote it is pretty wacky. I took his java introductory course and it was hip as well as very educational.
Get it to your Valentine on time! Choose UPS 2 DAY and pay the price of Ground.
Yeah. Give my GF a book on Linux Assembly programming. That should get those panties off in a hurry.
"Quotation is a serviceable substitute for wit." --Oscar Wilde
Perhaps it's time that computer science curriculums start teaching assembly language first.
Here at University of New-Brunswick (Canada), they may not teach assembly language "first", but we do have a second year course dedicated to assembly and the inner workings of computers. My only problem though at the school is that we learn the Motorola M68HC11 cpu and not current ones. Sure it's easier to learn and understand, but most computers we work on today are x86 based.
My 2 cents.
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.
I think it's a little weird to call this "Learning Computer Science via Assembly Language." It's programming, not computer science. Computer science is really only marginally about computers. It has to do more with algorithms, logic, and mathematics.
You can study computer science, and produce new knowledge in the field, without ever touching a computer.
This misunderstanding is, I think, part of the reason so many students drop out of CompSci. They head into it thinking it's about programming, and are startled to find that computation and programming are not equivalent.
That's why the Compilers course at PSU is considered the "filter" which kills all the students who aren't really interested in computer science. They really need to spin off a seperate "Software engineering" school for these students, since what they really want to study is programming.
real programmers do:
copy con myprogram.exe
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.
Well, for starters the syntax for assemblers is different. There are two standards, the AT&T standard (which is used by the GNU assembler) and the other one that is more familiar to DOS/Windows x86 assembly programmers (which is used by the NASM assmebler).
Second, OS interfaces for making system calls (e.g., to read files, open network connections, etc) are different in Linux versus DOS or Windows).
My other first post is car post.
I think the article should have disclosed that the submitter (johnnyb) is also the author of the book, Jonathan Bartlett. So rather than saying "A new book was just released", I would rather see something like "I wrote this new book." Here is johnnyb's website. http://www.eskimo.com/~johnnyb/
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.
It's about optimal instruction usage, language design, automata, and a lot more. It's about optimal computing all the way around.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
In the BYU CS department they've recently gone a little farther than starting with assembly language. The introductory programming class actually begins with digital logic gates. The next section deals with assembly programming using the contrived LC (Little Computer) opcode set. It's a much smaller set of opcodes than x86, so it's simple enough for beginners, but still contains the important elements learned from doing assembly programming. The course ends with an introduction to C++ and OOP. I think the change in curriculum is a very wise idea. I took a class in digital circuitry and it has helped me so much in my programming. I'd like to see more programs move in this direction.
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.
MIXAL, MIX assembly language. MIX was the virtual machine I learned assembly on in 1975. Googling reveals that MIX was, in fact, the Knuth virtual computer. The book came with a little cue card with a picture of Tom Mix on it. MIX has 1 K of memory. Amazing what can be done in 1 K.
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.
Except that things like "i = i + 1" vs. "i++" vs "i+=1" are mostly irrelevant today, since that's a very easy thing for compilers to optimize. And they've been optimizing stuff like that for years.
Try looking at the asm output from GCC at -O2 on those two statements.
Knuth had reasons for using ASM that were a lot better than that. It does give you a better idea of how things are laid out in memory, because you have to do it yourself. It's easier to do detailed performance analysis of algorithms, because you can get exact cycle counts. (Which in turn helps train your intuition, and tell you how to find out from a CPU's instruction set how it does at various things to tune algorithms.) You can look at how cache affects things.
Take a look at his reasons.
I think one would be much better off writing in C without optimization, then stepping through the execution in a disassembler to see how the resulting machine code operates. Yes, it helps to write more efficient high level code if you know how it is converted to machine code. For example, I had a coworker who made a habit of declaring initialized arrays local to his functions. I had to point out to him: "You do know that this causes the array to be copied onto the stack every time you enter the function, thus really slowing down program execution, don't you?" Apparently this had never occured to him, because he had never actually watched the code execute.
"Freedom means freedom for everybody" -- Dick Cheney
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.
Find free books.
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.
A real computer science program will teach generic principles of programming and systems development, with projects that delve into a variety of actual implementations of systems.
For example, a b-tree data structure is fundamentally the same thing whether you implement it in 32-bit ARM assembly language or 16-bit x86 assembly language or C or Java.
To understand how assembly language works, you need to understand how a processor works, how instruction decoding works, how register transfer language works, how clocking a processor makes it accomplish things. To understnad how registers hold values electrically and transfer values between registers you need to understand some physics and electronics.
To understand how a compiler takes a source language and translates it into a target language, you need to understand a little about the kinds of languages computers can understand (Context-Free Languages) and how they can parse them (Context-Free Grammars). Delving into that field will lead to the core theory of computer science, what is possible with machines in general and what is impossible.
A real computer science program at a university will take you through all of these subjects over several years, allowing for some excursions into other things like databases and cryptography. A real computer science program is always theory with projects that are applied to actual implementations.
My other first post is car post.
I agree with what the author has to say about assembly. I never felt like I new enough until I learned assembly, even though I started with LOGO in 1st grade, and have had programming every year since. Then I came to understand a lot of how to prevent security holes in higher-level languages, and how to write tighter code. It also helped with better understanding program security from hackers, i.e. how they can hack my programs, product keys (or other such copy protection measures) and find the exploits. Mostly since they disassemble anything they can't decompile...and of course disassembling something puts it into assembly language of one sort or another. It is a class that I didn't get in college, and went back for after I got my degree. The most useful one IMO.
:p
An off the shelf book I liked and found useful was "The Art of Assembly Language" by Randall Hyde. I liked it better then my text books, anyway
From the website
...
>>To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor works.
A race car driver is a high-level user of the car (more akin to a financial analyst using Excel). Why would a high-level user care about HOW the carburetor works? All he has to tell the pit crew is how the car is behaving. A professional race car driver's job is to drive the car faster than the guy or gal next to him. End of story.
Now the mechanic or race car engineer is a different story
I forget...are we at war with Eurasia or East Asia?
Lets see 20 years ago this is what I remember being taught in undergrad CS (Though I'd been an assembly programmer for 7 years already then):
1st Year: Pascal, PDP-11 assembly
2nd Year: 68000 Assembly,
3rd Year: Ada, Eiffel, Modulo-2, Smalltalk, VHDL, EDIF
Interestingly despite using mostly UNIX hardware C was left to be self taught, though it could be used in place of Pascal.
The point really was use appropriate tools for appropriate jobs: Thus we learnt OS/Kernel basics in assembler, likewise IRQ concepts and HAL stuff. For algorithmic stuff we worked in a mainstream strongly typed high level language. For trends yet to propagate to the commerical world (some doomed ones!) we learned in exotic academic languages.
Assembly is as valid today as it was in the 1950's, its just that its most appropriate for only some tasks that a minority of programmers do: Deeply embeded microcontroller SW, OS kernel work (take a look in our beloved linux kernel code), hardware bootstrap, hard real time etc etc etc
Just learn C instead. It combines the readability of assembly with the ease of use of assembly.
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.
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.
I've found I get blank stares sometimes when discussing memory usage, I/O bottle neck or code optimization in front of PHB's. All they want is crap to run and if they've got the money they'll throw it at buying more power. Sadly I've seen BSCS people who care less about getting a project done rather than done well, often with hideous looking code which can choke the fastest quad processor servers. A little time spent, considering how code may be written to minimize impact or organize I/O more efficiently isn't even encouraged anymore, where it once was a hard rule.
Look at VB.NET, it's the very embodiment of just code and don't worry about it. So much of the work is buried in libraries/namespace, you really have no idea what impact calling routines will do.
Today's lesson: Screw finesse, just throw more CPU and memory at it.
A feeling of having made the same mistake before: Deja Foobar
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.
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?
Fight Spammers!
I don't think knowing assembly language is required to become a good programmer, but a good programmer should learn how the computer works at that level at some point in their life. And that's the key. Assembly language isn't a bad way to learn that, but it isn't the only way. And, in many respects, it isn't really the best way, either.
See, I'm sort of tore. I like this idea since I feel most programmers these days are sorely lacking in the fundamentals. However there are advantages to starting higher. One major advantage I can think of is that when you start so low level, there are certain ideas that may never occur to you. Certain ways of solving problems won't come up because you "know" how the computer works and therefore adapt your thinking to it and seeing things very narrowly. I believe that we should be working towards adapting the computer to us instead. And when students start out learning at higher and higher levels, they start thinking higher and higher level and see connections from their "low level" beginnings to a higher level ideal without being bogged down in the little details. I think that would help drive innovation.
Hexy - a strategy game for iPhone/iPod Touch
Real men type the 1's and 0's in directly. Who needs a sissy assembler to do the translation? I wouldn't hire a programmer who did not know what "011001001100" meant to today's x86 procs.
Ok, let's get real. This is equivelent to saying that unless a farmer gets on his hands and knees to plant 1 seed at a time, he's not a real farmer. Sure, he knows how to operate a $100,000 tractor that can plant several million seeds each day, but his hands-on knowledge of planting seeds isn't near what his great-grandad's was so, he must be less of a farmer... even though his output is thousands of times greater.
HELLO! It's called technology. It's all about advancement. We no longer have to type in the 1's and 0's ourselves. Hell, very few of us need to use assembly. Why was C written? Because all the fucked-up assembly languages in the world do not work together. A program written in XYZ assembly will only run on a XYZ computer, etc.
Today, programming is high-level. Write once... run everywhere (Java, Python, C#). Let's leave this assembly crap, and it is crap, where it belongs... back in the dark ages!
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!
Yours Sincerely, Michael.
...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.
Assembly is an impediment to understanding high-level issues. While I agree 100% that any good CS program should include some discussion of assembly and systems programming (at least a few semesters), there is so much more to CS than systems hacking. There is no way that a whole modern CS curriculum should be taught in assembly language.
As a starting language it's really a matter of preference: the bottom-up method gets you really understanding the machine (and really yearning for more convenient tools), but it is a slow, painful start. The things you learn are less general and will be less applicable years down the line. On the other hand, learning a high level language can leave you in the dark about what's going on under the hood, which means that some aspects of what you're doing will seem like "magic". For you efficiency addicts, this can mean less efficient code. On the other hand, the world will have fewer efficiency addicts!
However, I think that assembly will turn a lot of people off of programming that could otherwise be interested in the subject and perhaps productive programmers, if not cowboy kernel hackers.
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.
Tsunami -- You can't bring a good wave down!
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
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.
by Randy Hyde at Univ California - Riverside. To learn about assembly on 80x86 processors, check out the printed book, or download the text with a Linux or Windows point-of-view. It's written in a style that's not overwhelming to the novice.
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.
From the book's presentation page:
To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor (sic) works.
To which I reply: To be a book writer without ever learning how to spell properly is like trying to teach programming by starting with assembly languages.
A message from the system administrator: 'I've upped my priority. Now up yours.'
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.
-- Wolfpup
"A man whose circumstances went beyond his control." -- Styx
It is not assembly language. It is the way we think - and in the world of computers there are 5 types of languages that will make you take on anything very easy.
1. Procedural (Pascal/C/BASIC)
2. Object-Oriented (Eiffel/Smalltalk/Java/C++)
3. Functional (Scheme/Lisp/Logo)
4. Declarative (Prolog/Forth)
5. Assembly (x86 etc.)
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.
Ewh! Yuckky. Teach them a *REAL* assembly language like MIPS or ARM.
x86 is just an abortion that got to full term.
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 :)
Perhaps it's time that computer science curriculums start teaching assembly language first.
Having taught an assembly/into computer arch class, I agree with the sentiment that students who get "under the hood" gain valuable knowledge and working skills. Not just pounding ASM, but in learning how the machine works. Point agreed.
Also having taught first year computer science students, and seen how some of academia's transitions in pedagogy affected students... I have to say that the idea of teaching first year students in assembly is friggin' daft.
My reasoning is the same as why I strongly advocated an objects-first teaching model. It is increasingly critical for students to build a strong sense of software design and abstraction early on. This foundation makes students much better prepared to solve problems of many different scales (asm to component-systems) in the long run.
There's evidence from a paper in one of the Empirical Studies of Programmers workshops that this approach does trade off design skills for purely algorithmic reasoning for students at the end of their first year. But my own experience, as well as that of some prominent Comp Sci Education (CSE) folks seems to indicate that this is far more than compensated for as a student's skills grow.
Here's my theory as to why this is the case:
The details of debugging, alogrithmic thinking, and problem solving are very much skill building exercises that really require time of exposure to improve. But it is much more difficult in my experience for students to build good design sense on their own. Once the framework for thinking in terms of good abstractions is laid down, it provides much stronger support for later filling all of those gory low-level details.
Historical perspective: Ironically, this same reasoning is much of why I believe that academia's switch to C++ from languages like Pascal, Modula-2, etc. was an educational disaster for many years. The astute reader is now thinking: "hey, you just said you like objects-first; what up?" In the Procedural Era, many schools wouldn't expose students to C in the first year, as it had too many pitfalls that distracted from learning the basics of algorithmic thinking and important abstraction skills. Once the foundation was put in place, it was okay to swtich 'em to C for the rest of the program.
When C++ and the early object boom really hit, this put on big pressure to teach first year students using C++. At one point in the mid-90's, upwards of 75% of 4-year institutions were teaching their first year in C++. Thus a language that had plenty more pitfalls than C, previously shunned for its pedagogical failings, entered the classroom. Combined with a lack of of proper OO mental retooling on the part of first year instructors and faculty made for something of a skills disaster on a broad scale. At best, students learned "Modula-C" instead of good OO style. At worst, they were so confused by this melange of one-instance classes and sloppy hybrid typing that they didn't get a cohesive foundation whatsoever.
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...
One of these days I'm moving to Theory - everything works there
People who know assembly produce better code by almost any measurement except "object-oriented-ness", which assembly makes difficult to an extreme.
Actually, they don't.
A study was done, some decades ago, on the issue of whether compilers were approaching the abilities of a good assembly programmer. The results were surprising:
While a good assembly programmer could usually beat the compiler if he really hunkered down and applied himself to the particular piece of code, on the average his code would be worse - because he didn't maintain that focus on every line of every program.
The programmer might know all the tricks. But the compiler knew MOST of the tricks, and applied them EVERYWHERE, ALL THE TIME.
Potentially the programmer could still beat the compiler in reasonable time by focusing on the code that gets most of the execution. But the second part of Knuth's Law applies: "95% of the processor time is spent in 5% of the code - and it's NOT the 5% you THOUGHT it was." You have to do extra tuning passes AFTER the code is working to find and improve the REAL critical 5%. This typically was unnecessary in applications (though it would sometimes get done in OSes and some servers).
This discovery lead directly to two things:
1) Because a programmer can get so much more done and working right with a given time and effort using a compiler than using an assembler, and the compiler was emitting better assembly on the average, assember was abandoned for anything where it wasn't really necessary. That typically means:
- A little bit in the kernel where it can't be avoided (typically bootup, the very start of the interrupt handling, and maybe context switching). (Unix System 6 kernel was 10k lines, of which 1.5k was assembler - and the assembly fraction got squeezed down from then on.)
- A little bit in the libraries (typically the very start of a program and the system call subroutines)
- Maybe a few tiny bits embedded in compiler code, to optimize the core of something slow.
2) The replacement of microcoded CISC processors (i.e. PDP11, VAX, 68K) with RISC processors (i.e. SPARC, MIPS). (x86 was CISC but hung in there due to initera and cheapness.)
Who cares if it takes three instructions instead of one to do some complex function, or if execution near jumps isn't straightforward? The compiler will crank out the three instructions and keep track of the funny execution sequence. Meanwhile you can shrink the processor and run the instructions at the microcode engine's speed - which can be increased further by reducing the nubmer of gates and length of wiring, and end up with a smaller chip (which means higher yeilds, which means making use of the next, faster, FAB technology sooner.)
CISC pushed RISK out of general purpose processors again once the die sizes got big: You can use those extra gates for pipelining, branch prediction, and other stuff that lets you gain back more by parallelism than you lost by expanding the execution units. But it's still alive and well in embedded cores (where you need SOME crunch but want to use most of the silicon for other stuff) and in systems that don't need the absolute cutting-edge of speed or DO need a very low power-per-computation figure.
The compiler advantage over an assembly programmer is extreme both with RISC and with a poorly-designed CISC instruction set (like the early x86es). Well-designed CISC instruction sets (like PDP11, VAX, and 68k) are tuned to simplify the compilers' work - which makes them understandable enough that the tricks are fewer and good code is easier for a human to write. This puts an assembly programmer back in the running. But on the average the compiler still wins.
(But understanding how assembly instruction sets work, and how compilers work, are both useful for writing better code at the compiler level. Less so now that optimizers are really good - but the understanding is still helpful.)
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Thanks for reminding the forum that Assembler is already one step removed from the actual machine language. I threw myself against several assembler lanuages and never got the result I desired. I loved the logic but hated the syntax.
Personally, I wish that, in the evolution of computer languages, we spent a little bit more time evolving a somewhat more intuitive set of languages at the assembler level. As there is still a great deal of programming that really should be done at the machine level, an assembler rival might help spur on the use of linux.
The book is going into my wish list.
The book was released under the GNU Free Documentation License, and it can be downloaded for free (in PDF format) from: http://savannah.nongnu.org/projects/pgubook/ .
Anyone who cannot simultaneously consider the position of every logic gate and every memory register has NO business being in the same time zone as a computer.
The CS and CE programs I went to in Virginia only differed by 3-4 classes. CE had 2 semesters of micro controllers, Linear Algebra, Ordinary Diff EQs and Chemistry. While CS required Algorithms and Operating Systems. CS could opt for matrix algebra for business or the engineering based Linear Algebra. Other than that, they were identical. Many students opt for dual degrees. Both required physics,calculus and what they called core curriculm which was Digital design, and alot of programming, computer architecture etc. Both taught assembly, C++,UML and java was a popular elective.
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.
I have discovered a truly marvelous
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.
blech, 6 figures for VBA macros? I guess it's a living... um, good job, but I'd sooner toss my machine out the window than work with Excel all. day. long.
There's more to life than money.
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.
Need Mercedes parts ?
Eh, it isn't really unheard of today.
In the old days, computer scientists didn't really exist. You basically had groups of electrical engineers, mathematicians, etc, developing what is today computer science.
As a graduate of an accredited Computer Engineering curriculum, my take is this; computer scientists develop software, algorithms, etc. Computer engineers design the underlying digital circuits, logic, and such. Software guys vs. hardware guys.
As such, you'll find computer engineers use assembly a heck of a lot more than computer scientists. I've worked with MIPS, x86, motorola's, and several others. And when you get down to it, I like to work with C more than I do with languages like C++ or Java. I enjoy the low-level nitty-gritty.
I'm making a generalization of course; there's no great schism between the two groups and our work often overlaps. We just each use the tools most appropriate for our jobs.
A preposition is a terrible thing to end a sentence with.
From the description:
To be a programmer without ever learning assembly language is like being a professional race car driver without understanding how your carburetor works.
My corollary:
To program in assembly language is like driving in the Indy 500 in a car that doesn't have fuel injection.
WARNING: there is a trojan on your
has been available for some time under the GNU Free Documentation License. I tried to use it a while back when I decided to learn assembler, but I found Paul Carter's PC Assembly Language to be a much better introduction.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Am I the only one who went to a school where it was expected that you already had a solid knowledge of programming? From day one I started taking theory classes. Aside from a digital design class where we briefly worked with motorola assembly, the only programming I did in school was to aid in math, physics, and CS theory. I personally find it offensive when somebody assumes that, because I was a CS major, I am nothing but a programmer. Honestly, I was a better programmer before college, because afterward all my time was spent on doing proofs, developing algorithms, studying computability, etc. Implementation was, for the most part, trivial.
Anyway, that's what I learned about computer science. There are apparently a lot of school that teach *programming*, and I find that to be a real shame.
ascii art
Nothing else in the Universe can make students grateful -- grateful! -- to be allowed to use C
I'm NOT an awesome programmer by any means. But I bet as far as someone that doesn't do it for a living, I'm damn good and could probably hang with a lot of pros.
I programmed 8510 assy. on my Commodore-128 as a kid. Yeah, I had to, due to limitations of basic.
There's NOTHING like knowing how a computer works to make a computer work, ya know?
--Jim (me)
Basically, I liked my education where I was taught concepts in the context of a language. You want to learn about memory allocation? Teach pointers and things in C. You want to learn about object oriented models... use Java or C++. You want to learn about how a computer functions at a base level, learn assembly. The language itself should never be the end goal, it should be a means to learn the concepts. The best programmers I've encountered are ones who have ideas, not ones who can't think outside a particular language.
"Oh dear, she's stuck in an infinite loop and he's an idiot" -Prof. Farnsworth (Futurama)
Perhaps it's time that computer science curriculums start teaching assembly language first.
Yeah, as a mathematics major I've often felt that number theory is glanced over far too often in high schools. Kids really ought to learn why 1+1=2 and how to strictly define multiplication of integers before getting into such oversimplifications of mathematics as the Pythagorean Theorem.
I think the submitter is proceeding from a false assumption. Anyone who's really pursuing a BS in Computer Science (from a reputable school, anyway) is probably going to get a course in assembly language whether they like it or not, and anyone who hasn't earned a BS shouldn't be calling themselves a "computer scientist."
JohnnyB, use your lightning powers to teach us ASM!
> 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.
...his site is at http://www.grc.com, he's got loads of security related info on his page and a shedload of Win32 progs coded entirely in assembler, every last line of em. He also created the very neat ShieldsUp tool to scare people into getting a personal firewall installed (like listing their netbios share names, doing a remote port scan and telling them the gory details of what people could do to their computer etc.).
Most of the progs are under 30k in size, including a very cool sub-pixel font-rendering demo, and ones to disable messenger, dcom and upnp. A really nice touch is that some of them have sound fx, produced by a simple virtual synth, also coded in assembler...just cause he could (a true geek!)
I am NaN
Sorry if this has already been mentioned, but the book is available for dowload from this site, under the filelist link. Here is a direct link to the pdf.
--
Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.
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.
..don't panic
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.
However, when my then employer needed a high performance CPU for their missiles, they designed what in later days would have been called a RISC chip. The instruction set was all of maybe 20, so few that many of us found ourselves coding patches directly in hex. There were just a few general purpose registers and four pages of memory to worry about.
It was elegant, straight forward, and only took a few sessions writing a patch to get the hang of. Once over the hurdle of writing a few lines on an embedded system like that, taking the next step and coding to an API of an open source system ain't too much bigger of a deal.
Luke, help me take this mask off
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.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
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.
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.
Who is Jon von Neumann? If you don't know and are planning on programming you should find out. Worse, if you already have a CS degree and don't know about "von Neumann" architecture then you missed am important topic.
....
If you want high performance code, you must understand procedural programming and assembly language. You must understand the components of the modern "von Neumann" architecture like RAM, Registeres, L1 cache, L2 cache, ALU etc
While everyone has gone OOP (Object Oriented) crazy, the "von Neumann" architecture is NOT optimized for OOP programming. Because modern CPU's have lots of cache, the latency that exists between the CPU and Memory is reduced. This is called "faking" memory bandwidth, read this article on the von Nuemann bottleneck.
Serious coders should learn ASM, then move to a higher level language like 'C' then see how the 'C' statements compile in ASM and then analyze efficiency.
Modern wisdom says, be wasteful, vendors will make bigger/faster machines and we won't have to care that our code is slow, inefficient, and not optimized for the architecture. Keep in mind, you can save substantially on hardware expenditures by hiring good coders that know how to tune and optimize code but, if you don't want to be bothered, just plan on large capital expenditures every couple of years. Also write everything is JAVA and make sure you create indexes on every column of every table in your database for faster lookups.. ( I am joking, don't really do this. )
When *I* was young we didn't *have* vacuum in space yet! You post-big-bang kids don't know how easy you have it!
--AROS is an Open Source AmigaOS clone, and source compatible with AmigaOS! Try the x86 build at http://www.aros.org
The correct answers are down there, but just to collect them and clarify - you can build anything using nothing but NANDS. Alternatively, you can build anything using nothing but XORS. You can prove this easily using demorgan's theorem.
However, in the real world, NANDS are cheap (2-3 transistors), so that's what everyone uses.
To make laws that man cannot, and will not obey, serves to bring all law into contempt.
--E.C. Stanton
Sounds like a bad idea to me, for reasons pointed out in other posts.
.
For a first course in CS, I think it would be hard to do better than one based on Structure and Interpretation of Computer Programs
This book takes one from zero to writing a compiler in a few hundred pages, including a chapter on writing code for register machines which gives the student a good idea of what is going on "under the hood."
To those who would say that Scheme is useless outside of academics, I would counter that once the concepts in this text are mastered, it is easy to transfer them to other languages.
These days, kids come out of school unable to manipulate simple pointers. Why? Because the sissy langauges they use don't even USE pointers, so they were never TAUGHT pointers. God forbid they have to figure out how a machine is going to execute their code!
What they do know how to do is read. They read what's going to happen in the future. They read about the NEXT version of Java and its speed and other associated wonders. They read about how feature xyz is supposed to work (I read the source code for feature xyz; it doesn't work that way). They read about the flying car they're going to be cruising around in in a few scant years.
As a fallen Java evangelist (not to pick on Java, but it deserves it), I've learned that there are a few constants in that particular language. It's slow as balls; it has been since I was using it in alpha 7 or 8 years ago, and every version promises that the next will be faster than C. Container-managed beans suck; for 5 years, they've been saying that the mythical container (read as: someone else) will magically optimize them, which we all know is bullox. The more fictional something is the more it's talked about; Java's been talking about Jini for something like 4 years now, with absolutely nothing to show for it.
If students spent more time learning assembly and less time fluffing around with "references" (which is short for "retarded pointers"), they'd be much more bitter and cynical... Like me.
:wq
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.
Join Tor today!
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.
plus-good, double-plus-good
Speaking from some experience (CS undergrad TA while in grad school)....
... wait for it ... PostScript. PS sounds wacky but it's the only stack based language widely used on modern computers (APL and Forth have died out).
...) had BASIC interpreters in ROM, and they were mostly OK, though the only one with a really good BASIC language (proper procedures, not GOSUB) was the Acorn BBC.
A few thoughts:
It's essential to teach some assembly at some point in a CS undergrad - A CS course should give full insight into the workings of a real CPU, and should give as wide a variety as possible.
At Edinburgh the first year CS course included assembly, C, and
When I was a CS undergrad we had practical classes in no fewer than 17 languages, covering the range of imperative, declarative, functional and stack based, plus specialist toys like theorem provers and SQL.
The best starting point for a university level course is the good old procedural language - in my day it was Pascal, C++ and Modula-3, these days I'd use Java (and many CS departments do).
Also, when you do get to assembler, I don't think using a real assembler is the best teaching tool - assemblers are intended for developing real low level code, or as back end targets for compilers. For teaching at Edinburgh, we used an X11 based tool called xspim which simulated a MIPS R2000 (we actually ran it on Sun Sparc-II's, not that it matters), and it let you single step and examine registers without the complexity of adding a debugger, and had a window where you could see the registers, CPU pipeline etc. displayed.
For introducing programming concepts to a younger audience I think an interpreted language which will execute command lines, allowing them to experiment while avoiding the edit-compile-run cycle, is very important. Some are better than others; when I was a kid the 8 bit micros (Apple, Commodore, Atari,
I don't like Pilot or Comal for teaching (failed experiments of the 1980's) but I think LOGO is a very commendable way to make concepts accessible to the young.
A perhaps unexpected place I was made to learn with an interpreted environment was as an undergrad at Cambridge University, where the first programming language taught is ML which for the CS people who haven't heard of is an implementation of lambda calculus with a sane syntax.
However, in the real world, NANDS are cheap (2-3 transistors), so that's what everyone uses.
Well, NANDs are easy to make with MOSFETs or vacuum tubes.
But I suggest that, in order to simplify the learning of digital logic and avoid this whole nastiness of DeMorgan, we should adopt relays as our primary logic device.
Think about it: two relays with their contacts in parallel = OR. Two relays with their contacts in series = AND. A relay with normally-closed contacts = NOT.
In this way, all design work can be done with natural logic (AND, OR, NOT) rather than "efficient" NAND, NOR, etc.
On top of that, your computer would make satisfying clicking sounds reminiscent of a pinball machine's scorekeeping system or an old elevator contoller, while you're crunching SETI@Home units.
I'm building a 4-bit binary full adder with nothing but relays in order to demonstrate their sheer computing power, and was hoping that someone could write me drivers to allow it to have practical uses.
Fire and Meat. Yummy.
That was in 1965 and the unit was the only one for our whole school district and worth about $30,000 (CDN - about $35000 US at the time)
From there to today's Object Oriented Programming languages has been an interesting time. I wouldn't have missed it for anything, and I honestly think that living through it has given me a perspective that many more recent programmers don't have and IMHO need, sometimes.
Where "brute force and ignorance" solutions are practical, there is no gain in knowing enough about the underlying hardware and bit twiddling to make things run 1000% faster after spending 6 months re-programming to manually optimize. In fact, since (C and other) compilers have become easily architecture tuned, there really are few areas where speed gains from hardware knowledge can be had, let alone made cost effective. Most are at the hardware interface level - the drivers - most recently USB for example.
If you're happy with programming Visual Basic and your employer can afford the hardware costs that ramping up your single CPU "solution" to deal with millions of visitors instead of hundreds, then you don't need to know anything about the underlying hardware at the bit level.
On the other hand, if you need to wring the most "visits" out of off-the-shelf hardware somehow, then you need to know enough to calculate the theoretical CPU cycles per visit.
Somewhere between these two extremes lies reality.
Today I use my hardware knowledge mostly as a "bullshit filter" when dealing with claims and statistics from various vendors. I have an empiric understanding of why (and under what circumstances) a processor with 512 Megs of level 1 cache and a front-side bus at 500MHz might be faster than a processor with 256 Megs of L1 cache and a 800MHz FSB and vice versa. Same thing for cost effectiveness of SCSI vs IDE when dealing with a database app vs. access to large images in a file system (something that came up today with a customer when spec'ing a pair of file servers, one for each type application)
Back in the mid 70s I dealt with people who optimized applications on million $ machines capable of about 100 online users at one time. Today I deal with optimization on $1000-$3000 machines with thousands of 'active' sessions and millions of 'hits' per day. Different situations but similar problems. Major difference is in the cost of "throwing hardware at the problem" (and throwing the operating systems to go with the HW - but then I use Linux so not much of a difference ;)
Bottom line is that understanding the underlying hardware helps me quite a bit - but only as a specialist in optimization and cost-effectiveness now, not in getting things to work at all as in the past.
Been there, done that, paid for the T-shirt
and didn't get it
I ended up teaching introductory Pascal back in the late '80s and found it to be useful only for teaching programming concepts but useless for teaching the students about how computers actually work. As an alternative to Pascal, I would choose FORTRAN over C because its possible to introduce students to things like internal representation without getting them tied up in their shorts over things like pass be reference vs. pass by value, pointers, etc. If C is bad, assembler is worse because the students will more likely get bogged down in nuances of assembly syntax. Also, if someone simply wants to learn how to program in C, I would suggest they buy "C for Dummies" and knock themselves out. On the otherhand, if someone wants to learn about how a computer works while at the same time being introduced to programming skills, debugging, etc., I'd go with something like FORTRAN as the teaching language.
The goal of a first "computer science" class should not be to merely teach technical skills (programming, debugging, program design) but to also give the students an understanding of how computers work. Even with today's proliferation of home computers, most people (student or otherwise) have utterly no idea how a computer works internally since their exposure is limited to simply installing software someone else wrote. Assembler is too far on the side of "how the CPU works" without giving the student any better insight into how the whole system actually operates (memory, CPU, storage, peripherals, etc.) than a higher level language while requiring much more effort by the student to accomplish anything useful. This would seem to indicate that a second generation language such as FORTRAN (or C) would be more likely to let the course delve into programming, machine operations, machine organization, etc. It also means that the students can produce "interesting" programs fairly early on which will keep more people interested (which would you rather have: a PHB MBA with no programming classes or one that has at least sat through enough classes to have some understanding of what goes on inside the box and how difficult that can be to accomplish).
One other complaint against assembler as an introductory teaching language is that, depending on the specific assembler, it is usually difficult to see the overall program structure even after the program is complete. This is primarily due to the low implementation level that leaves simple program controls (if-then-else, do-for, do-while, etc.) burried in the assembler syntax of loading and testing registers and smeared out over what is generally multiple individual statements. The student *may* end up with an appreciation of what it involves to implement these structures but will loose site of the tree (control structure) and never even notice the forrest (overall program design).
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
That's an old link - outdated version. Go to
http://savannah.nongnu.org/projects/pgubook/
Engineering and the Ultimate
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.
This strategy generally works better for Computer Engineers rather then Computer Scientists because what you are really learning with Assembly tends to be how the hardware functions. In fact if you are going to learn assembly, you could spend just another month and learn the basics of computer architecture. I feel like that is what really helped me de-mystify the computing process: the ability to trace back all the way to elementary physical processes, and see the computer as a almost a physical entity rather than a magical black box.
For an example of this, you can see Patt and Patel's "Introduction to Computing Systems:From bits and gates, to C and beyond." I took and TA for a course that uses this book.
-ashot
No one would really call the PDP-11 a CISC machine. You might call it a RISC VAX however (pause for audience laughter).
Also, many PDP-11's were random logic and not micro-coded. The later 11's were microcoded, of course, the 11/60 being the extreme because it had a writeable control store that let you define your own micro-coded instructions.
It's important to remember that the entire RT-11 operating system was written entirely in MACRO-11 by some amazing software engineers who knew the PDP-11 instruction set inside and out. The result was an operating system that ran very nicely in a 4K word footprint.
The VAX had a terrific compiler, BLISS-32, which created amazingly efficient code; code no human being would ever create but fantastic none-the-less.
Afterward a cute Pembroker in a really short skirt came up to introduce herself. I don't know if she agreed with our argument, but she's been my wife for quite awhile now. I don't teach much any more, but when I teach beginning CS, I teach assembler. The students we taught machine programming to back then have held positions like VP at Microsoft, CS Department Head at MIT, Princeton, Washington, UNH, and Waterloo.
I wish people wouldn't keep referring to C as a "programming language;" it's a pathology.
For what it's worth, they don't use just NANDs in cmos chip design in the real world. The primary primitive is the AND-OR-INVERT (AOI) structure.
In the cmos world, pass-gates are much cheaper than amplifying gates (in the size vs speed vs power tradeoff), although you can't put too many pass gates in a row (signal degradation). So in fact MUX (multiplexor to pass one of the two inputs using the control of a third) and XORS (use input A to pass either !B or B) are used quite a bit.
Some background might be helpful to think about the more complicated AOI struture, though...
In a cmos NAND-gate, the pull-up side is two p-type pass gates in parallel from the output to Vdd (the positive rail) so that if either of the two p-type gates is low, the output is pulled high. For the pull-down side, two n-type pass gates are in series to ground so both n-type gates have to be low before the output is pulled to ground. This gives us a total of 4 transistors for a cmos-nand where the longest pass gate depth is 2 (the pull-down). The pull-down is restricted to be the complement function of the pull-down in CMOS (otherwize either the pull-up and pull-down will fight or nobody will pull causing the output to float and/or oscillate).
A 2-input NOR gate has the p-type in series and the n-type in parallel (for the same # of transistors).
Due to a quirk of semi-conductor technology, n-type transistors are easier to make more powerfull than p-type so usually a NAND is often slightly faster than a NOR (the two series n-types in a NAND gate are better at pulling down than the two series p-types are at pulling up in a NOR gate). However, this isn't the end of the story...
Notice that you can build a 3-input NAND by just adding more p-type transistors in parallel to the pull-up and more n-type in series to the pull-down. You can make even more complicated logic by putting the pull-up and pull-down transistor in combinations of series and parallel configurations. The most interesting cmos configurations are called AOI (and-or-invert) since they are the ones you can make with simple parallel chains of pass transistors in series for pull-up and pull-down.
For most cmos semi-conductor technologies, you are limited to about 4 pass gates in series or parallel before the noise margin starts to kill you and you need to stop using pass gates and just start a new amplifying "gate". Thus most chips are designed to use 4 input AOI gates where possible and smaller gates to finish out the logic implementation.
Thus "everyone" really uses lots of different types of gates (including simple NAND and XORS as well as more complicated AOI).
Switching a task in an OS is called context switching. This means that the OS saves all of the registers used by the application, and then loads up the saved registers of the task you are switching to. When this task has ended, or another context switch occurs, the registers of the saved task are then reloaded.
If you go to www.google.com and look up context switching you should be able to find all the information you'll ever need!
Paint.NET, a Free Image Editor, with Source Code Available!
I understand that much of C was inspired by that instruction set.
I'm not sure inspired would be the right way to say that. C was invented a shorthand for assembler, in particular PDP-11 assembler. I'm probably just being pedantic but I think it's an important distinction.
We owe a lot to those machines, by '74 UNIX and C were available (barely) from Bell Labs but by the late summer of 76 Dave Conroy at Teklogix in Mississauga, Ontario, had written and made work the only C compiler not written by Bell Labs, which ran under RSX-11M. This became DECUS C, and then gcc.
I worked there between high school and university ; Dave taught me C to test his compiler and must have got all of about $1200 for writing it as it only took him a few weeks. It was of course written entirely in assembler.
Need Mercedes parts ?
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).
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.
Ladies and Gentlemen of the Slashdot community... Code in C.
/opt directory thinking it to be "optional" while trying to make space for his porn collection, or a lethal bug in your fancy CASE tool.
If I could offer you only one tip for your future as programmers, C would be it. The long-term benefits of C have been proved by scientists, and academics, and professionals, and corporations all over the world, whereas the rest of my advice has no basis more reliable than a Microsoft marketing report. I will dispense this advice now.
Enjoy the power and beauty of simple command line tools. Oh never mind, you will not understand the benefits of vi, make, grep and gcc until you're working as a contractor, and that fancy environment you have at home isn't available. But trust me, in 5 years, you'll sit down in front of an expensive IDE, pore over the GUI menus and checkboxes, read the badly written two-inch-thick manual twice, and still not be able to write a program to say "Hello World!" You'll then recall in a way you can't grasp now, the importance of understanding how to get useful work done with the standard, simple tools.
Don't worry about not using the latest and greatest Microsoft tools or language; or worry, but know that worrying is as effective as watching all your carefully crafted code fail because a registry setting or dll you depend on was changed by the installation of some do-nothing program. The real troubles in your programming career are apt to be things that never crossed your worried mind; like a middle manager who wipes out the
Write one script every day to aid you.
csh!
Don't be reckless with other people's test procedures, don't put up with people who are reckless with yours.
Lint.
Don't waste time on hand-optimizing your code; sometimes you're elegant, sometimes you're a kludge... The optimizing compiler will do it better anyway, and in the end you'll have to maintain the source code - so keep it readable.
Remember the useful code snippets you receive, forget the cruft. If you succeed in putting together an elegant an efficient source "proverb" library, send it to me.
Keep a logbook of your programming efforts. Toss your core dumps.
Top.
Don't feel guilty about not following a particular development methodology completely. The most useful programs I've seen have been cobbled together ad hoc. Projects I've seen follow the Rational Unified Process, Extreme Programming or Aspect Oriented Programming methodologies to the letter, dies over budget and behind schedule.
Get comfortable with revision control.
Be kind to your O'Reilly books. You'll miss them when they're gone.
Maybe you'll become famous, maybe you won't, maybe you'll win the Turing, maybe you won't, maybe your codified soul will be ignored sight unseen, maybe you'll crank out the next Mosaic... Whatever you do, don't congratulate yourself too much or berate yourself either - the commercial success of your program depends more on the whims of lawyers and marketing drones than on the technical merits of your application or the effort you've put in. So does everybody else's.
Enjoy your home computer, use it every way you can... Don't just use it to hack away at code or to automate your bedroom lights or to run a website, it's the greatest tool for self-expression you'll ever own.
Learn... even if you have nowhere to do it but from a weblog forum. Read the responses, even if you don't agree with them. Do NOT read Ziff-Davis magazines, they will only make you feel like a long-haired, smelly zealot.
Get to know your kernel, you never know when you'll need to recompile it yourself. Be prudent about your patches, they are the best trace of development and the means most likely to keep you safe and relevant in the future.
Understand that CASE, GUI and other developer tools come and go, but for the precious few you should truly know. Work hard to bridge the gaps between convenience and uti
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
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.
Do daemons dream of electric sleep()?
I definitely agree with the idea that computer programmers need to learn assembly, and other low-level programming skills. I started my education as an Electronics Engineering Technician in D.C., (i used to teach NSA techs how to build FM radios in the electronics lab) Anyway... my career has been mostly writing macros, maintaining networks, user support, light engineering, etc. and I feel that my in-depth knowledge of computers has helped me immeasureably in these higher-level areas of software maintenance. I laugh at "micosofties" that graduate from colleges here in Northeast PA with their MCSE... I outperform them on a regular basis.
In 1978 I had a liberal arts degree and no job. I borrowed $2000 and went to a trade school to learn computer programming. That $2000 has paid off big time of the last 26 years and continues to do so. The course started with a simulated, 1000-memory-cell decimal "computer"; we programmed it in assembler. We then went to IBM 360-style assembler (all this was on punched cards), followed by Fortran, RPG, and COBOL.
I got a job right away for a company that made data comm hardware and, naturally, used assembler. I didn't touch a high-level language till 1984 (and that was C).
As the years have gone by, the trade (NOT profession!) has become more and more the domain of the "computer scientist". These are the guys who learned how to write compilers in school. Often, they're disappointed when the job involves something more mundane. These are also the guys who have trouble with pointers and other basic concepts because they don't really know what's going on on the machines they program.
German machinists used to spend a year doing nothing but filing as part of their training. Nothing but filing. These were people who honored their craft. Assembler is the computer equivalent. Without it, you might be a "scientist", but you'll be a lousy craftsman.
I once worked for a guy who learned programming in the Air Force in the 60's. His motto: "It's all just loads and stores and branches."
It's a contrived simple assembler they used to use at AT&T to teach programmers assembler. This is not a new concept. This kind of touches on one of my themes, that being that most younger computer science people are mere technicians who are in the field to make money, not because they love it. They don't have a clue about the history of their discipline, nor do they care. I really see this in the the 15 to 30 year olds. 99 times out of 100 they really don't have much of a clue. In a way I feel sad for them, because they didn't experience things before the huge monolithic companies (you know the cube farm sweat shops like Adobe and Apple and Microsoft) got on the scene and pushed lots of wonderful products off the market through business muscle and not survival of the best product. I also feel sad when I try to hire people. Most graduates that I interview know a whole bunch about Visual Basic and SQL, and not much else. (In other words they have no real training at all)