Everybody is talking about data-centric programming these days. But what is it, and what can it do for, and to, you?

Every once in a while, we see a flurry of articles about one particular topic. It blazes forth like a flaming Molotov cocktail, gets tossed up in the air for everyone to see, and then seems to explode in a cloud of smoke. It’s 15 minutes over, the topic quietly goes about the rest of its life, sometimes fading into insignificance and other times taking its place in the hallowed pantheon of IBM i concepts.

Such, right now seems to be the trajectory for data-centric programming. So, I guess I will add my two cents.  

Data-Centric What?

I have to admit, as with most things, I was confused when I first saw the term “data-centric programming.” I thought it must mean that, when you program, you have to consider the data and make that the center point of what you’re doing.

Heck fire, boys, I thought, we already do that, don’t we? I mean how can you program without thinking first and foremost about the data that you have to deal with? But that’s not exactly what the concept is all about.

Traditionally, we in the IBM i world have had one particular orientation: a procedural language orientation. That is, we tend to use a procedural language—generally RPG, but it could be COBOL or Java or whatever—to operate on the data that we are dealing with. And this orientation seems so natural and moral that we never even stop to consider another option.  

But there is another option, another paradigm that has been growing in importance over the last few years and is now finally at a critical kindling point, so a lot of people are beginning to take notice.

Data Languages

And that other option is a data language, a language that is born out of the database that created it.

Unlike a procedural or OO language that was developed to be able to do logic statements and then had IO routines appended to it, the database language started with the IO routines. That is what it was originally designed to do: to manipulate the database, to create tables or files, define the columns that are associated with it, screw around with them and change the values they contain—all that kind of stuff. And then, once they were sure that the language could do all that, they (the Creators) added in the ability to do logic statements. Lowering the operating table down from where it stood perched high above the castle, and crying out in defiance of both man and God, “It’s alive, it’s alive,” they unleashed this new type of language on the world.

Hmmm, OK, maybe that’s overdoing it a bit, but you get the idea.

DB2 Data Language

On the i, DB2 is the primary database outside of the DDS-based language that is part of RPG. I admit I have not always been a DB2 aficionado. It seemed sort of like buying a Ferrari to drive to the end of your driveway, but you can’t argue that it is (being SQL-based) an industry standard. And if you have real hard-core data needs, it is the way to go. And, even if you don’t and you are re-doing your system, it is kind of hard not to argue that it is a better alternative than DDS. So, in the future, we will probably be seeing a lot more DB2 and somewhat less DDS.

Now if you are using RPGLE as your primary language, then this is not a huge change. Instead of using the standard RPG IO operators, you can simply substitute the appropriate SQL alternatives.

I know what some of you might be saying: “Do I really have to learn SQL?” And the answer is “Yes.” Five or ten years ago, that might have been more of a question, but the simple truth today is that everyone who is associated with the i needs to not just be passingly familiar with SQL but pretty solid in it.

Now that doesn’t mean I want you to go out and start writing four-page SELECT statements. That’s the big thing I have against DB2 and SQL and all that jazz. It almost gives people a license to do things that just ain’t right. Like writing SELECT routines that are so complex that there is no way you can possibly unravel them. And for a long time, I refused to embrace DB2 because of all the bad code examples I saw.

But then it occurred to me (actually Dan Lovell explained it to me) that languages aren’t bad; it’s the people who use them who are the evil ones. And he is right. The same people who write huge, convoluted DB2 routines do the same thing in RPG.

Is There a Point to This?

In the i world, SQL is our data language, implemented via DB2. There are other data languages out there, of course. For example, if you are into Hadoop, there is a data language that you can do stuff with for that. But we on the i are pretty much DB2/SQL.

Initially, the DB2 data language was called DML (Data Manipulation Language), but now people tend to refer to it as DB2 PL (Programming Language).  

The idea of this thrust is to “make the database do more.” I frankly never know what to do with a statement like that. What does it mean? To me, it means having the database do more in terms of monitoring itself. Normally, monitoring the database is a function of the procedural language. But what if you could get the database to do that? Automatically, without your having to do anything.

Part of the problem, for me, is that I don’t have many clients who don’t already have a mature database. They have an ERP system they put it in 20 years ago, and they are just trying to keep their heads above water. So let’s put all the “pretend like you are defining your system from scratch” off the table. What good is data-centric programming to someone who is in a mature environment? What does it give you that the regular procedural programming doesn’t?

A Different Point of View

And this is where I struggle, because when I look at this question, I can’t see a solid reason why I should abandon my four-line Chain for a 10-line SELECT that seems so much less readable. But then I move over about four feet, and I start looking at it from a slightly different angle.

First, I never let the number of lines of code I write dictate what I write. Readability and clarity are paramount to me, and if it takes extra lines of code to do that, no problem.

Second, I know very well why PL seems less readable to me. It’s because I am not used to reading it. It is not second nature to me the way RPG is, but that is something that can be cured with time and experience and should not be a reason to avoid it.

Third, I think there is a fundamental difference in the way you read PL versus RPG. With RPG, you are reading a sentence at a time and then mentally putting that together. With PL, I am tempted to think that to be effective you need to read it in blocks and then mentally break it down from there. This is very similar to the way I think you have to read web languages, particular OO ones.

And that brings me to my fourth point, one that is both style and substance. What IBM has done with RPG /Free is wonderful. I love it. But in the end, I don’t think there is any way that you can take a procedural language and make it “modern” in a way that most young programmers would agree with. It is still a procedural language and therefore not cool.

And in one sense, that doesn’t matter. We don’t need to be cool to do our jobs. But in another, it makes all the difference in the world. Because we are a group of people who are trying to show a disbelieving audience that the i is a modern tool for the modern world. When we are speaking PL, we are speaking a language that many people from many other languages can understand rather than a language that is akin to Latin in their minds. We are speaking a language that can be bundled as a web service. We are speaking a language that can be used just as easily within the i as the web.

Data-centric programming using the PL in DB2 is a different way to do our work, but it is just possible that, in the long run, it may be the one way we have to signal to people outside the family that the i is indeed a modern tool for a modern world.

Give it a look.  

For more info on PL, download the IBM Redbook SQL Procedures, Triggers, and Functions on IBM DB2 for i.