RPG is Dead - Long Live RPG

About every two years some industry pundit or other takes it upon themselves to remind us that "RPG is Dead." We say "remind" because this theme recurs so frequently -- and always with the same predictable results. One group rushes to agree and joyfully starts banging the nails in the coffin lid, another (usually larger) group decries the statement, starts pulling out the nails, and affirms that the language is indeed alive and well in their world. Sometimes the discussion occurs on the Internet on one of the IBM i related lists, at other times it appears on websites such as LinkedIn, and from time to time it appears in the IBM i press. As Yogi Berra said, "It's deja vu all over again."

The latest, and the reason for this blog entry, appeared recently on iProDeveloper.com under the headline "Is RPG Dead? Why it's time to write the obituary" and was authored by Mel Beckman. Before you read on, you may want to read Mel's piece if you haven't already done so. You may notice that one of the people who commented on the piece was Jon. He has a lot more he could say about some of the points made in the article, but he's trying to restrain himself. We want to make some rather different points here and to dissect the article itself would not serve that purpose.

It seems to us that articles such as this only serve to harm the community. We are a (relatively) small group, and the vast majority of us still believe that IBM i on Power is the single best business system out there -- period. So why do we continue to make such negative public critiques as this? It seems to us that the only thing these discussions serve to do is to help reinforce all of the negative things that our "competition" like to say about us. "Look, even IBM i experts think RPG is dead." And of course if you say RPG is dead then you have pretty much condemned the platform. Make no mistake - that is exactly how the competition uses such articles. After all, a very large percentage of application code running on IBM i systems today is written in RPG. So connect the dots -- from an IBM i competitor's perspective.

We used to think that the positives of such discussions, namely encouraging people to explore new languages and techniques -- outweighed the negatives, but we are less and less convinced of that. 

