A Short History of Free-Form RPG

Free-form RPG is back in the news with the announcement of free-form D, F, P, and H-specs. In this short essay, I look back at the history of free-form syntax in RPG.

It all started more than twenty years ago, back when RPG IV was being designed. At the time, there were two distinct schools of thought. On one side, there were people who insisted RPG should have a fully free-form syntax. On the other, were those who strongly believed that RPG should remain in its traditional fixed-form layout. The result was a compromise that leaned heavily towards a traditional fixed-form syntax, but with some free-form elements, such as keywords on the new definition specification and expressions in an extended factor two entry.

My first task in the implementation of the RPG IV compiler was coding the new D-spec, along with its keywords. Later, we were able to convince our planner that keywords should also be allowed on the F-spec. Later still, keywords on the H-spec became an obvious design change.

The extended factor two opcodes, such as EVAL, IF, DOW, etc., were a riskier proposition. At first one developer was assigned the task, and later another to help out the first. But as time went on, it was clear that they weren’t making any progress. Late in the development cycle, I was assigned that piece of the language. Scrapping the work already done and starting from scratch, I finished the feature well in time for the initial release of RPG IV.

With the release of RPG IV, the development team was scaled back, leaving two developers working on new features. Because the extended factor two calcs were such a hit, one proposed enhancement was a fully free-form syntax for C-specs. However, we believed that it would require 100% of all development and testing resources for one release. When considering potential enhancements, this item would always get pushed well down the priority list.

This changed during the planning cycle for V5R1. I realized that common coding standards had changed somewhat during the past few years. I realized that a new free-form C-spec did not need to include all traditional C-spec features. Conditioning indicators weren’t needed now that we had the IF opcode. Resulting indicators were largely deprecated in favor of built-in functions. And some opcodes were no longer needed, such as IFxx and the MOVE opcodes. We just needed a few additional built-in functions to fill in some gaps. With this strategy, free-form calcs could be implemented relatively easily, along with other useful functional enhancements.

But of course, this proposal was not without controversy. In order to get the proper design, we had approval from management to discuss the proposal publicly, on a popular RPG related mailing list. Many people loved the idea, but some were vehemently against the proposal. Personally, although I knew we had something good, I was so disheartened with the criticism that I gave the feature a 50/50 chance of making it to release. However, in 2001 it was released, and over time, most critics came around to accept the syntax.

With V5R1 and /FREE released, we started thinking about moving towards a free-form syntax for other spec types. However, while free-form syntax made a lot of sense for calc specs, we could see little benefit for the rest of the language. Other enhancements of a more functional nature were always considered more important.

In the summer of 2003, the iSeries group in the Toronto Lab could not escape the “staffing actions” rampant throughout the Software Group, and the RPG compiler development team was reduced to one person. I was moved to a new team responsible for PL/X, a compiler used internally within IBM for the development of mainframe software.

So now we come to the Fall of 2013, 12 years after the release of  free-form calcs, 18 years after the release of RPG IV. A few weeks ago came the announcement of free-form D, F, P, and H-specs in RPG. Although I’m happy to see this come about, I’m also puzzled. It seems all too anti-climactic, too little too late to save an anachronism of a programming language. In a previous missive entitled Is RPG Dead? The Autopsy, I list half a dozen features common to modern programming languages but missing from RPG. Note that free-form syntax is not included in that list. At the time I wrote that, significant parts of the language were still fixed-form, but I didn’t consider the lack of a fully free syntax significant.

So what’s the big deal about the additional free-form syntax? More than ten years ago when I was part of the RPG development team, we always looked for useful functional features to add to the language. That is, features that would help improve programmer productivity, or allow programmers to do things they couldn’t do easily before. But that seemed to change about ten years ago. In the last release that I had any involvement with, one feature added was XML operations within the language. It wasn’t as if programmers couldn’t handle XML before since there were already XML API’s in use. But as far as I could tell, the only reason the XML opcodes were added was because COBOL was getting XML operations, and someone within the management team decided that RPG needed them too. I considered it a goofy feature, but I was too tired and jaded to argue. (Now that JSON is commonly used in places where XML was previously used, should RPG now include JSON opcodes?)

Lately, the major enhancements to RPG seem to be accompanied by major coverage in the iSeries press. Consider that silly Open Access feature, which seems primarily designed for ISV’s helping to modernize old monolithic applications, which in most cases probably should be rewritten from scratch instead. And now with the new free-form specs, a lot of pundits are writing about how the feature will make the language more acceptable to other programmers, while ignoring the functional deficits previously mentioned. That is, these days, it seems like planning RPG content is more of a public relations exercise geared towards managers of client RPG shops rather than providing real improvements making the job of RPG programmers easier. As RPG falls further and further behind the modern programming languages, I suspect the PR show will become more and more prominent.

