Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!ncar!tank!nucsrl!accuvax.nwu.edu!bob
From: bob@accuvax.nwu.edu (Bob Hablutzel)
Newsgroups: comp.sys.mac
Subject: Re: The Mythical Man Month
Message-ID: <10330098@accuvax.nwu.edu>
Date: 8 Dec 88 14:11:59 GMT
References: <6176@fluke.COM>
Organization: Northwestern U, Evanston IL, USA
Lines: 93

>>Responding to flame #512...

>If you don't want to be flamed in return, don't express your views as flames
>in the first place.

If I flamed, I'm sorry. Really. I didn't intend this to be an ongoing thread,
and I frankly don't even remember what started this whole thing. I've been
a bit more dogmatic about this subject than I should be, and I apologize.
However, I still stand behind my original premise - for people who are 
sufficiently familiar with assembler, there is no reason not to use it freely,
and that hand written assembler code will be more efficient than code output
from a compiler, simply because of the nature of compilers.

These statements I still stand behind. 

>>I will agree that
>>purely mathematical, or "semi-numeric" type problems, are good candidates for
>>high level languages (assuming decent compilers are available, and these
>>routines are not critical ones). What I really meant to attack is the use of
>>portability for things like user interface code, file system interaction, etc.

>Encryption may be a mathematical problem, but network protocols and database
>file access packages are not.  Care to respond to my point?  Most software
>which is not directly interfaced to the user benefits from portability,
>not just mathematical packages.

I guess it depends on the level of code you are talking about. With no
standardized methods of talking to hardware, at some point the code will
not be portable. _This_ code is what I'm singling out for a good assembly
candidate - the code will be executed often, the user will benefit from
the speed, etc. I'm not talking about drivers, which are obvious, but about
the code which talks directly to the drivers. (On the Mac, it's the
difference between calling glue routines (PBRead) instead of the ultimate
call to the (Read)). With a modularized program, and development system that
permits it, these routines could be localized, and optimized.

>>I didn't say that assemblers were structured, I said that you could write
>>"almost" structured code in assembler. What this means is (a) not giving
>>in to temptation like the instruction 32 problem, and (b) hand writing
>>code similar to what the compiler is going to generate anyhow (for the 
>>placement of GOTOs to simulate loop constructs). I am considering structured
>>programming as a style, not as a formal definition, here.

>The temptation to write spaghetti code will, in this universe of flawed
>humans, lead to spaghetti code.  Maybe in Heaven everyone uses
>assembler and simulates compiled constructs, but not down here in
>Heck.  Giving people tools that encourage them to shoot themselves in
>the foot and then blaming them for their lack of toes is silly.

You can write lousy code in a structured language, as well. My point is this:
don't blame the _tool_ for the lack of discipline in the programmer. 

>>I am curious, however, as to why multiple arithmetic instructions makes a
>>program non-structured. Can you clarify this? I understood structured 
>>programming as a flow control disciple, but maybe I should go review...

>The superiority of writing infix expresions instead of two-operand or
>three-operand opcodes in a linear sequence is sufficiently obvious that
>it wasn't even mentioned by Dijkstra, to my knowledge.  Readability,
>modifiability, reduction in complexity (no register management), etc.,
>all pertain to writing infix arithmetic expressions, and all are
>motivations of structured programming as well.

That's fine, and I agree - Infix is more readable than assembler. No problem
there. I was just wondering about the structured programming aspect - I 
didn't remember infixing being a part of it. Even _I_ would rather use
Pascal (Fortran, etc) for heavy math than assembler. 

>Frankly, Bob, I think it's obvious to everyone reading your messages
>that you're making up bogus rationales for a personal, subjective
>preference.  Why not just admit that you like assembler for personal
>reasons and that it doesn't really have any general superiority over
>high-level languages?

Well, if this is the impression I've given, I'm sorry. I don't think assembler
is generally superior to high-level languages, and if I said that, I 
hereby retract that. What I do think, however, is that when you choose high-
level language as your tool, you are gaining some things (automatic register
tracking, loop constructs, etc), and losing others (speed and size). It's
up to individual programmer. You're right - assembler is a personal 
preference. What I wish is that people would admit that assembler does
have some advantages (as well as drawbacks) against high level languages.
It's a different, but still a viable, world.

I say this from experience - it's the reason I switched to assembler. In
every non-trivial case, coded written in assembler will take longer, run
faster, produce a smaller executable, and be less readable than high level
languages. 

> Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim

Bob Habluztel	BOB@NUACC.ACNS.NWU.EDU
Disclaimer:	I'm getting less cranky - wanna talk politics?