In the open source project that I maintain, I use C when I have to interface with the source library (written in C) or with LE languages. I avoid using complex macros and I keep it simple. I have mercy on people who may need to read my code. And that is because I've found that it is difficult to read C code that is peppered with unnecessary macros.OTH, when I need to interface with Rexx, HLASM is the king.My point is that as always, one may and should use the right tool, and avoide abuse of the tool. The problem is once one is inside the culture, he or she do not necessarily see the abuse as suchZe'ev Atlas
Sent from Yahoo Mail on Android On Mon, Jan 22, 2018 at 6:05 AM, Rob van der Heij<[email protected]> wrote: 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