RPG is a tool. Plain and simple. PHP is a tool. So is Java. So is C++. Just as we wouldn't use a hammer to try and smooth out a piece of wood so we (personally) would not want to implement our business rules in Java or C++. Java and other OO languages have a role for sure. There are many things that OO languages are well suited for. We just don't find the argument that business processes are among that set a convincing one. More importantly, we think that these so-called "modern" languages should be added to our tool kit -- not used to replace the tools we already have. Even if it made sense from a capability perspective (which we don't believe it does), it would make no economic sense.

We have no idea what plans IBM may, or may not, have for RPG or of the timeframe in which any new features might be delivered. But we're not sure an OO RPG would be a good option -- not because it would be too late, but simply because such a large percentage of RPGers don't take advantage of the more modern facilities such as subprocedures in the language today. Thinking that those stuck in RPG III mode would embrace OO just because it has an RPG label is just foolish. There are better things for IBM to spend their money on.

"(RPG is) ... no longer routinely used to write new programs that solve current problems." Really? Many, many shops are writing new, modern applications using RPG. Sure, there are shops out there still using outdated versions of the language and outdated tools and techniques. But there are also many mobile and Web-based applications out there with rock-solid, modern RPG at their core. 

Since we included a Yogi Berra quote earlier, perhaps it is appropriate to steal one from Mark Twain to close. "The report of my death was an exaggeration." 

 

 

Comments

[Aaron Bartell]

What's important to note about OO is that it isn't all bad. For example, I would love to have procedure overloading. That would give us a nice feature of OO yet still keep us with the simple/powerful modular RPG paradigm.

Now I am really curious to know how much coding Mel Beckman actually does on a daily basis or is he just putting out this stuff in complete ignorance. My guess is it's the latter and that is something iProDeveloper should address. He's a "senior technical editor" - in my book that means you should know your stuff - he doesn't seem too. (Mel Bio: http://www.iprodeveloper.com/author/2998266/MelBeckman)

Every vendor that advertises an RPG product with iProDeveloper.com should send a formal letter to the editor because Mel just cost you a lot of marketing/sales dollars - your sales job just got a whole lot tougher of trying to convince shops that RPG is alive and well.

Mel, you picked a fight with the crowd. Formal retractions are welcome.

AaronBartell.com

[Buck]

It's a pity that Mel's article isn't getting much discussion. I'd like to hear his opinion on why only OO is suitable for new development.

[Hans Boldt]

First, I agree with Jon that adding OO to RPG would be a very bad idea. And not just because most RPG programmers don't yet use all the language features available to them. However, this fact alone is a bad reflection on the language.

Second, saying "RPG is a tool. Plain and simple. PHP is a tool. So is Java. So is C++." implies an equivalence between them. Clearly, they are not equivalent. Languages like PHP and Java have very powerful features that make application development much easier. In addition, Java and PHP programmers have robust frameworks at their disposal that make app development even easier. Heck, PHP programmers don't normally write SQL, and yet can easily do database reads involving complex joins.

Bottom line: I think Mel has it right.

Cheers! Hans

[john erps]

Implementing "server side" business logic on IBM i is best done using RPG. NOT because it's inherently good for implementing business language, but it's "good enough" (i.e. ILE RPGIV, not RPG/400) , and available. I.e. integrated with the OS and tools etc.

However, to say that OO is not usable for business logic is a very PERSONAL OPINION. It is not fact.

What you are referring to is wrong usage of OO. To implement business logic it is a wrong idea to scatter code in small methods along several (business) objects, which makes the code fragile and difficult to follow. It's a matter of experience. Like not only knowing how to code a service program or module, but also what to include (or not to include) in a module. This takes experience. Same thing with OO. When coding a GUI you have lots of tools and frameworks which already do the hard part of good separation of concerns and there is lots of experience with it (OO is indeed used to implement the first GUI). But business logic is something else. Business logic implements (parts of) a business process. These business processes should be encapsulated as a whole (command pattern), for example. So that the complete business process is in one method (which maybe delegates parts of the processing to other objects). But because this doesn't "look" like OO (long methods) it's felt as "wrong" by people who program OO languages but are not experts.

for info on this interesting subject:

http://martinfowler.com/bliki/CQRS.html

[john erps]

Addendum to my previous post.

http://en.wikipedia.org/wiki/Data,_Context,_and_Interaction

The reason RPG is better to implement business logic is of it's procedural nature. You need "more procedural" code to implement business logic, you could say. In RPG you don't have a choice. And using "procedural" code only is better than scattering your code all over the place trying to be good "OO programmer". OO is nothing more than "the next level" of "modular programming" as a way to organize your code. If you want you could use Java with only class methods, which is also a better way to implement business logic.

[Aaron Bartell]

>And not just because most RPG programmers don't yet use all the language features available to them. However, this fact alone is a bad reflection on the language.

We need to give up and pass by the people that have not yet adopted fundamental things like service programs and sub procedures. We also need to stop using that as a crutch for why we shouldn't add new features. Wouldn't you agree?

Hans, I think I understand where you are coming from. Your belief in RPG being dead is more so the lack of frameworks and not the language as it stands, correct? And if there were enough frameworks then you would consider it to not be dead?

John Erps, good comments. At the end of the day OO is quite good for frameworks and then just doing modular Java *can be* good for modularizing reusable code.

AaronBartell.com

[Buck]

Good discussion!

I'm with Hans: it is difficult to simply equate Java with ILE RPG. Each has strengths the other does not. Therefore, it is important to discuss the application we have in mind.

I for one would not use Java or PHP for the back-end stored procedure that returns data to a web application. I'd use RPG. I would use a stored proc because the web team are not familiar enough with the database to reach in and get what they need. I can write an ILE RPG stored proc in minutes. This optimises the web team's time (they can focus on fit and finish) and delivers reliable results quickly.

What application would I be working on where Java on IBM i would be a better candidate than ILE RPG on IBM i? (This is intended to spur discussion, not restrict it).

[Dan Devoe]

"Dead" is a relative term.

I would agree that RPG/400 & prior is "dead". IBM itself has not made any enhancements to RPG/400, let alone earlier releases, in over a decade.

RPG/IV, specifically free-form, is alive & thriving.

New enhancements to RPG may not be experienced by all, because of lack of tooling (PDM syntax checking "frozen"), lack of desire, or just pure laziness.

If RPG was really "dead", why would IBM still be enhancing it?

One major issue that RPG faces is it is not available on any platform, except the IBM i. Sure, WANG used to use it, but that was one of the truly "dead" versions. There is also Visual RPG, but that is not open-source, and is not readily available on SourceForge, etc.

One way for IBM to truly prove that RPG is alive & well, is to release an opensource version of the compiler itself - it shouldn't be that difficult, since the compiler was bundled with VisualRPG. But I digress...

Just because your boss won't "let you" develop using /free form, or fixed-form RPG/IV, doesn't mean that you can dabble on your own time, and then as a "by the way", show the powers that be how much easier the code is to read - perhaps throw in a web service, or spreadsheet processing, and you'll get a "wow!"

No one is going to look out for your future, except you. Now I'm not saying that RPG is perfect - it is far from it. But, as it has been pointed out, when paired up with other "tools", you can have your cake & eat it too.

Most of the cast of House believe that Dr. House is dead. But much like RPG, he is very much alive.

I'm looking forward to reading the next obituary in around 5 years - and more curious to find out how many other languages that are presently "thriving" have their funeral before RPG...

[Greg Helton]

Does Mel think that fixed point arithmetic is a rarity among programming languages?

Mel says OO is so important, does he think that some OO dialect of the languages he mentions, COBOL or FORTRAN, is a better choice than RPG? I think the market has judged OO COBOL and found it wanting. Its laughable to think that adding OO to a language is going to make it better.

What framework functionality does Mel think RPG is in need of? Spring's dependency inversion? Hibernates persistence?

Mel provides a pretty poor argument.

[Jon Paris]

@Hans "PHP is a tool. So is Java. So is C++." implies an equivalence between them. Clearly, they are not equivalent. Languages like PHP and Java have very powerful features that make application development much easier."

Not our intent when we wrote that part. Tools as in a hammer is a tool, so is a hammer. And I think we made that pretty clear in the post. The inference is entirely yours Hans.

To the point though - while I agree that they have features that can make app dev easier, you need to add the qualifier "certain kinds of apps" - again we covered this in the post.

The first thing most Java programmers say when introduced to RPG is "Wow - that's so much easier ..." - not everything - just certain things - reports being one example.

But you and I have had the discussion before and the only reason I even responded was to point out that we had already qualified the remarks that you referenced.

[Jon Paris]

@Dan "I'm looking forward to reading the next obituary in around 5 years - and more curious to find out how many other languages that are presently "thriving" have their funeral before RPG...
"

Amen to that. I suspect that there will be a number of them - in part because many of the adoptees of those languages are the first to climb on the "latest and greatest" and therefore the first to abandon them for the next one.

[Bob Genis]

I for one would like to see some OO features added to RPG. Most notably the ability to implement and program to interfaces. RPG has the ability to pass procedure pointers as parameters. It sure would be nice to be able to have the compiler check the procedure being passed as being an implementer of a known/published interface.

[Greg Helton]

An individual has created Light Table, an IDE that provides instant feedback to the developer as he writes his code. $274K has been pledged for the Light Table project on Kickstarter.

Such a feature would be a huge benefit to the RPG language but no one in their right mind would expect to see it in their lifetime. RPG isn't dead but IBM's relationship with RPG is practically comatose.

[Nathan Andelin]

We routinely write new RPG programs to solve current problems. More specifically, we use RPG to develop web applications for students, parents, teachers, and school administrators. So far, we have deployed more than 400 new applications under our web portal, and we anticipate writing a lot more.

Our user interfaces are written in HTML, CSS, and JavaScript, while the majority of our server-side code is RPG. Following are some reasons one might consider using RPG for web applications:

RPG has more efficient database interfaces. Most applications NEED record level access as well as SQL for database I/O. RPG uses less CPU and I/O, has less latency, and performs much better than more mainstream languages, etc.

RPG web applications can maintain state just like 5250 applications, which takes a burden off programmers as well as garbage collectors. Users can even launch multiple instances of the same application without worrying about the state of each. Users can end jobs and free resources by clicking an Exit link.

You can launch RPG programs that perform database I/O and browser I/O and run under IBM i user profiles. You can use IBM i security interfaces to specify authorities of each. User IDs are automatically recorded in journal entries for changes made to IBM i databases and other objects.

RPG jobs can take advantage of IBM i workload management; utilizing subsystems, memory pools, run priorities, time slices, library lists, job descriptions, job logs, output queues, spool files, etc.

With RPG you can activate thousands of IBM i jobs to support thousands of concurrent users where each job can have its own runtime environment. Contrast that with so called “modern” languages that run under environments where you have to set up a separate virtual machine for each environment.

Pronouncing the death of RPG would be essentially be pronouncing the death of IBM i. It baffles me that Mel Beckman and Penton would do that.

Workload management under IBM i is much more advanced and offers much more control than managing workloads with LPARS and comparable virtual machines.

Rather than setting up multiple virtual machines for separate organizations, or for separate development, test, or production environments, you can use separate subsystems, and separate library lists. RPG saves programming time, system administration, and computer resources, which ultimately saves money.

[Dan Darnell]

Good points, Jon and Susan. While I know that we don't entirely agree on this topic I appreciate your well-reasoned and insightful arguments.

As you know, I advocate for EGL as the language that makes the most sense for RPG'ers to adopt. EGL seems to me to the business language that best represents the evolution of COBOL and RPG -- a language that does incorporate *some* OO concepts but remains essentially a business software oriented procedural language while incorporating one-language support for all of the "modern" client UI, server, and database targets.

I do find myself in agreement with Mel's article based on my own experiences with the companies I work with currently and have worked with in the past.

However, EGL has an audience that is a tiny fraction of that enjoyed by RPG -- so I am not in a position to argue too strongly about "dead" or "dying" programming languages. At least, not yet. ;-)

