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
