By Philippe Magne | November 6th 2019
In this article, we will discuss two languages that appear opposites in many senses. One, a very old procedural language (born in 1959!), and the other, a far more modern and object-oriented alternative. The two are so diametrically opposed that the first question is, would there be any value in comparing them?
1. The myth of Java
The typical reaction of any company looking to modernize its applications is to rewrite everything in Java, a universal and far more portable language than RPG. Looked at from the outside, this choice is not surprising. You could easily believe that a rewrite in Java would address two burning issues: preparing you for an exit from the IBM i platform at some time in the future and providing an easy answer to the RPG skill shortage. However, if you look more closely, it is clear that each language has been conceived from the outset for a specific technological environment. Java was born with the advent of the Web. It has been specifically designed to meet the needs of that ecosystem. In contrast, the mass batch processing so prevalent in legacy/heritage business applications is a requirement from “another world”. This is why we at ARCAD believe that the RPG Free Form is and will remain the principal language of the IBM i platform. It is naturally the best fit because it was “born with” the platform. Of course RPG must coexist with all the languages of the open world but it is fundamentally irreplaceable in the context of business application development on IBM i, thanks of course to its tight integration with the platform and its unequalled performance.
Many companies have tried to transcribe RPG code into Java in a more or less automated way. The results tend to very poor to say the least. An application written using a a procedural language cannot just be converted into another in an object-oriented language. Why? Because the design philosophy is radically different. Indeed Java developers confronted with code that has been “transformed” in this way all have the same reaction: for them, it is “not really Java”. Further, the cost in terms of application execution performance is especially high.
2. Why RPG Free Form?
COBOL is and will remain the standard language for mainframe platforms. The billions of lines of code developed over more than 50 years run the core systems of the world’s largest companies. The same is actually true of the RPG language on IBM i, as the undisputed language of choice for the most mission-critical of business applications on the platform. The only difference is in sheer volume (since RPG is only available on IBM i). But bear in mind that RPG constitutes more than 85% of the applications developed on this platform. What has held RPG back however is the unusual syntax of the earlier versions – their column-based format – which is extremely restrictive and makes the language very challenging to learn for newcomers. As a result, the average age of the developer population on IBM i is steadily increasing as young resources have been slow to embrace RPG.
Another major difference between the two business-oriented languages is their constancy. Unlike COBOL (whose structure has not evolved since 1974), the RPG language has undergone some major enhancements that have made it easier to read and hence to maintain. With IBM i being RPG’s sole and unique custodian, IBM itself has had the courage and motivation to make the language evolve. In 1995, the Integrated Language Environment (ILE) appeared, bringing more modularity and characteristics similar to object-oriented languages. But the most important transformation was the emergence in 2003 of “Free Form” RPG. The syntax of RPG Free Form is very similar to more common languages such as Java or C#. This makes it far more accessible to developers starting out on IBM i. They are very quickly up and running (a half-day e-learning course in RPG Free Form is enough to get you started).
The other major feature of RPG Free Form is that it is very deeply integrated into the operating system. This gives developers access to functions that are simply not available in other languages. Execution performance of RPG Free Form is optimal thanks to its proximity to the machine on which it runs.
The decision to conserve the “RPG” roots of this modern language in its name has been the subject of much debate. Yet in balance, the name “RPG Free Form” actually plays a role in ensuring the transition between generations. Indeed the improvements that make Free Form RPG easy to understand for the younger generations of developers, are also an advantage for the “elders”. By sharing a common language between generations, organizations avoid the kind of devastating disruption in technology that regularly costs companies millions in wasted IT expenditure – not to mention the risks and managerial difficulties caused.
So ironically what was previously considered to be the biggest threat to the platform – namely the uniqueness of its principal development language – has finally become its greatest asset, and its greatest hope for the future, a language that actually brings IT generations together!
3. Why Java?
Even if nowadays Java is challenged by a whole range of other even more recent languages, it still remains the standard in many companies. Yet attaining a good level of Java skills and high productivity requires a heavy investment, particularly in team profiles, along with a change in organizational structure and development processes. Such are the risks that many companies are not prepared to take.
Java must be kept for what it does best: developing Web applications (or interfaces). There is no doubt that Java is and will remain a reference in the field for many years to come, but should it really become the one and only standard for all application assets?
4. In a nutshell
RPG (in its most recent “RPG Free Form” version) and Java are not opposing languages, they are complementary. Each has its own advantages, its own adepts, its own ecosystem. The ideal solution is to have the two coexist in order to obtain “the best of both worlds”.
For this, the right approach is to invest in a DevOps strategy. Good DevOps tooling naturally brings diverse teams closer instead of pitting them against each other and comparing them. DevOps makes language less important than the methodology for managing change. Many new languages are still emerging, each one better adapted to the latest industry needs. In essence, to modernize a legacy system, the priority is not the language but rather the way that development is organized. In one word: it’s DevOps!