--Dan

[Aaron Bartell]

Dan,

Do you have a feeling for how EGL is catching on within the overall community (not just IBMi) since it was give to the Eclipse foundation?

In hindsight I wish IBM would have made EGL compile to MI on IBMi vs. requiring it to run on a JVM layer. I would have been the first to jump ship to it because it would essentially be "RPG V" without all the legacy syntax burden.

AaronBartell.com

[Dan Darnell]

Aaron,

I was in touch with the program director and getting updates on download counts (not the same as adoption rate but perhaps an indicator of interest level) but I haven't asked for an update lately. The download numbers were impressive but there is so little traffic on the EDT forum that I wonder how many of those downloads are turning into people doing a meaningful evaluation of the product.

My opinion is that IBM has something special with EDT but they are failing to figure out how to get the word out. It's hard enough to make inroads with the IBM i community but reaching the overall community of developers is even more difficult.

--Dan

[Dan Darnell]

Frank Soltis used to talk about a completely object-oriented system...one in which the operating system was capable of dealing with true business objects. He said that this mechanism was already in the IBMi but had never been leveraged.

OO languages used with relational databases are unwieldy because of the data mapping required. Object databases solve the mapping problem but they are tricky to use, slower than RDBMS, lack tools, etc.

A completely object-oriented computer is such a radical concept (throw away your database!) that I guess we'll never see it. Still, it blows my mind to think that the power is there in the IBMi to marry an OO infrastructure to an OO language such that we could have invoices that age themselves, accounts that accrue interest on themselves, etc. It's a vision in which the OS takes advantage of the speed and massive threading capabilities of today's processors to accommodate something that would feel almost like a sentient business system.

