Communications of the ACM
Examples of Phenomenology in Computing
Way up in the rarefied air of philosophy, you will find phenomenology, the study of the first-person experiences of things as they appear. While it may seem that something so commonplace is of obvious interest, philosophy sometimes requires persuasion on such matters.
Widely regarded as difficult to explain, let alone dubious to propound, phenomenology directs out attention to our own conscious grasp of things, objects, and intangibles, anything in human life that garners attention in some way. We have Edmund Husserl and others before and after him to thank for this revealing proposal [Husserl, D. Smith, J. Smith]. But don't search the Web for a catalog of phenomenology results. It is honored mostly in the breach, as we say of endeavors that are casually promoted but rarely carried out. Phenomenology may seem to resemble other pursuits in computing, but it is not psychology, nor philosophy of mind: Phenomenology does not take its subject to be our minds, but rather the objects that we perceive with those minds. And it is not introspection, nor artificial intelligence: Phenomenology does not observe the working of our cognition, but rather the focus of that cognition.
My own work produced a result that can be attributed to phenomenology, in Hill 2016. And just this month, for the Fourth Conference in the History and Philosophy of Programming, held in Oxford on March 23rd, I undertook an inquiry into the phenomenology of programming. In phenomenology, we practice epoché (last two syllables are "okay"). That means asking what's really going on, free of preconceived theories, frameworks, or forms.
Consider an example from daily life: We often have to work with groups of duplicates, homogeneous sets of things such as cows or socks or chairs. Consider home-made jars of jelly, lined up nicely on a shelf. The first-person experience incorporates more than just the recognition of that bald fact; it involves satisfaction, pride, and a sense of a possession and control of useful items. Even leaving aside the affect (the feelings), the first-person experience involves both less and more than an analytical view would allow. Let’s compare the phenomenological treatment with the analytical view and its constraints.
- Count
- We step back and admire the jars on the shelf, appreciating the display with thoughts like "a goodly amount for charity sale; should bring in some modest funds." Now suppose that we want to keep track of how many we have, perhaps in preparation for an inventory program. In a clumsy pseudo-code that corresponds to no extant programming language, it might look like this:
type integer var jar_count;
In jar_count, we have made precise our notion of "a goodly amount for charity sale" with some numeric value. We have, therefore, discarded other counts that might have captured the same notion. We are now stuck with an associated natural number that demands a value, a value that may be modified, and can be ignored, but can no longer be finessed as "several" or "maybe not quite enough." - Property
- Our attractive jars of jelly are all the same size, "standard," but suppose that we want to note the exact volume to provide that data to potential buyers.
type real const volume=12.5;
We have to had to formulate a new property, volume, that did not exist in our earlier conception (and we will have to note somewhere the units used, ounces, perhaps). And what have we lost?—the ability to quash that aspect, the option to dismiss it, to pass it over because the approximate volume is clearly visible in the first-person experience of conscious sight. - Structure
- Suppose now that we have arranged the jars of jelly on the shelf with those ready for sale out in front. If we want to programmatically distinguish those that are ready—perhaps those that are clean and labelled—we incur a cost, an added constraint due to the necessity of attaching that property to each jar.
type boolean var ready-for-sale;
In order to accommodate this requirement, we need a structured variable such as the following.list of structure Jar { type real const volume=12.5; integer var ready-for-sale; } indexed by integer var inventory;Here the length of the list shows the total jar count.Our first implementation amounted to Class+Count (or Type+Count), where the item volume defined a class, or type, and the item jar_count defined the count. This second implementation is Array of Tokens, where the type is instantiated explicitly for each individual element. Each of these departs from the first-class experience, variation Class+Count because the attributes and number have to be ready to hand, and Array of Tokens because the individual items have to be indexed by some identifier. Each of these is artificial.
If the jars were all cleaned and labelled, they all would be ready to sell. The variable ready-for-sale that distinguishes among jars would no longer be pertinent, and the representation could fall back to Class+Count. In our minds, it would, with no trouble. We form and act on concepts independently of such details. We encounter no difficulty, no discomfort, no perspicuous stumble of any kind in moving between views from one moment to the next.
Modern programming languages, using list structures, may be able to define and redefine data structures quite efficiently. But the low-level structure that must be implemented in some physical memory somehow, in accord with the different conceptualizations, manifests in either one memory structure plus an integer taking up space, or several identical memory structures taking up space. Switching requires complete restructuring, where "complete restructuring" means recompilation (whatever that means in the cognitive case).
At each stage, the increasingly precise definition of the situation is required for the programmatic rendering, but sacrifices some aspect of the first-person experience. To claim that the first-person experience is defective or inadequate is to scorn the flexibility of imprecision, and the advantages conferred.
By rendering objects as, well, objects—the first "objects" being the first-person concepts, and the second, abstract data types—we clean and clarify them, picking them up out of a heap of messy conceptual detritus. But just what is the detritus? That’s what phenomenology would have us explore.
These questions of the fluidity of concept are not new, as they have been posed in several ways (although perhaps not in phenomenological terms) for decades. Many commentators have identified cognitive processes that do not seem to admit of algorithmic analysis. Currently, many experts expect that faster computation and vaster storage will accommodate such flow among cognitive states and processes (whether the flow is instantiated exactly that way in our brains or not). That remains to be seen.
References
[Hill] Hill, Robin K. 2016. What an Algorithm Is. Philosophy & Technology, 29:1. DOI:10.1007/s13347-014-0184-5.
[D.Smith] Smith, David Woodruff. 2016. Phenomenology. The Stanford Encyclopedia of Philosophy. https://plato.stanford.edu/archives/win2016/entries/phenomenology/.
[J.Smith] Smith, Joel. 2018. Phenomenological Reduction. Internet Encyclopedia of Philosophy. Date accessed: 20 December 2017. http://www.iep.utm.edu/phen-red/
Robin K. Hill is adjunct professor in the Department of Philosophy, and in the Wyoming Institute for Humanities Research, of the University of Wyoming. She has been a member of ACM since 1978.
[Posted March 29, edited briefly April 9 2018]
No entries found