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?