Our concept of "applications" is radically changed at that point. The traditional application part of a system would be the user interface but everything underneath that would be self-contained true business objects.

Why do we need this? Because old school DATA PROCESSING isn't an effective way to process data any more. Hardware architecture is about symmetric multiprocessing not processing data in a single thread. In essence, everything we do is out of whack. OO languages and relational databases don't fit together. Procedural languages and symmetric multiprocessing hardware don't fit together.

Old people like myself will remember that IBM attempted a true OO architecture from a pure software point of view with their San Francisco initiative. They started with C++ and them tried Java. The efforts failed, in my opinion, because they were starting at the wrong level -- they needed an object-oriented operating system. They needed the IBMi.

What does this have to do with the topic at hand? RPG may be dead. I think it probably is. I'm more interested in not losing the IBMi. It's time to do what Frank did with the S/38 and AS/400 -- radically change the world.

Bring on the the evolutionary change, the revolution, that the whole field of software development needs. Bring on the IBMi as the world's first completely OO computer.

Then Aaron and I can get back to arguing about user interfaces. ;-)

--Dan

[Robert Nehrbass]

I was using the i5/OS glossary from the IBM i 7.1 Information Center (© Copyright IBM Corporation 1993, 2012) and came across the definition of RPG, as follows:

RPG
See Report Program Generator.

