|
|
|
I first encountered the work of the Persistent Programming Group at Edinburgh and St. Andrews around 1984. At that time I was consulting with GemStone Systems (then Servio Logic) on the design of their database machine and system. A fundamental shift was going on at the company, from implementing a nested-set data model on custom hardware to producing an object-oriented database that would run on standard workstations. I was trying to get my head around object-oriented programming in general and Smalltalk-80 in particular, and figure out what the challenges and advantages were for an object-oriented data model. Peter Buneman had visited the group in Scotland, and he pointed me at their work after hearing what I was working on with GemStone.
The cited paper is a short introduction to PS-algol, a persistent version of S-algol. It covers some of the design decisions in converting a programming language into a database language (such as how to indicate persistence and how to provide efficient access to large collections) and gives a brief overview of its implementation. (A pair of companion papers in Software - Practice Experience around the same time go into detail on the implementation.) The paper affected my thinking in several ways. First, it made me feel that trying to build a database system by adding persistence to an existing programming language wasn't such a nutso idea after all. Second, it showed me which aspects of the GemStone approach arose from it being a persistent programming language and which depended on object-orientation. For example, PS-algol had persistence orthogonal to type and persistence by reachability, so those aspects didn't require an object model. On the other hand, logical data independence via methods and extensibility via subtyping did depend intimately on having an object model. (However, the Scotland group showed later, by adding persistent procedures and a run-time compiler to PS-algol, that there are non-object-oriented means to achieve type extensibility.) Third, the paper helped me realize that there are common problems in turning any general-purpose programming language into a database system, such as the need for a common schema and associative query, and that there were implementation options I hadn't thought about, such as swizzling reference of objects in memory.
Copyright © 1999 by the author(s). Review published with permission.
