RPG, PHP, and history

RPG, PHP, and history

Summary: What RPG and PHP have in common is an applications model that works - and the enemity of computer science professionals everywhere. They're a lot like cognitive dissonance theory that way: the theory works, and is therefore rejected as too simple minded.

SHARE:
TOPICS: Apps
24

While thinking through some of the comments recorded here as part of our discussion of development languages and environments I finally figured out what PHP reminds me of: RPG.

RPG [Report generator] started out in the IBM 360 world as a report formatting aid, but never really succeeded there until Codd et al tried to use it as a query canning tool for System/R users.

The original applications delivery model for IBM's intended System 360 successor was client-server. In that vision the IBM 51XX series machines would run query formatters and interface management software accessing data stored using a microcoded System/R on specially optimized 48 bit hardware. By 1969, however, that vision had been largely abandoned due to serialization problems with client-server, and the battle was on between people who saw applications in COBOL terms and those who, like Code himself, saw applications as mere interfaces to data.

The latter view won - when the future system hit the market as the System 38 nearly ten years later, the primary applications language was a second generation RPG - now capable of handling the full CRUD repetoire but still inherently focused on interfacing users to a data store.

The evolution of Personal Home Page (PHP) from a simple variable substitution tool intended to interface generic HTML scripts to personal data to full fledged web programming language still focused on linking scripts to databases mimics the growth of RPG very nicely.

I'm personally skilled with neither RPG nor PHP but, at least as far as I can tell, they both suck on all possible computer science school style evaluative criteria except one: they work, and work well.

So why?

My guess is that they work because they implement the same basic ideas about how business applications should work - and because those ideas are fundamentally right, even the first applications built using them work well - and widespread adoption then drives the further evolution of the language into a widely successful toolset.

So what's the model? simple: business applications are user interfaces to business data.

Bear in mind when thinking about this that the relational database wasn't developed as a data storage tool - storage wasn't the problem Codd went after: IMS was much faster than System/R and COBOL files worked very well for most applications. The problem was application stove-piping: the storage and use of the same data in incompatible ways across multiple applications.

Stove piping was a natural consequence of batch processing because that required each application, defined as a series of batch jobs carried out on packs of data cards in exactly the right order, to store and manage its own data; and that, in turn, led to what Sir Topham Hatt, in a very different context, called "confusion and delay" throughout corporate systems as different applications adapted the same data differently.

Codd's solution was to make all of these problems go away by forcing all application data access through the same interface to a shared file system. That idea then led him to apply set theory (known as the theory of relations when he went to school) to data as a way of managing redundancy and thus to the formulation of his relational rules - starting with rule zero: no access to data except through the shared data interface manager.

From there Chen (1974) and others further developed the theoretical foundations for the underlying applications model; IBM issued the RPG/System/R based System 38 in August of 1979, and everyone from 1920s style data processing managers to emeritus professors of computing science have tried desperately to kill it ever since - but that's the model that makes RPG a success, that's the model built into PHP, and really that's why I like two languages that seem otherwise unattractive.

Topic: Apps

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