Which takes us to this:

Report Program Generator (RPG)
A programming language designed for writing application programs for business data processing requirements. The application programs range from report writing and inquiry programs to applications such as payroll, order entry, and production planning.

In other words, RPG I is it, folks.

If you dig down into the section on programming languages, there is this on manuals:

RPG
These manuals include information about ILE, ILE RPG, VisualAge® RPG, and RPG/400® programming languages for network administrators and for both new and experienced programmers.

So someone, at least, understands which version of RPG is used now. However, this was not the person who wrote the glossary. That person not only thinks RPG is dead, but that it was never born beyond RPG I.

Like to see more of the glossary?

program cycle
In RPG, the series of operations performed by the computer for each record read.

I haven't seen the program cycle described as part of RPG for about 25 years! At this point, I figured that the glossary would consider matching records an important part of the modern RPG, so I looked:

match fields
In RPG primary or secondary multifile processing, fields within a record type that are to be used for checking the order of a single file, or for matching records of one file with those of another file.

matching record indicator (MR indicator)
An indicator used in calculation or output specifications to indicate operations that are to be performed only when records match in primary and secondary files.

match level
In RPG, the value (M1 through M9) assigned to the match field. The match level identifies fields by which records are matched during primary or secondary multifile processing.

Now that is a good example of a dead language!

I have been programming in various versions of RPG since 1982. I started working on the AS/400 in 1988 on Release 1.0. In all this time, one thing has remained true: programmers outside the AS/400/iSeries have nothing but contempt for RPG. Is this any surprise, given how IBM treats the language? They have never been good at selling the benefits of this platform or this language.

[Greg Helton]

It was stated that "RPG uses shared memory interfaces to interact with IBM i". This is a very general statement that seems to convey the thought that this is an advantage RPG has?

I imagine that every programming language uses some technique to share memory with the OS so is this a unique advantage of RPG? I wonder.

Let's look at one instance where Java shares data across a wider scope than does RPG. First we investigate RPG. A RPG program can be written so that data is loaded into a table at program initialization. This is very effective in eliminating CHAINs to a table for purposes of validation. The obvious problem with this and all other data used by an RPG program is that each user gets his own copy.

Using a cache, data can be shared among all users of a web application. Web application containers can eliminate the execution of method calls where parameters remain unchanged and return a previously cached result. And, with OO, the return value is a reference to the data, not an additional copy of the data. When caching is added to an application, no coding changes are required to the program code.

The IBM i DBMS is optimized and performs caching as well or better than does any web cache but, because RPG's access to data is limited to what would be session scope in web parlance, in regards to Nathan's point, I don't see RPG having an advantage in sharing memory

[Wayne Jensen]

RPG is alive and well in Lincoln, NE. We use it to create web application using CGI and Websphere. Oh sure we are fighting the .net takeover even at our own company, but we continue to out perform the so called .netters. They keep throwing more programmers and servers at their project. IBM and RPG are solid like a rock. Never down running 24/7! Long live RPG and Free form!