Process programming: passing into a new phase

• Published in: ACM SIGSOFT Software Engineering Notes
• Main Author: Balzer, R.
• Format: Article in Journal/Newspaper
• Language: English
• Published: Association for Computing Machinery (ACM) 1988
• Subjects: eskimo*
• Online Access: http://dx.doi.org/10.1145/75111.75113; https://dl.acm.org/doi/pdf/10.1145/75111.75113

Our whole experience, as a community, has been with a single type of program and its associated lifecycles, hereafter called Product Programs and Product Programming. Because of its importance to us as a multi-billion dollar industry, as our chosen profession, and as an intellectual challenge, we draw many distinctions within this broad category. For the same reasons, the Eskimo has 27 different words for snow to distinguish what for them are important differences. We naturally use this “vast” experience base to organize our view of the world. When new situations arise, we categorize them according to this existing structure, occasionally extending the structure by drawing finer distinctions. This is a very successful strategy and is the process by which community knowledge is built. However, this strategy is unsuccessful and quite debilitating on those rare occasions when truly new phenomena are encountered, because by operating at the micro level it tends to hide macro distinctions through a series of micro adaptations. Consider the dilemma of some hypothetical Eskimos who first encountered water and attempted to fit it into their “snow structure.” For them it was just a soft version of this rather obscure and troublesome form of snow called “slush.” This accommodation of the existing theory hid the fact that although there were some similarities and all the same “stuff” was involved, that because that material was in a different phase (as used technically in physics) it had fundamentally different properties which necessitated fundamentally different ways of handling it and different uses to which it was put. I believe that we find ourselves in just such a situation with process programming. It's constituted out of the same primitive components as product programs, but its organizational composition places it into a different “phase” of the material which gives it fundamentally different properties and forces us to handle and use it quite differently. We do ourselves a great disservice by adopting the ...