"Chris Jones" <cjns1...@gmail.com> wrote: > Intellectually, assembler programming is the less demanding since its > level of abstraction does not go any further than mapping a few binary > numbers to a small set of usually well-chosen mnemonics.
This is the surface complexity - it is true that when you write an assembler statement, you know exactly *what* it is going to do. The *why*, however, is not always as obvious, as it entails keeping far more *registers and memory locations* alive in your mind as you go - and the temptation is great, for efficiency's sake, to let a series of calls leave their answers *in place*, ready for the next call to use: call this jc error_handling call that jc error_handling call thenextthing jc error_handling ... This kind of thing is in a way worse than spaghetti, and it is about the hardest thing to understand that I know of. It is also fragile, as you are never sure if you change something, no matter how well documented your individual routines are, what the effect of a change somewhere will have somewhere further down the line, as the parameters are not explicitly named before the calls. I find higher level languages a lot easier to read because of this. You can do the same kind of thing in Python, using globals, and if there are enough of them, it will be just as hard to follow. > Unless it features a powerful macro-language that lets the apprentice > create his own high-level patois on top of the assembler, that is. This is the fun part of assembly programming - and here again, one has to exercise restraint, or the "language" becomes baroque. Used correctly, however, it allows you to generate a lot of required boilerplate with very few keystrokes. It is also very useful to create application specific virtual machines with specialised *instruction sets* which can make solving some problems a lot easier. - and that is a level of abstraction that is in a sense orthogonal to the levels of abstraction brought to the party by a high level language that has a simple von Neumann machine as it's base assumption. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list