As a woman: A female track star who holds all the world speed records. She is hard and bumpy, and so is not that pleasant to embrace. She can cook up any meal, but needs a complete and detailed recipe. She is not beautiful or educated, and speaks in monosyllables like "MOV, JUMP, INC". She has a fierce and violent temper that make her the choice of last resort.
Shooting your foot: You crash the OS and overwrite the root disk. The system administrator arrives and shoots you in the foot. After a moment of contemplation, the administrator shoots himself in the foot and then hops around the room rabidly shooting at everyone in sight.
or: After looking through serveral hundreds of pages of documentation you finally come up with a couple of hundred lines of code. It assembles excellently but when run, you discover you overlooked the direction flag and ended up shooting yourself in the head instead of the foot.
- found on the net in Tallus Humor Archives (I think)
Great - if you like reinventing the wheel each time you program.
All right, a bit exagerated. Many assemblers supports macro's and procedures, but it still takes a lot of work and code to get anywhere in pure assembler. I disrecommend developing anything larger that 100 codelines in assembler - it is simply to simple. Do not misunderstand me - it is simple in the sense that you access the hardware directly, and therefore need to know quite a lot of details.
Assembler is suitable for creating small subroutines, that need to be called serveral thousands of times during an application run. Eg. we were a couple of guys working on a project where we needed to reset memory areas quite often, and thus needed a very fast routine for this. In a high-level language, the routine took more than 10 msec, where highly optimized assembler took 2.5 msec (that is 1/4 of the original time). Now imagine that routine is called more than 100000 times during the execution - that is 1000 secs decreased to 250 secs!
But assembler is a difficult science - you need to know a lot about the CPU, that executes your program, and that cannot be ported to another machine. Likewise with the code - it cannot be run on other machines. But on the other hand - it is a challenge to write assembler - imagine working with 4 fast variables and 2 pointers and trying to avoid using other for speed considerations - it is fun.
Fun, but not for humans.
Another problem with assembler is the fact that to use it, you need to learn the mnemonics (short names easy to remember) for each operation available on the CPU, because you write the list of instructions to the CPU in a series of mnemonics. The problem comes when you want to port something to another machine - it hardly has the same operations and thus you will need to rewrite the entire program. Plus if you want to change your machine, you'll need to learn a whole new set of instructions. One could argue, that in these Intel-times, you only need to learn one instruction set, but you're wrong - the EPIC won't use the same set (actually, I doubt that an assembler will be publicly available), and other architectures with more power than the x86 will hopefully emerge.
There was a time, now gone, where practically all software for the computers (there where perhaps a couple of thousands in the world) where written in assembler (on punched cards!), and much of the software for the mainframes are still written in assembler.
So my recommendations, if you program a lot and expect to make a living on it - better learn what an assembler is - not nescesary to master it. If you only program once in a while - KEEP AWAY, do not start messing with assembler, it is really not worth your effort.