April 28th, 2008
RPG, PHP, and history
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.
Paul Murphy (a pseudonym) is an IT consultant specializing in Unix and related technologies. See his full profile and disclosure of his industry affiliations.
Subscribe to Managing L'unix via Email alerts or RSS.
| 04/28/08
