Still Programming in RPG

The article "Why Are We Still Programming in RPG" by Carson A. Soule [November 2008, article ID 62267 at SystemiNetwork.com] needs a controversial comment. First of all, I would like to mention that I am responsible for the (ILE-RPG) application development of an ISV. If one speaks only about simple, System i-restricted and non-globalized solutions, then Carson is right. Otherwise, 4GL techniques and modern programming languages are essential.

Starting with the first point--simple applications--the complexity of applications has highly increased in the last 10 years. Thus, one needs abstraction layers (you can call it 4GL). Of course the vendor-specific solutions such as LANSA and Cool:2E are not suited for software companies. One needs its own 4GL techniques to master the complexities.

Second: System i restriction. That means the RPG-based solution runs only on System i. However, nowadays this is a strong restriction for a software company. There are a lot of competing platforms a software solution has to run at too. System i restriction means also the exclusive use of RPG-enabled System i technologies, no networking, no file access in a network, no graphical user interface, no interaction with other systems. Of course, you can do all such things but not in a seamless way. You need a lot of technologies besides RPG, and you have to use tricks and do handicrafts to integrate such technologies into your RPG programs (see the huge amount of articles in System iNews about this topic). "4GL" as C# and Java deliver a sophisticated API which covers all the mentioned tasks without bothering the programmer with details.

Last: Non-globalized solution. A non-unicode solution is not worth being called a globalized solution, but it is a nightmare to transform a big RPG-based software solution of, let's say, about 10 million LOC to Unicode (it is my own experience). The difficulties start with the restricted Unicode capabilities of BIFs and opcodes end with the integration in the System i environment, as, for example, the invocation of API or CL, which are more or less non-unicode. And try to create or print a Unicode spool, if it works at all. We are still searching for ways to do that. I won't speak about the missed possibility to use internal defined output files with Unicode and other Unicode restrictions of RPG. All the other "4GLs" don't worry about Unicode, they are Unicode from scratch.

Ottfried Thümmel
Via email

Author Carson Soule replies: I must agree with Mr. Thümmel. RPG is not perfect for every application or company. As an ISV, we made the same analysis and decided to write new applications in Java over WebSphere to get the cross platform and other advantages he mentions. However, our experience was that we had a hard time being competitive in a purely i environment where these capabilities were not critical. As a result, we now often mix RPG back-end code with Java, Lotus Domino, or other front-end language implementations. While I hope that RPG continues to evolve rapidly, we continue to look for the language which will replace it. But, we haven't found it yet.

More Thoughts on Still Programming in RPG

First off, I should indicate my background since that probably shapes the opinion I will now espouse. I've moved from Fortran (on an IBM 360 mainframe), to machine language/assembly, to BASIC, Clipper (DBASE), Pascal, C++, PowerBuilder, and now C#.NET. I would never move back to any language I had ever used before because, in all honesty, each new language I have adopted over the years has been better than the one before.

I can understand however, how someone locked in the darkness of a System i shop, unbathed in the warm glow of modern programming tools, would believe that there is little to be gained from using them. Many 3GL programmers do not understand OOP and think that reusability is the copying and pasting of old code. They either see no benefit in, or do not understand, concepts such as inheritance, polymorphism, iteration, aggregation, interfaces, delegation, or overloading, and the power they provide to the developer. Someone who has always used a spear must find a gun useless since it does not have a point!

I meet apologists for System i who keep trying to justify the expensive paperweight by pointing to its much-vaunted reliability. The same can be said for an AK-47. However, let's face it, modern weapons technology has gone past a gun created nearly half a century ago. The same can be said for RPG.

With modern languages, more can be done with a single command, and the applications frameworks make programming complex systems with large teams much easier. I don't even need to mention code maintenance, which is significantly easier using the aforementioned frameworks and powerful IDEs available today. If we include support, third-party libraries, development tools, books, user groups, language extensions, language evolution, etc., RPG would not even be mentioned in any useful discussion on programming. Well, none in which I've participated in the last 15 years.

The real crux of the discussion comes down to this. If Mr. Soule did not have a zillion lines of legacy code to maintain and had to start from scratch to write a new complex business application, would he ever consider RPG? Then again, given how little Mr. Soule seems to know about modern languages, he probably would.

Lancelot Green
Via email

Author Carson Soule replies: I would like to thank Mr. Green for amplifying my point with his excellent examples. First, however, I must correct his impression that RPG programmers are not in the warm glow of modern tools and techniques. Any reading of our magazine and its related forums and blogs should convince him otherwise as would an examination of the current language and tool offerings on i. I bring a working knowledge of most of the languages and all of the concepts he mentions. Someone who has always used a gun may have no idea how to work in a jungle, at close range, where bullets are unavailable. Under those circumstances, a spear looks mighty good.

Mr. Green's mention of the AK-47 is an excellent case in point. While theorists and warfare textbook writers will agree that the AK-47 is outdated, the experience in the field is that low cost and rock-solid reliability make it the weapon of choice for most of the world. Militants in Iraq, Afghanistan, and most of Africa have proven that they can hold off or fight to a draw the most technologically sophisticated armies in the world with little more than an AK and some improvised explosives. There are many stories of allied soldiers in a firefight who throw down their jammed M-16 and pick up a fallen combatant's AK-47 to continue to fight. I would argue that RPG is the AK-47 of the programming world. It loses most intellectual arguments but wins more than its share of real-world battles.

I have had several opportunities to completely replace legacy systems, starting from scratch and having a choice of language. My opinion stems from my experience in creating substantial new systems in Java, Groovy on Grails, and Lotus Domino. In a previous generation, I did so using VB, C, and Pascal. Yes, I am influenced by legacy systems, but I am more influenced by business demands for application functionality quickly and inexpensively.

To paraphrase Donald Rumsfeld, you go to program with the language you have, not the language you might want or wish to have at a later time.

The EGL Has Landed

Just got finished morphing your article to pull back dynamic menu label/options to EGL ["The EGL Has Landed: Calling RPG Programs from EGL," November 2008, article ID 61407 at SystemiNetwork.com]. I never had much cause to use nested array data structures but wish I would have gotten to know them better sooner! I had wanted to present "menu" options on EGL panels based on the signed on user; this was a perfect way to get there. Really slick and opens up other opportunities.

Jake Berberich
Via email

We welcome your suggestions, criticisms, and opinions. Email your comments to editors@SystemiNetwork.com. All letters should include your name, your company name, city, and state or country. We reserve the right to edit letters for clarity and length. We also reserve the right to publish them in all electronic and print editions of System iNEWS unless the sender specifically requests otherwise.