It's important to understand that raw assembly language has no structure. That is one of the reasons why use of assembly language in most aspects of computing has greatly diminished.
Hmmm.... So, what is your take on projects like
High Level Assembly (HLA)?
It's nothing about which I could get excited. Randall Hyde has great credentials, has written a fine book about assembly language and all that, but I think is a bit misguided with this concept.
The very name "high level assembly" is an oxymoron. Assembly language is, by definition, the lowest level at which you can program a computer, short of manually poking bytes into RAM with a panel of switches and push buttons. As soon as you are insulated from the assembler, which is what "high level assembly" is doing, you are no longer programming in assembly language. If you want that much insulation you might as well fire up a COBOL compiler or a BASIC interpreter.
Programs are written in assembly language so as to avoid the performance issues that are present to some extent in all high level languages, compiled or interpreted. Also, sometimes assembly language is the only way to accomplish something, or to accomplish something in an efficient manner, especially on small 8- and 16-bit systems such as what we build.
To quote that Wikipedia article:
It uses a syntax loosely based on several high-level programming languages (HLLs), such as Pascal, Ada, Modula-2, and C++, to allow creating readable assembly language programs, and to allow HLL programmers to learn HLA as fast as possible.
That doesn't sound like assembly language to me. Instead, it sounds like illustrating a landscape by connecting the dots. Just what is it someone would learn from a mish-mash of Pascal, Ada (the ultimate designed-by-a-committee programming language), etc? And don't get me started on C++, what I consider to be the ultimate bloatware language.
As for "creating readable assembly language programs," there's this little thing called a comment, which if judiciously used in assembly language source code, makes the program eminently readable. Good commenting is the heart of writing understandable programs in any language. If the programmer can't explain in his/her comments what the program is doing then he/she doesn't know what it's doing. Perhaps Mr. Hyde should hammer that home to his followers.
Both Garth and I strongly advocate for the use of macros in assembly language programs, especially large programs. Macros allow you to add some higher-level features to your programs without sacrificing the inherent speed and flexibility of assembly language. A well-chosen macro name can make for very readable code. Macros can also be invaluable for reducing errors, as a properly-structured macro will report an assembly time error that might go undetected in raw assembly language (e.g., missing parameters).
That said, nothing can beat the performance of assembly language that has been hand-optimized to produce the tightest loops and smallest code. You can't do that when the language does all sorts of hand-holding for you. The folks who developed action games for machines like the Commodore 64 understood that 37 years ago. It's still true today.