> -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of William M Klein > Sent: 08 April 2011 05:34 > To: [email protected] > Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!) > > > > -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] > On Behalf Of Sam Siegel > Sent: Thursday, April 07, 2011 4:30 PM > To: [email protected] > Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!) > > On Thu, Apr 7, 2011 at 1:46 PM, McKown, John > <[email protected]> wrote: > >> -----Original Message----- > >> From: IBM Mainframe Assembler List > >> [mailto:[email protected]] On Behalf Of Sam Siegel > >> Sent: Thursday, April 07, 2011 3:41 PM > >> To: [email protected] > >> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - > >> SOLVED!) > > <snip> > >> It is a non-sequitur to say knowing a certain programing language > >> makes you better at designing and implementing algorithms. > Analysis > >> of algorithms is more of a mathematical endeavor than a language > >> endeavor. > >> > > > > True. What I meant, sort of, was "in my experience people who know > assembler also tend to be better at algorithms" I don't say > it is a causal relationship, just that it seems that > assembler people also tend to have stronger skills at > algorithms. Personal opinion based on "gut feel". Like the > perception that "geeks have poor social skills". > > > > That makes sense in the IBM asm/cobol world. I guess the > Microsoft analogy would be C programmer versus an visual > basic programmer. Where, in general, the C program would be > thought of as having better algorithm skills. > > -----End Original Message----- > > As a "COBOL bigot", I think it is probably true that "good > assembler" programmers OFTEN create "better performing" > algorithms than "good COBOL programmers". This isn't > universally true (and I don't think anyone has claimed that it is). > > What is EQUALLY true is that often (not always) a COBOL > program is designed to be "easily maintained" ("readability") > and to be "patched" at 3am by someone who has never seen the code. > > Assembler is "readable" to Assembler programmers (just as > COBOL is readable to COBOL programmers). > > HOWEVER, those same things that make for good (performing) > Assembler programs are often the "easiest" things to miss > during regular or emergency maintenance. "Good" internal > documentation can help, but COBOL's (claimed whether proved > or not) "self-documenting" nature does allow for "bad" but > "understandable" algorithms. > > I think one point you have missed is that perhaps the utility of assembler depends of the target machine. So the 360 architecture with its 16 general purpose registers, orthognal instruction set, and powerful macro assembler makes for great code writing. Try doing the same on an 8080 derived machine where you have fewer registers and many have dedicated use. YUK...
Any you can write obscure code in any language if you try hard enough. On the other hand simple code can have hard to find bugs. I don't program very often at all but I got caught out in a simple bit of VBSCRIPT the other day. Any way I spent an hour trying to find out why a compare that I was sure was equal , wasn't. Turns out the string I had read in had enclosing quotes as part of its data value, so it contained "TC" INCLUDING the " marks. Yuk. Dave