In my opinion, although I think the new free-form specs are a nice improvement to RPG, they will not make RPG more palatable to the programmers of Java, Python, PHP, etc. A dozen years ago, we saw little justification for the feature, and I don’t see what has changed in the meantime. If anything, RPG has become less and less relevant as applications programmers continue to discover the productivity gains to be had by using modern interpreted languages like Python and PHP.

Is RPG Dead? The Wake

In a previous post called Is RPG Dead? The Autopsy, I suggested I’d probably have more to say on the subject. This offering is in response to Scott Klement’s editorial, RPG is Dead? Are You Serious?! I’d like to respond to a couple of points he makes.

First, he brings up the fact that people have been debating RPG’s death for the past 20 years, and yet RPG is still around. But why bring up the question at all if there was any doubt as to RPG’s future? Does anyone ask if Python is dead? Or PHP? Of course not! No one has to.

Next, he raises the point that most application development on IBM i is done in RPG. No one is denying that. However, no one can deny that IBM i is a platform in decline. The numbers just don’t lie. The fortunes of RPG are intimately tied to the fortunes of the platform. As IBM i slowly dies, so does RPG. (I said more on this theme in my blog posting Is RPG Dead? Do We Still Have To Ask?.)

Skipping past some history, Scott talks about what’s important to programming business logic. Let’s look at each in turn:

Business logic uses numbers heavily. Well, this is not unique to business applications. However, most arithmetic in any business application, like in any other domain, is integer arithmetic. Business logic does make use of decimal numbers, but even there, most operations involving decimal numbers are simply the movement of data. Actual decimal arithmetic is a small part of the logic, and in most business apps, could be implemented fully in SQL code. That said, other languages do have support for decimal arithmetic. Scott mentions Java for one. Python is another. Even PHP has support for decimals.

Business logic uses databases heavily. Business applications don’t have a monopoly on using databases. Many different domains, from gaming to on-line social networking to statistical analysis make at least moderate use of databases. And so you can find support for databases in practically every programming language out there. RPG gives you two choices: built-in I/O operations and pre-processed SQL. Other languages often provide higher-level access to databases. For example, in CakePHP, you define your high-level relationships (1-1, n-1, 1-n, n-n) between your tables, and one find() operation can bring in all related data for a transaction. That is, the framework figures out the SQL for you, including joins. Among the available RPG frameworks, which one can provide that level of power?

Business logic uses dates frequently. And so do many other types of programs. And so you can find date support in practically all modern programming languages. RPG is certainly not unique. Python has the datetime class. PHP has an extensive list of date/time functions and classes.

Business logic uses a lot of string manipulation. I disagree with that assertion since strings are most commonly needed in the presentation layer of an application. But let’s assume it’s true for business logic. Again, what modern programming language lacks support for strings? Languages like Python, Perl, and PHP (to name a few) all have very powerful string support. Much more powerful than RPG’s support. In those other languages, strings are all objects, with a rich set of methods. RPG, in comparison, has a rather limited choice of string operations. Consider the ease of doing regular expression matching in Perl, Python, and PHP. And compare that to what you need to do in RPG.

If these four categories define what’s important in programming business logic, there are clearly languages other than RPG that have a definite advantage. Whenever I see someone claim that RPG is the best language for business logic, I always interpret that to mean that the author simply knows RPG best. And Scott certainly is an expert on RPG.

Finally, Scott makes the point that RPG is still being enhanced and supported. True. However, other languages have long ago surpassed RPG in terms of features and capabilities. In my previous missive, I listed half a dozen features common to other programming languages that are still lacking in RPG. And I could have listed more. And other languages continue to grow and gain in popularity.

RPG will not disappear overnight. To say that RPG is dead is an exaggeration. However, it is becoming increasingly irrelevant in the I.T. world. I’m reminded of a job interview I had back in 2008 where the interviewer looked at my resume and asked: “What’s an iSeries?”. (RPG wasn’t discussed at all in that interview.)

Cheers! Hans

Is RPG Dead? The Autopsy

In a previous post, I promised to say more on the subject of RPG’s death. But I’m finding it tougher than I expected. Don’t misunderstand me, it’s not for lack of content. It’s just that I worked with RPG for a long time. I don’t want to see RPG go away. Writing this blog posting feels like I’m kicking an old friend while he’s down on the ground. On the other hand, it’s just a programming language. And the facts need to be understood.

