IBM i > Developer > RPG

What RPG Developers Lack

Can IBM find the last programming stack piece?

 

Over the past few years I’ve been paying closer attention to—and comparing—the different platforms on which I develop. My primary two development platforms have been RPG on IBM i and Java on Windows running in Tomcat. I’ve also done PHP on and off, and have dabbled in C#, .NET and Ruby on Rails.

Many of the more popular languages such as Java, .NET and PHP get much attention both on the front of new language features and also code collections that aid in doing everything from creating PDFs to DB management layers to entire frameworks meant for user interaction (e.g., JavaServer Faces).

In comparing these programming stacks to RPG, I’ve come to the following high-level conclusion: The only necessity RPG coders really lack is the capability to easily and seamlessly convey a modern user interface from the RPG language. Pretty much everything else we have is either far beyond the capabilities of what other languages have or is “good enough” to meet our daily needs.

Before I further discuss my comparison of programming stacks, I want to convey that processing is moving full Web 2.0-style applications that run in a browser back to the server—making use of honed frameworks like Ext JS and Dojo. Moving the majority of processing and workload back to the server works well for IBM i because it’s had time to marinate as a multiuser server-side OS compared to Microsoft Windows. This is important to note because it relieves RPG of the perceived need to run on the desktop.

Who’s Got the Goods?

Back to comparing. Let’s examine what the non-IBM i big players are working on lately. The article “Microsoft Enhances its Roadmap for Midsize Businesses” shows Microsoft is still trying to get to the point of what RPG+DB2+IBMi has had for years—an intimately integrated application programming stack. The funny thing is that it’s constantly trying to create a refined and integrated platform with applications that aren’t tightly knit. The same could be said for the Java community. For example, every time I must communicate with a database from Java it pains me because I must be concerned about connections, pools, “Object Relational Management” (ORM) tools like Hibernate.org, and the list goes on. With RPG, I’ve NEVER EVER had to worry about those things. This saves me MANY hours because not only don’t I have to program for it but I also don’t have to fix it; my connection to DB2 from RPG has NEVER been broken in my personal experience. Java’s flexibility is also its biggest demise: I can do ANYTHING with it, but I can’t do anything QUICKLY with it because the community is still trying to develop patterns around it that are never quite right. We must look no further than the ever-evolving “solutions” like the EJB (Enterprise Java Bean) spec to see the pains non-RPG programmers go through to get data from their DB into their program. It was so overarchitected that they had to strip it down in its latest incantation to make it digestible by Java developers, a classic case of trying to boil the ocean. What’s crazy is that we’ve had much of the DB-to-programming-language mapping built into the RPG language for decades with our READx and CHAIN family of opcodes. We issue a READx and the data shows up in a data structure (similar to a Java POJO) and we didn’t have to write a lick of plumbing code for that! I no longer take that for granted.

Consider the article “ASP.NET Grows Up,” in which Microsoft explains its attempt to move away from stateless Web apps to stateful "jobs" on the server but have had efficiency issues. IBM i has had stateful jobs since I was born (1979)! But NOTHING that IBM is selling for Web apps makes use of the awesomeness of IBM i stateful jobs (not even CGIDEV2). That’s just one of many points one could make in favor of IBM i application development that often gets overlooked and all the while other vendors take the opportunity to get press for it.

What’s funny to me is that even IBM has realized some of the programming inefficiency issues and has tried to address them, but has done so in ways that don’t give it a competitive edge. EGL, for instance, acknowledges that developing raw Java by hand takes way too long, so a simpler syntax was needed. The issue is that instead of recognizing and capitalizing on a language it owns (i.e., RPG), the company chose to build on a language owned by IBM’s biggest professional services competitor, Oracle. Not to mention that EGL barely makes use of native IBM i features. EGL trades up tight integration for platform independence, which is a great option to have if you’re a vendor selling software. But what of us who are more than happy with our IBM i, the OS that rarely burps?

 

Tweet