24 comments
Log in or register to join the discussion
  • If it works for you, use it - but it doesnt work for me.

    If it works for you, and especially if it has an elegant simplicity, then go for it.

    However,

    [i]So what?s the model? simple: business applications are user interfaces to business data.[/i]

    I think that in many cases is too much of a simplification. What's missing is the "Business Logic", and in your model you're going to end up mixing that in with either the UI, or as stored procedures.

    If the business logic was as simple calcuating TVA due on a sales order, things would anyway start to get out of hand. Thrown in the need for ACID transactions, distributed databases, role based security, integration with business partners and/or your own legacy systems, support for offline users, increasing large amounts of data not well suited for an RDBMS, etc, etc, etc, and it becomes totally unworkble.

    We need development platforms that have the flexibility to handle all these many and varied problems, and that additionally scale well to the combined complexity of it all.

    It's exactly that goal that has lead n-tier architectures, and the likes of .Net and J2EE, and supporing middleware (MTS was ahead of its time, and calling it "COM+" killed it. J2EE has been rejected as too complex, and it appears that various WS-* protocals aimed at acheiving the same thing are again being rejected in favour of RESTful protocols which are too simplistic for many business apps).

    If you properly understand the problem, then you can understand this architecture. When you understand the archictecture you can start to reliably and quickly build robust, flexible and scaleable AND maintainable business apps.
    TheTruthisOutThere1
    • Of course there are exceptions, but...

      I think there are far fewer then most people think. For example, you say:
      ---
      the need for ACID transactions, distributed databases, role based security, integration with business partners and/or your own legacy systems, support for offline users, increasing large amounts of data not well suited for an RDBMS
      --
      ACID - a non issue for php or RPG
      Distributed DBs? again no issue
      legacy integration? no problem

      Off-line use? What's that? a batch op update requirement like a lotus resync? First I'd say that the existence of this kind of thing is often a design compromise and, second, I don't think it invalidates the model.

      And as for non RDBMS data types - I hear this a lot but i don't believe it. Do you know what Ingres stood for in the 70s? Know anything about postgres? Show me a data type I can't store efficiently in informix 10 a decade ago or DB2 now.
      murph_z
      • You completed missed the point.

        I made no comments about PHP or RPG - it was your overly simplistic archiectural model I have issues with.

        As you clearly think all the things I mentioned are part and parcel of typical business apps and "a non issue for php or RPG", surely you must be proposing all this code is bundled into the UI?

        Or do you think, just maybe, you might think about introducing an extra layer to handle business logic, and let the UI layer just be good at that?
        TheTruthisOutThere1
        • umm.. a little light reading perhaps?

          Interface != GUI; with php.. php code != browser code.
          --
          check out:
          Mosh? M. Zloof, "Query-by-Example: A Data Base Language", IBM Systems Journal 16(4): 324-343, 1977
          (inter alia)
          murph_z
          • You assume too much.

            I never mentioned GUIs or anything about PHP or browsers. Your words were:

            [i]So what?s the model? simple: business applications are user interfaces to business data.[/i]

            So, I'll ask again, if this is your preferred model, do you prefer to mix your business logic with a) "user interface" or b) "business data"?
            TheTruthisOutThere1
          • neither one

            I dispise stored procedures and don't do browser development.

            (You really need to step outside the PC world a bit - try figuring out what bportlock and I like so much about RPG on the AS/400.)
            murph_z
          • There is nothing specific to PCs in what I said.

            (and, FYI, I've been building business apps for 20+ years, the lions share not having been on PCs. Currently, .Net fits the needs of our target market (SMEs) extremely well - and that's good business for us and our customers.)

            As to "[i]neither one[/i]", how does that mesh with "[i]So what?s the model? simple: business applications are user interfaces to business data.[/i]"? Have you abandonded the notion of business logic as unnecessary, or are you conceding that you model is often too simplistic?

            In the last couple of weeks you argued against Java and denouced OOP as a dead-end.

            Now you're suggesting that two-tiered architecture based around PHP or RPG (neither of which you claim to know), an RDMBS, and business logic that lives in never-never land, is in fact the the development strategy of choice (except, perhaps, for a few "overestimated" exceptions).

            I think you should take some of your own advice, and try to figure out why so many of us in the development trenches use things like middleware, TPMs, application servers, OOD & OOP.
            TheTruthisOutThere1
      • Murph I think you'd like the organisation of Rails

        as that enables a lot of business logic to be encapsulated in "Models" (classes) that will then manage themselves database-wise.

        "But that's MVC" some will cry. Yes, but Rails has a wonderful implementation of it, and allows you to *not need* to put business logic into the RDBMS, which is great for cross platform considerations etc.

        The interface literally becomes layers into which you stick the data. A helping of Ajax then makes the backend and front-end much easier to deal with/use/maintain.

        All, of course, in the (initially quirky - like any language) easy and accurate Ruby language.
        fr0thy2
        • Mixed feelings

          I've played a bit with ruby on rails - there were things I liked, and things I didn't.

          Overall I ended up passing on using it as a primary toolset then mainly because of the run-time inefficiency - but I'm really not convinced for or against it.
          murph_z
  • Data To Documents

    PHP does abstract data retrieval and updates as SQL statements
    issued to a RDBMS.

    I'm not familiar with RPG, but I'm guessing it either hardwired
    the report to the data storage or abstracted the storage in
    some way so that an RPG module communicated to a driver.
    Codd (typo note: he is "Code" the second time his name
    appears in your article) thought that the mathematics of sets
    would solve issues related to hierarchical data storage and SQL
    was the formal language for set manipulation (with vendor and
    standardized throw-ins added for engineering concerns, which
    irritate the heck out of Dr. Date.)

    PHP owed its success in adoption to being lightweight, having a
    user-friendly license, and being easier than Perl. If Sun had
    been more welcoming of Linux and *BSD in the first 5 years of
    java's life, then maybe a lightweight java framework would have
    been as successful.
    DannyO_0x98
    • To clarify

      RPG is device independent. It treats everything - displays, printers, databases, communication interfaces as input/ouput devices and it doesn't give a d*mn about how they work - that is left up to the operating system.

      RPG owed its success to being small, fast and portable. RPG programs written on the S/38 or early AS/400 in the late 80s can have their [i]compiled[/i] code run on today's AS/400 because the virtual machine that RPG runs on has had a 128bit architecture for decades and the original 24bit machines, the 48 bit CISC machines, the PPC machines, the RISC machines and the current 64 bit AS/400 can all run the same RPG programs without recompilation.

      Not bad for a backward bit of "big iron" with no modern features.... ;-)
      bportlock
      • Agreed (NT)

        <P>
        murph_z
  • Please complete the thought.

    You describe the history of an approach and conclude with: "... IBM issued the RPG/System/R based System 38 in August of 1979, and everyone from 1920s style data processing managers to emeritus professors of computing science have tried desperately to kill it ever since ..."

    The way that you describe what's wrong with "it" is likely to imply the reason you think it can be used successfully. And, anyway, even if you expect your readers to have knowledge of a situation, leaving the end of an argument hanging seems inappropriate.

    This post politely overlooks the statement: "... they both suck on all possible computer science school style evaluative criteria ..." Daily publication deserves tolerance.
    Anton Philidor
  • Some advice for you Murph...

    .... writers are generally advised to write about whatever they know. You said:

    [i]"I???m personally skilled with neither RPG nor PHP but, at least as far as I can tell, they both suck on all possible computer science school style evaluative criteria except one: they work, and work well."[/i]


    Now, in my case I know them both extremely well. I programmed RPG for 16 years and PHP for 5. Let me fill you in....

    They both support OOP encapsulation and abstraction
    They both lack direct access to the underlying database
    They both make extensive use of databases rather than flat files

    RPG has had event driven programming since the 1980s
    RPG runs on a virtual machine (like Java)
    RPG compiles to an intermediate language (like .net's IL)
    RPG can be combined with modules in other languages (like IL again)
    RPG can be used in MVC configuration with DB/400 and SDA/DSPF
    RPG is device independent

    PHP supports modern constructs such as classes and interfaces
    PHP supports operator overloading
    PHP supports object iteration, cloning and reflection

    Now run it by me again on which "modern" features these languages lack.....
    bportlock
    • Support from the politically correct

      gee - :)

      ---
      here's a challenge: find a computer science text that speaks well of the System-38, RPG - or even mentions PHP without being condescending.
      murph_z
      • Huh?

        [i]"here's a challenge: find a computer science text that speaks well of the System-38, RPG - or even mentions PHP without being condescending."[/i]

        Why should I bother? Just because the texts think those languages are cr*p doesn't mean that they are. Abraham Lincoln used to say [i]"If we call a tail a leg, how many legs does a dog have?"[/i]. The answer is, of course, four! Calling it a leg didn't make it one. The texts you hint at reveal more about the author's prejudices than defects in RPG and PHP.

        All languages have shortcomings and the "perfect" language does not exist.
        bportlock
        • Duh

          RPG, like PHP, gets no respect - but works. (In my opinion because they reflect the same applications model.)

          See: we're on the same page here.
          murph_z
  • Once again, way past your level of competence

    I'm just so glad you admit you know nothing about these languages (and apparently programming in general).

    Now if we could convince you to stop making assertions based on your lack of experience...
    tonymcs1
  • RPG and AS400/S38

    RPG on AS400 is used to express the application logic. The layout of the viewable screens, data presentation format, textual description of data etc is performed and created by the programmer separately from the application logic. One can easily modify the appearance of the application long after the application logic is written without changing the application logic. End user language can also be accommodated to a large extent in this fashion also.

    In PHP, at least as I have seen it used, the application logic and the screen text and formats are intermixed.

    This seems to me an important difference that you have overlooked.

    Contrary to what one of the previous posts asserted the RPG programmer can produce ACID transactions. I was the RPG compiler team leader when transaction commit and rollback was added back in about the mid 80s.

    I believe the reason RPG and its AS400 runtime succeeded was that it was a simple to use relational data base on the back end and the equally simple to use separation of view from application logic on the front end. All the other languages on AS400 like Cobol, C/C++ had the same benefits.

    Free form RPG that was introduced in the late 90s made the language much more palatable to many people.

    I agree with Murphy that for moderate transaction rates PHP and RPG fill much the same need, although it would have been nicer if PHP could somehow have separated view from application logic. Of course by using a browser as the rendering engine PHP logic is considerably simpler than applications that are built with GUIs driven by C++ class libraries.
    gingoro
    • Lazy programming

      [i]"In PHP, at least as I have seen it used, the application logic and the screen text and formats are intermixed. "[/i]

      It doesn't have to be that way. It is easy enough to separate the form from the code. I agree that PHP [i]lets[/i] you mix the MVC components together, but that is no reason to actually do it that way. We have a data class, a form tool (let's call it SDA-PHP ;-) ) and the "classic" PHP script acts as the "controller" in MVC by coordinating the model and view components.
      bportlock