Re: Future of RPG: What language would you learn?

In the late 1970s, some large government organizations running IBM mainframes purposely trained their application programmers in PL/I because, if they trained them in COBOL, they would leave after a year or so, for better-paying jobs in private industry. They found that when trained in PL/I, they were far less likely to find a job elsewhere, and so they were able to retain a much higher percentage of new hires as "career" employees.

I think the same principle may have been at work for a long time in the MIDRANGE community, where the language of choice just happened to be RPG. Over time, the total number of MIDRANGE customer sites grew to the point where there was pretty good demand for those with RPG skills. So, perhaps RPG also came to be viewed (by management) in much the same way that COBOL was once viewed. Perhaps this might also explain why so many shops seem reluctant to invest in training their RPG programmers in anything "new" (for fear of losing them).

In another related example from the early 1980s, a large company gave a presentation at SHARE about how they used the IBM PL/I compiler pre-processor to create their own industry-specific application programming language, and their programmers were trained in this "language" and were required to use it exclusively for all "in-house" developed application code. Thus, their applications programmers developed a skill-set that could be used nowhere else, in effect creating a "captive audience" of application programmers. That was not the only reason for doing this; the set of "macros" they developed gave the applications programmers what amounted to a "4GL" or a much higher-level language than ordinary PL/I, and so their productivity was greatly increased, and they were able to re-use more code that way. Of course, such a shop would need to have at least one or two "heavy" PL/I developers who were knowledgeable enough to write and maintain the PL/I preprocessor macros for their "little language".

Today, we see much the same sort of thing, where companies are using object oriented languages and they create their own custom class libraries (of application or industry specific classes and methods). Done properly, this can be a "good thing." But, it is all too easy to do this rather badly, and using a poorly designed class library or object hierarchy is probably worse than not using any class libraries at all.

I also think the "not invented here" mentality (pride of authorship, etc.) is probably another big reason that we do not see more widespread adoption of these "modern" techniques and object-oriented technologies and "open source" projects at more companies.