I'd like to hear other opinions about this comparison of C/C++ and HLAsm. The comparison revealed some interesting insights between C/C++ and HLAsm but was not as helpful as I wished because the products solved very different problems. There is a lot of motivated reasoning used when discussing C/C++ that doesn't match reality. I'm not saying this is a bad thing because we all have our personal preferences and we need to validate those choices of which I too am guilty. In my opinion, if you feel more effective using HLAsm with macros and it meets all your requirements, then you should code in HLAsm. In my case, I lose more in C/C++ than I gain for the projects I've worked on.
Google did a complete rewrite of C/C++ and called it GOLANG because they refused to slap more lipstick on this pig. They did a great job which also included important HLAsm features that do not exist in C/C++. We underestimate IBM smart design and the role HLAsm played in making z/OS vastly superior to Unix. GOLANG is not a cool kids language. It is a business replacement for C/C++ albeit slow in converting because of GOLANG decisions. I'm not advocating for any specific language but most people ignore the impact that programming languages have on our design decisions. MVS would not exist if IBM coded it in C instead of Ibm assembler macros. my 80,000 lines of HLAsm versus 32,000 lines of C++ code seems substantial until you realize that I dealt with more than 20 very unique events versus 3, several very unique user interfaces versus 1, an automation log versus joblog, 11,000 lines of msgs / msg doc versus less than 500 and I could go on. While we can't say with any certainty, we know the C++ version of automation would be far more than 32,000 lines making the HLAsm implementation less than double. I'm guessing around 1.5. "Add another function call" mentality is normal in Unix instead of keyword parms. GOLANG dropped KEYWORD= support in function calls because no one (except IBM) ever used it. In C/C++, IBM completely deviated from the norm by extending OPEN(dsn, RECFM=FB, LRECL=100). GOLANG forced IBM somewhat closer to the norm with ZOSRECORDIO.OPEN(dsn, "RECFM=FB, LRECL=100") but anyone else would have required more than 1 function call. "Add another function call" mentality encourages bad design. It's been said that HLAsm attach is egregious compared to C/C++ pthread but that ignores 1 ATTACH versus more than 50 pthread functions. It also ignores when and where pthread functions must be called (attached task / attacher task). GOLANG removed pthread altogether for good reason. GOROUTINES encourage multi-tasking mentality by providing the bare minimum suitable for most needs instead of all possible scenarios. With many business computers now exceeding 24 CPUs, multi-tasking simplicity is far more important (e.g. Kubernetes cloud containers). Macro languages play a critical role in many programming languages. Evolving OS/VS1 to z/OS was only possible with the IBM assembler macro language regardless of the programming language being used. For example, consider the stagnation of file processing on OS's written in C. Unix files have not changed since 1969. z/OS files (DFSMS) documentation is now 50 manuals because of the DCB macro. DCB is not possible in C without thousands of functions. C/C++ macro support was dropped from GOLANG because it served no useful purpose and caused bad programming practices. GOLANG chose to implement macro support consistent with other programming languages (Python, Java, JavaScript, Perl, PHP and more) which provide functionality similar to IBM HLAsm macro language but at runtime instead of compile time. Macro languages are now implemented as follows: 1. The macro language is the programming language thus no macro language documentation. 2. The macro language must be compiled and run. Everything is runtime. Nothing is compile time. You can't warn the programmer of problems during compile time. You can't eliminate overhead by moving logic into compile time. 3. These languages have "reflection" which is the ability to extract program information. In terms of an HLAsm macro, it can get field information (e.g. t'x or l'x) or instruction information using OPSYN to a macro. Reflection is far more advanced compared to HLAsm macros. 4. I disklike that in GOLANG, it's difficult to insert code like an HLAsm macro. Instead, you must design to build new source and compile. This somewhat complicates their use and takes time to become accustomed. Most people ignore that C/C++ and HLAsm are very outdated languages. C/C++ is constantly upgraded but to no avail thus the need for GOLANG. HLAsm has been a stagnant language for years. HLAsm hasn't replaced its macro language despite REXX replacing runtime languages everywhere else. Despite the ability to create HLasm macros like my #CALC, IBM hasn't made the HLAsm toolkit more friendly and usable.
