Rob, what python call mechanism are you referring to? Are you talking about OOP that was taken from C++?
You missed the point. Superiority is not about number of lines, optimal code, opinions or preferences. As a programmer, it's about what designs are you willing to implement in the programming language of you choice? What problems are you willing to solve before you consider the solution too complex to code, maintain and upgrade? C is a simple language with many functions. For straight forward programming logic, C is fine. When it's a complex problem, it's not so great. Programmers will not use a complex implementation. Below, I discuss XML to make this clear. Before I do, let me show it's not an isolated issue. Consider MVS with all it's cool features that are accessible thru SYS1.MACLIB. Don't take SYS1.MACLIB so literally. Think about how easily we access those features in HLASM. Show me any possible C implementation that would make it easy to access these features in C (and most other languages too). With that implementation, would a programmer use that feature in C? Is that feature complex to use? Case in point would be I/O. In Unix, you get 1 very basic I/O method (file streams) without records because records and advanced MVS I/O techniques were too complex for a C usage implementation (you can use structures but it's not that common). Making the DCB / ACB features available to C programmers would be a usage nightmare. This choice has led Unix to a problem called "BIG DATA". Companies are struggling to solve the big data problem. It's rare that anyone considers MVS I/O as a brilliant idea nor do they understand why it is so revolutionary. The Unix big data problem is simply where data gets out of hand within the scope of available resources (e.g. an overused small amount of data). In Unix, most often the solution is to analyze and modify all the programs involved to use an SQL database. MVS programmers have several easy solutions before they must resort to an SQL database. If they must resort to an SQL database, they are ready because they designed the data around records. Think about why MVS I/O is such a brilliant idea. Programmers avoid SQL & databases because they require work and maintenance. On the other hand, MVS can often solve the problem without modifying a single program. E.g. convert the file to VSAM and turn on RLS. Define shared resources. Change I/O prioritization. Convert the file to a VSAM KSDS and modify the programs that would benefit from keyed access. We can use record locks instead of data enqueues. I'm sure there are more but you get the idea. C and Unix are about me (the programmer). I have complete flexibility and can do anything I want. The problem is that everything is the programmers responsibility and they must think about how they need to access data and how to secure it. MVS is about what's best for the company. Programmers are given wise choices. HLASM makes it easy to provide what programmers need to get the job done efficiently and easily. At the beginning, I mentioned using XML to demonstrate one of the basic problems with C. There must be over a hundred (red flag 1) available and most written in C. Most are variations of the same basic concept (implement new programming language referred to as a schema (red flag 2) and require 3 user functions be written (element start, element data, element end)(red flag 3)). If you recall my pseudo C logic, it was wrong but no one complained (red flag 4). We only wish it was that easy to code and understand (e.g. you maintain a list of the active lists in proper sequence or add a schema). It only included 5 elements but would certainly be far more complicated with 30, 40 or more elements. Truthfully, it was just easier to code in assembler than integrate an existing XML parser. If C had macro's and loctr, you could code a single statement to populate all 3 functions (element start, element data, element end) and generate the schema required by the C XML parser. As I said before, HLASM is a non-linear programming language. Regards, Jon. On Monday, January 22, 2018 3: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