When I first learned RPG III, 31 years ago, I was impressed by a couple of things. First, I was impressed with the externally-described file. As far as I knew, no other language had such a powerful feature. Second, I was impressed with the syntax-checking source editor. At my university, some professors were just beginning to think about something like that.

But other aspects of RPG III were definitely goofy, such as the fixed-form syntax and the indicators. Fortunately, the language has grown since then. Indicators can be largely avoided, and calculations can be coded in a free-form syntax. However, although RPG has progressed, other languages have progressed faster, and new languages have cropped up with even more powerful features. More and more, RPG looks like an anachronism, rather than a modern programming language.

I’ll list some features that are commonplace in other, modern programming languages that RPG still lacks:

1) Namespaces. That is, what happens when you want to import two libraries with the same name? In languages like Java and Python, imports can be put into a directory hierarchy. And if there are conflicts, things can be renamed.

2) User-defined data types. Sorry, data structures and LIKEREC just don’t cut it.

3) Object-oriented programming. What language doesn’t have OO support these days? It’s something we now take for granted elsewhere.

4) Extensive list of built-in functions or classes. Just compare what RPG has to the Python Standard Library or PHP’s Function Reference. No comparison.

5) Frameworks. Most modern programming languages have a goodly selection of frameworks that simplify programming web applications. These frameworks have various levels of functionality, however, typically they take care of a lot of nitty-gritty details. Using a framework, you should never see a query string, or XML, or JSON, or SQL.

6) Operating system independence. Programs written in languages like Java, Python, and PHP can easily be ported across different operating systems.

Some would argue that RPG could be further enhanced to address these short-comings. But why bother when there are already other languages that have these features? The planners at IBM certainly know what’s lacking in RPG, and they still seem to have the resources to make the occasional enhancement. But over the past decade, there seems to have been little effort to address these specific short-comings. Looking at the situation from that perspective, one could argue that IBM itself also sees no future for RPG.

So far, I’ve written about 500 words, and yet there’s still more to be said. Stay tuned.

(Update: Next installment: Is RPG Dead? The Wake)

Cheers! Hans

Is RPG Dead? Do We Still Have To Ask?

Guess what, folks? It’s that time of year again when people debate the future of RPG. Is RPG dead? Think about it: Does anyone ever ask that question about any other programming language? Why do some people still insist that RPG does have a future?

To start with, let me make one assertion: Of all participants in this debate, I’m one of the very few who is both knowledgeable about RPG and who does not have a financial stake either way. Some commentators make their living by moving people off of IBM i. Others make a living doing RPG programming or training others. If anything, I don’t relish the idea of RPG disappearing because of my long involvement with RPG development.

RPG is very much unlike practically all other programming languages in use for application development. It is one of the few programming languages that is available on only one operating system. That’s right! If you want to do RPG programming, you need a system with the IBM i operating system. And IBM i is one of the last of the traditional proprietary operating systems.

What do I mean by that? Look back at the history of computers: In the 1950’s and 1960’s, there were a lot of computer companies, colloquially called “IBM and the Seven Dwarfs”. After a couple of mergers, they became “IBM and the BUNCH” (Burroughs, Univac, NCR, Control Data Corporation, and Honeywell). Each one had their own mainframe computer products. And each computer ran its own proprietary operating system, each incompatible with all the others. Over time, almost all of these proprietary operating systems have disappeared. Today, there are just two left: z/OS and IBM i.

Today, most computers run either Windows, or some variant of Unix or Linux. Even the machines that run the O/S relics z/OS and IBM i now also run Linux, with significant cost savings over the dinosaurs.

So here’s the current situation: The fact is that the main reason for running IBM i is to run RPG applications. And to be fair, a lot of them are still running. Without RPG, there’s no reason to choose IBM i. And without IBM i, there’s no way to run RPG apps.

Is there a future for IBM i? When I was looking for work back in 2007, one headhunter specifically told me that the bottom had fallen out of the i job market. Indeed, over the course of about 8 months, I saw only three listings for iSeries jobs in the greater Toronto area. If there are so few IBM i job openings in the 8th largest metropolitan area in North America, what hope is there for IBM i programmers elsewhere?

Frankly, in this day and age, if you want to develop a new application, it just doesn’t make any sense at all to limit yourself to one particular operating system. Especially one that is clearly in decline. Other languages like C, C++, PHP, and Python can run on practically any operating system. If you want to protect the value of your software development investment, clearly, any of these other languages is the way to go.

I have more to say about RPG, but I’ll save that for another blog post. Stay tuned!

Cheers! Hans