Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!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: <10330096@accuvax.nwu.edu>
Date: 6 Dec 88 14:26:24 GMT
References: <6176@fluke.COM>
Organization: Northwestern U, Evanston IL, USA
Lines: 60

Responding to flame #512...

>>1) Assembler is not portable. Fine. Who cares? No seriously, think about this:
>>when you start to worry about portability, you start shooting for the lowest
>>common denominator. Programs should _not_ be portable for machines like the
>>Macintosh - you will be putting blinders on yourself, and forcing yourself
>>to ignore features of the machine. (Data files, on the other hand, do not
>>depend on the machine as heavily, and should be portable).

>Um, have you written much software?  An awful lot of software is in the
>form of distinct modules which could theoretically be used in lots of
>different programs with no changes.  For instance, encryption or
>database-file packages, or network protocol implementations.  There's
>every reason for this kind of software to be as portable as possible
>across OS and processor lines.

Let me back off from this one a little - I didn't state it very well. (Yes, 
I have written a lot of software - for almost 12 years now). I think the above
statements have more to do with cold-killers than reality. 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.
There seems to be an ugly trend toward "totally" portable code - this can
only lead to lowest common denominator code.
 
>>2) Assembler does not immediately lead to the dreaded spaghetti code.
>>Assembler can be (almost) as structured as Pascal, but doesn't get in your
>>way when structured programming is a pain.

>Baloney.  Even VAX assembler isn't as well-structured as Pascal or C.
>If you have to simulate structured constructs using GOTOs, it isn't
>structured.  If you have to write arithmetic expressions using two or
>three operand arithmetic, it isn't structured.  The constant necessary
>use of GOTOs makes spaghetti code almost impossible to resist -- "This
>almost works -- all I have to do is put in a conditional branch bavck
>to instruction 32!"

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.

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...

>>3) I also disagree that assembler is inappropriate for large projects, but 
>>I've had enough flaming for today.

>On this point, I think I agree, more or less.  There really isn't any reason
>assembler can't be just as modular and well-defined as high-level languages.
>It's less self-defining, at least as usually written, but large projects
>require external module specifications anyway.

You mean someone agrees with me?? On anything? Oh, my heart... :-) 

Bob Hablutzel	BOB@NUACC.ACNS.NWU.EDU