> -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > [email protected]] On Behalf Of Rob van der Heij > Sent: 22 January 2018 11:05 > To: [email protected] > Subject: Re: Fair comparison C vs HLASM > > On 22 January 2018 at 07:47, Jon Perryman <[email protected]> wrote: > > > I find it amazing how C programmers believe in the superiority despite > > overwhelming evidence to the contrary. Surprisingly, the psychological > > term for this is "motivated reasoning" and I never believed it until > > now. Below actually transpired yet they still believe that C is > > superior (even with an examples). > > > > I hope you also have other New Year's Resolutions like to give up smoking; > probably easier than a programming language fight :-) > > HLASM (with the macro libraries written over the past 40 years) gets beyond > what many people think of when you mention assembler language. Many > with a strong opinion base that on hearsay or lack of familiarity. A > Structured > Programming macro library can help avoid goto-spaghetti. The one I use for > CMS Pipelines also adds a procedure concept to do flexible calling of > subroutines. I would not have benefit of using C except when I can take code > written by someone else. If you want to disagree about "superior" you might > first have to agree on the criteria. The least number of non-blank lines or > characters? Shortest execution time? If C were superior, why have so many > new languages been developed based on it? ;-) > > Many say the strong point of C is the availability of libraries to call. > Obviously assembler routines can call subroutines and most of us have > extensive libraries available. You can even write HLASM macros to check > parameter lists similar to function prototypes in C. If you put in some effort > to initialize the runtime environment, you can call those C routines from > assembler code as well. But this is nothing compared to the function call > mechanisms in Python for example. > > There's probably a good use case for each of the thousands of programming > languages, but how would you pick the right tool for the job? I would say that > when you are comfortable with half a dozen languages in different classes, > you have a good basis to pick the proper tool for the job. As for your > example, I would not try to parse XML in either C or assembler, unless it's > really a very trivial case. You're probably better off with a generic XML > parser > to build an abstract tree in memory, or specify the program for an XML > stream processor. Or have lexx and yacc generate the code to parse your > grammar if you don't expect it to be extended often. > > Rob
Folks, Having lived in the Honeywell world of systems programming, where I "moved" from GMAP to B I would say that for many tasks "C" is superior to both "B" and Assembler. On the Honeywell we delivered many products and tool sets that we could not have done with the programming resource and machine time available using Assember code, even though GMAP had similar Macro tool kits to those in HLASM. You may wish to dispute this, but a typical programmer will be more productive in "C" than Assembler. Dave
