Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac Subject: Re: The Mythical Man Month Message-ID: <6013@hoptoad.uucp> Date: 7 Dec 88 20:32:12 GMT References: <6176@fluke.COM> <10330096@accuvax.nwu.edu> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 63 In article <10330096@accuvax.nwu.edu> bob@accuvax.nwu.edu (Bob Hablutzel) wrote: >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. >>>1) Assembler is not portable. Fine. Who cares? >>>When you start to worry about portability, you start shooting for the lowest >>>common denominator. > >>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. > >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. 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 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. >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. 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? -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I've got troubles of my own, and you can't help me out. So take your meditations and your preparations and ram it up yer snout!" - Frank Zappa, "Kozmik Debris"