On 7/18/23 23:24, Jon Perryman wrote:
I'm not hating on C. It's silly to say that C hardware near. I would say less
than 5% of the x86 or z instructions are used by the language. Look at the x86
instruction manual or the IBM POPS. Do you think malloc is written in C? C
gives you access assembler at a minimum, there is an assembler SVC coded in the
C program. Only assembler is hardware near.
Apologies for not being more clear.
I was trying to say that C is as close as I (personally) can get to the
hardware and yet be portable.
Compare C with any assembler, and no, it's not "hardware near". But it
IS portable, which no assembler can be, by nature of assemblers.
C is not a good language for solving complicated problems because it over
complicates solutions. Without the macro language in assembler, it would have
the same problems. Ask yourself, how would you implement STORAGE, DCB, OPEN or
other macro important system macro. Would you create a struct and fill it in?
Would you have various calls with various parameter lists. How would you
validate that the correct combination of arguments have been coded.
It's fair to say, even with the sophisticated macro capability of HLASM,
any assembler is "not a good language for solving complicated problems".
At least, not any better than C. Complicated problems are where one
wants "up stack" languages (Java perhaps, or Rexx, or Python, or even
Tcl). C is tedious. Assembler is also tedious. With stock macros (that
we all use), HLASM is much less tedious than other assemblers, but is
not less tedious than C.
I see that I presumed upon combining languages. I do realize that few
projects start out intentionally using more than one language. Doing
selective details in C or assembler while doing "big stuff" in Python or
Rexx is better (for many projects) than doing the whole work in just one
language.
I am surprised, and sorry, that my post has led to some flamage.
I had not considered that our various opinions would drag us so far from
objectivity.
-- R; <><
