A personal research journal-cum-blog for my general project of introducing computer software developers to Philosophy and how it can apply to day-to-day programming and design. It is named after my special project of applying Existentialism’s motto “existence precedes essence”, generating a common theoretical approach to a diverse range of programming topics. [disclaimers]
This blog is normally about what computer programmers can/should learn from philosophers. Occasionally though, there is a posting like this about what philosophers can learn from programmers...
In An Introduction to Ontology[1], there is a discussion about whether holes “exist” (where “exist” has a technical Philosophical meaning). In laying out the pros/cons of defining a hole as a region of space, the (fatal?) flaw with the approach is claimed to be that, when the thing that had the hole in it (say a pair of jeans) moved to the next room, the hole wouldn’t/couldn’t move because it was defined as a particular region of space.
I, as a computer programmer, am left dumbfounded that anyone would make the definition of a hole be an absolute region of space, any more than they would define the geometry of each leg in the jeans as being an absolute region of space.
As modeled in typical vector drawing logic, the legs and the hole would each simply be a “part” of the jeans entity. Each part typically has attributes defining its contents (often simplified to just its color), so the left leg is denim/blue and the hole is void/transparent. Alternatively, the hole can be thought of as a “subtractive” part which simplifies the description of the geometry of things that have holes. (Beware of saying “that just simplifies the math but it isn’t real” because that's what they said when Copernicus noted that the math was simpler if planets orbited the sun rather than everything orbiting the earth).
CAD/CAM systems often model things as having parts known as features[2], which include not only subtractive “passages” (two openings, i.e. holes), but also subtractive “depressions” (one opening, i.e. dents) and subtractive “voids” (zero openings, i.e. completely enclosed). These are in addition to additive “protrusions”, “connectors” and “stand-alone volumes”. Don’t think a protrusion is an entity (or at least a part)? Don’t peninsulas exist?
So, just as no one has a problem with saying that the leg part of the jeans is a cylinder whose location is relative to the parent jeans, there should be no problem saying that the hole is passage relative to the parent left leg (just over the knee). After all, isn’t a hole always a hole in something? (yes, I know there is philosophical debate about this, like everything else).
The real head-scratcher, for me, is why it is apparently so non-obvious to the philosopher, that the textbook on this stuff simply ends the a-hole-is-a-region-of-space discussion with “this theory gets it thoroughly wrong”. There is no mention of “you know, there is a trivial rebuttal to that objection”. But that is why occasionally this blog has posts about what Philosophers can learn from Programmers.
[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013
[2] Parametric and Feature-Based CAD/CAM, Shah/Mantyla, 1995, Section 7.3.1 Form Feature Schema
In Paul Simon’s song “My Little Town”, there is the lyric “everything’s the same in my little town”. This can be contrasted with "the big city" that is cosmopolitan, multicultural, not all the same. It is only when you have the experience of more than one culture that it becomes natural to see that there can be more than one notion of how things are. In Philosophy, when there is one “correct” definition of something, due to it existing in nature, independent of man, it is called a “natural kind”. However, when something only exists because people have agreed to think that it does, that is called a “social construction”. Computer programmers need to be aware that, of the things they have to model in their databases, user interfaces & business models, most are social constructions, and hence, there are many ways to skin a cat, but not arbitrary ways. Two case studies are given that show how programmers can err on either side of the spectrum.
Social Constructs versus Natural Kinds
It is common to consider Natural Kinds to be “discovered”, and Social Constructions to be “invented”. An example of something that only exists because we say it does is money. A Bitcoin (or an ounce of gold, or a piece of paper with $100 printed on it) is worth whatever we say it is, and how many Big Macs can be bought with each is whatever we agree upon. And via the computerized marketplace, we can change our collective mind every microsecond.
Social Constructions are also inherently “relative” to some culture, which means that there can be more than one version of it floating around, and each can be equally valid. A traditional example is the definition of what it means to be a woman. While there are the aspects of womanhood that are controlled by DNA and biology, many aspects are defined by society, and there are many different definitions existing simultaneously.
On the other hand, we believe that atoms exists in nature. We may discover better definitions and understandings of them over time, but those would be mere changes in our knowledge of them, rather than making them an invention. When Europeans thought that swans only came in white, and then found black ones in West Australia, their definition of swan changed, but we still think that swans are in fact a natural species, independent of whether you’re European.
Natural Kinds that Aren’t
There are times that something is thought to be a natural kind, but later realized to not be, for example, planets. We thought that planets existed objectively and independent of our latest definition. We now realize that those orbiting chunks of rock and clouds of gas may exist objectively, but our classifications of “planet” versus “dwarf planet” versus “failed star” do not. I.E. they are arbitrary enough that aliens landing here will likely have different ways of classifying orbiting stuff.
Saving the Phenomena
So, if planets aren’t “real”, where did they come from? An early view of the universe was that everything literally revolved around the earth in a perfect circle, except for a handful of “wanderers”, the original meaning of planet. As we gained more knowledge, we would update our definitions. But we always (if only unconsciously) wanted to “save the phenomena”; in other words, make sure that the new definitions didn’t drop any planets and didn’t add any, otherwise, we would be defining something that did not match our intuitive notion of planets.
Of course, recently that became impossible because we realized that we were either going to have to add hundreds of new “planets”, or, drop Pluto, to be consistent. The more that people tried to keep the original collection, the more it became clear that the collection was based on culture and history rather than an objective category of things in space. Some even say that Jupiter is not really a planet, but a failed star.
Case Study: World Headquarters in My Little Town
The world headquarters of Coca-Cola is in Atlanta, and while a world headquarters would be expected to be pretty cosmopolitan, it is in The South which was traditionally very monoculture, conservative, and religious (which I can say because I grew up there). I was there, on a Y2K project, redesigning data files which were using just 2 digits to represent years (even though the file formats had been specified only two years previously, by the way). During discussions with the developers (all Atlanta locals), it was assumed that there was only one obvious “correct” way to represent dates in a string: mmddyyyy. Having lived overseas, I knew to point out that most of the world doesn’t do it that way, instead using ddmmyyyy, or yyyymmdd (and we did not even get into other calendar systems).
The point is that it was assumed that dates were a natural kind when they are actually very socially constructed. In my little town every thing is the same and therefore looks like the one and only way God intended.
Case Study: Bizarrely Arbitrary User Interface at domain.com
While the concept of “social construction” says that there can be several equally-valid ways of defining some things, do not forget about the “social” part! I.E. you should not create an arbitrary definition that no one actually uses and therefore no one will understand.
On the website of domain.com (a domain name registry provider), there is the domain name registration form which includes a mandatory phone number field. The required format is so bizarre though that it took a chat with customer support to figure out what is was. It turned out to require the phone number to be entered as the fractional portion of a floating point number…let that sink in…floating point notation, with a mandatory leading plus sign and mandatory integer of 1. So, phone number “(123) 456-7890” had to be entered as +1.1234567890 ...AND, to make matters worse, the error message received when it was not entered that way, only said that a legal phone number was required, without explaining what the non-obvious required format was.
When I pressed the support chat operator for an answer to my question, WTF?! , I was told (after some time on hold) that “that was the format that the developers chose”. There was no answer to my question: Of all the phone number formats on the planet, who has ever used that? Apparently it was the culture of domain.com off-shored contract developers with no managers who were engineers enough to review the design.
A 1960sTV seriestheme song began, "It's about time, it's about space...". Some, from Physics to Philosophy, say it's about both, claiming they are each aspects of a single space-time. Computer systems developers need to consider this as they build GIS applications.
Ontology, being the branch of philosophy concerned with describing "what exists", tackles the topics of Space and Time since they are often used to describe things. An Introduction to Ontology[1] devotes a chapter to each. As usual, things are more complicated than our initial intuition expects, and debate continues about different viewpoints. In a nutshell, the following are discussed:
Space is usually defined in terms of "regions"
Space is either absolute or relative.
Space is either something things "are in", or it is synonymous with the thing itself i.e. regions only have properties like size and location, versus, a region itself having the property blue if the stuff in it is blue.
Space is either Euclidean or not (i.e. flat or curved)
Space is either separate from Time, or parts of the same thing: space-time.
Most programmers today, in the age of Map apps, Geographic Information Systems, and geocoding, take the view that an entity such as a business or address is located at some location. The location ideally could be defined as a collection of regions defined by GPS coordinates. Often, the location is (over)simplified to a single point on a map.
While it is recognized that many problems exist with actual databases of geocoded entities, it is usually assumed that they are in the realm of epistemology rather than ontology. In other words, it is assumed the problem is with "our knowledge" due to inaccuracies in the set of GPS coordinates; not that locations don't actually have a definite set of coordinates.
However, not every entity that takes up space has a well-defined and unchanging mapping to a set of GPS coordinates. ZIP codes, for example, are not defined in terms of geography but rather as collections of delivery routes. Another example, as shown in the title insurance case study below, is in real estate legal descriptions. In addition to a knowledge problem caused by ambiguous language used in these descriptions, they can also refer to ephemeral landmarks.
While a naive assumption that space is different than time is often made in data model design, entities like ZIP codes and Legal Descriptions require a time dimension to be completely accurate. It turns out that the mapping of zip codes to postal routes changes several times a year. And landmarks, referred to in property descriptions, can change location and shape over time.
Case Study: TICOR Title Insurance System
OMEX was a startup that was an early pioneer in creating optical disk technology for data storage. It took on a contract to produce a computer system to support TICOR, the largest title insurance company in the U.S. TICOR itself had the contract to keep backup copies of all the real estate transactions filed with Los Angeles county. As a part of archiving copies of the documents, it was free to use the information in them, and hence support its business of providing title insurance. The computer system was to replace using microfilm photos of the documents with optical disk storage of the images. It would link these images with a structured database of information related to each property. One of the goals of the database was to enable answering basic questions about property locations.
The programmers, having a naive notion of how property boundaries were defined, were surprised to see that a common method is “metes and bounds” which uses plain english descriptions using landmarks. E.G. "beginning with a corner at the intersection of two stone walls near an apple tree on the north side of Muddy Creek road one mile above the junction of Muddy and Indian Creeks, north for 150 rods to the end of the stone wall bordering the road, then northwest along a line to a large standing rock on the corner of the property now or formerly belonging to John Smith, thence west 150 rods to the corner of a barn near a large oak tree, thence south to Muddy Creek road, thence down the side of the creek road to the starting point."
As can be seen, it would be difficult to translate this into a collection of GPS coordinates. But even if you did, you would not be done with the problem. Like ZIP codes that change over time, the location and shape of creeks, rivers, etc change over time. Lest you think this is a merely theoretical problem, for centuries, States have sued each other over land ownership due to border rivers migrating over time.
Ultimately, the computer system wound up just using unstructured text fields to contain the legal description rather than the more ambitious GIS database they had originally promised.
[1] An Introduction to Ontology, Nikk Effingham, Polity Press, 2013
[2] A River Runs Thru It, How the States Got Their Shapes, History Channel, 2011
Amongst the surprisingly simple ideas that aren't so simple when thought about Philosophically are holes. There is a small library of publications on what exactly holes are. A summary can be found online in this Stanford Encyclopedia of Philosophy article on the metaphysics of holes. One of the viewpoints it cites is: ‘There is no such thing as a hole by itself’ (Tucholsky, 1930). This reminded me of one of my very first blog posts from 2000 which I reprint here...
There is no such thing as a Component
I maintain that there is no such thing as a Component in the same way that there is no such thing as a donut hole. Just as the donut hole doesn't exist without a donut to define it, a Component doesn't exist without a Framework to define it. Using a printed circuit board as a metaphor for a framework, it's the "sockets", into which IC chips are meant to be plugged, that define components. So called universal or standalone components are meaningless (and certainly useless) without some framework that expects components of the same purpose and interface.
Ok, so what's your point? The point is that too many developers (and books on the subject) think about components as standalone chunks of functionality that can be "glued together" after the fact. They don't realize that the framework has to come first and foremost in conception and design. Szyperski doesn't get around to talking about frameworks until chapter 21 of his Component Software book for heaven's sake.
Even physical components are like this. The prototypical component, the IC chip, always was designed within a family of chips that were meant to work together. They all needed the same voltage levels for zeroes and ones and tri-states, the same amperage levels, the same clock rates, etc, etc. Other families used other voltage levels. The first reusable, interchangeable parts in history were for rifles. They were meant to be easy and quick to replace (as opposed to the hand crafted muskets they were replacing) but they were meant specifically to make rifles!
Rummaging around a garage, you could find all sorts of "widgets" and "gizmos" that you might guess are components of something, but unless you know what framework they were meant to be a part of, they are not good for anything but door stops or paperweights. In other words, random components don't tend to fit together or work together.
Too many people are trying to make "universal" components without realizing that those components still work within some framework that allows them to be put together and communicate with each other. The problem is that other people doing the same thing have defined other "generic" frameworks that are none the less incompatible.
For example, the toys that baby boomers played with when they were young abounded with generic frameworks of universal components: Tinker Toys, Lincoln Logs, Erector Sets, LEGOs. They all had universal components within a generic framework that let you build anything. BUT, you couldn't mix Tinker Toy parts with Erector Set parts (without glue or duct tape).
Ah, you say. That's why I like duct tape, weakly typed, languages like Perl that lets me glue together parts. Also, what about Play-doh?! You could stick anything together with that! Yes, but there was a reason you made bridges out of Erector Sets instead of Play-doh, and the same reasons apply to software systems (but Strong versus Weak typing is another discussion).
Objects versus Components
Until I had this epiphany about components as donut holes, I didn't have a good answer to the question "what's the difference between an object and a component?". I now understand that all objects ARE components, but not all components are objects. The framework that defines a set of components does not have to be an object oriented framework. But all object oriented languages define an object framework. They are generic enough frameworks that any objects programmed in that language may inter-operate with each other. Unfortunately though, as with Tinker Toys and Lincoln Logs, Java objects typically can't interact with Smalltalk objects.
In the Java language there are at least two levels of object framework. There are plain old Java objects (POJOs) and there are so-called JavaBeans. Whereas any property of a POJO can be accessed (assuming its not protected by the "private" keyword) via a fooObject.barProperty syntax, only special properties may be accessed via the JavaBeans framework. JavaBeans are those objects that have defined special property accessor and mutator methods of the form: getBarProperty() and setBarProperty(). "JavaBean" is the name given to any component that works within that specialized framework. To make matters confusing however, it turns out that Javasoft called more than one framework "JavaBeans" (arrgh!). There are even more specialized versions of JavaBeans that are made to work with fancy GUI toolkits. And of course, they caused even further confusion by calling yet another (different) "widget", from yet another (different) framework, a JavaBean: The Enterprise JavaBean! So, without clearly focusing on frameworks, even Javasoft confuses different component types with each other!
The moral? Don't fret that there is no such thing as a truly "universal" component. Don't spend energy trying to build them, or building "single universal" frameworks. Focus on what is needed for your situation and design a well crafted framework first and foremost. If it needs to work with other frameworks (like whatever Microsoft builds that won't integrate with anybody else), understand that framework bridges will be needed. It is the rare case that a mere "socket adapter" will suffice.
In an earlier post, I advocated adopting Philosophers' practice of considering the purpose of a thing when creating a definition for that thing. Plato and Aristotle would have said that one of the things that made an acorn, an acorn, was that it had the "goal" or "purpose" of becoming an oak tree. In defining a domain model (aka business objects model), document the "purpose" of a class in order to get at its true attributes and behavior. But, as I was recently reminded, not only can the purpose of a thing be "in the thing itself", it can also be solely in our minds. I.E. it begs the question: if we are defining a class of things, what is our purpose in caring if we know that something is one of those things?
I had this AHA moment after reading the article "Unclassified" in the June 2010 issue of Discover magazine, where I was surprised to learn that there is no accepted universal definition of a biological species; there are at least 20+ competing definitions. I had thought that "being able to breed fertile offspring" was the definition, but that is only one (and of course it leaves out the vast majority of living things on earth that reproduce asexually).
After having read about all the conflicting ways to organize and cluster individuals into species, each one with its own way of looking at things, it begged the question: Why do you want to know? I.E. What is the purpose of knowing which species something is?" Depending on why you want to know, you choose one definition over all the others.
But of course as Darwin thought, this would mean that species are not "real". Instead of discovering pre-existing forms, we would merely be inventing arbitrary sets of attributes-in-common. Therefore, unlike the "teleology" of Plato and Aristotle where the "purpose" or "goal" of a species is internal to itself, it would seem that a possibly more important purpose is the one that WE have in wanting to place a particular into that species.
For example, Ponder all of the various shapes, sizes, forms, etc of things that you would want to call a "chair" [and do a Google image search of "chair"]. Now, ponder coming up with a universal definition of chair (such that all chairs would be recognized as such, and nothing else would), and you will see that it will be much easier if you can refer to the purpose we have for them; i.e. being able to sit (comfortably?) on them. Without that, it is hard to distinguish between a storage box (not a chair) and a storage bench (a chair). [Try it. Do a Google image search for storage box and then storage bench.]
In this sense, a species would be more like a Java Interface than a Class. Classes usually embody the pre-existing forms viewpoint, i.e. the notion that attributes and behavior are really "in the thing" rather than merely "how we want to look at it". And while in practice Interfaces are often just wrappers around class definitions, ideally, each Interface defines a standard socket into which an object of any "form" may fit, as long as it can perform a certain "role" and participate in a certain "protocol" (see my definition of component).
SO, the lesson to learn is: When considering the purpose of a thing as a part of its definition, "purpose" is both its purpose, and our purpose for wanting to recognize one in the first place.
In heeding my earlier post which advocates that "wholes" be analyzed and modeled, rather than just their "parts", there is the danger of swinging to the opposite extreme of not considering parts as "individuals". After all, if one can model an entire Car as having a paintColor property, with a simple value of Red, then there is no need to model Paint as an entity on its own, much less PaintMolecule or Atom.
When the parts of X are considered "stuff" instead of "things" (e.g. paint versus wheels), or, when their abstraction level is so low that they are interchangeable (like WHICH carbon atoms are in the paint), it is usually concluded that they are outside the scope of X’s model because they make no difference at the level of the whole X. And certainly, if a whole has a property, there is no need to have each part redundantly carry the same property just to parrot the value of the whole. For example, the case study in that earlier post chronicled the “BigBank” database, in which the record for each obligation in a facility redundantly recorded the same single “facility grade”, even though they were always graded as a whole facility.
The problem, of course, is knowing which parts are relevant at the level of the whole (i.e. the granularity of the model). In recent science news, an example of this quandary has arisen which illustrates how parts that were considered “stuff” are really individual things. It turns out that the rare chicken who grows up half-male and half-female does so in a way that is different from humans and other mammals.
Until now, it’s been assumed that body parts (and hence their constituent cells) always grew up male or female because external hormones told them to, and told them to as a whole. The Nature paper announced the discovery that each cell in a half-and-half chicken has maleness or femaleness as an intrinsic property from birth. In mammals, if you transplant a formerly “male” cell into a “female” organ, it will start working as a female, whereas in chickens it will keep acting male. To switch metaphors: It turns out that the car wasn’t painted red and green after the fact; each car part was already red or green ever since its manufacture, and each is resistant to change. So, cells/parts have to be modeled individually if you are building chickens/cars.
Of course, if you are only collecting (and not building) cars, you might still think of color as a property of the car as a whole. But here is the sticky part…a painful situation occurs when the car collector later needs spare parts, but their inventory database was never designed to track part colors. I have often encountered this situation in corporate/enterprise systems that are too brittle because their data models were overly simplified. Sometimes the problem is that the designs were based on short term goals. [This mistake is exacerbated by some development “methodologies” that advocate only designing for today’s needs.] Other times, problems result from making quick assumptions about the nature of things being modeled rather than taking a deep look (i.e. using the fruits of Philosophy’s “best practices” as developed over 2500 years). The case study ahead illustrates this scenario.
This case study comes from another BigBank project where there was an enterprise-wide project to revamp systems to use a single standard ID number for each customer. Their (initial) proposal was published after over a year of analysis and requirements gathering. But, from the very beginning, a Customer was intuitively defined as synonymous with “legal entity”, where a legal entity has only one government Tax ID (e.g. SSN, EIN).
Because only the whole was modeled, all the other systems that needed parts granularity balked, and the project had to take another year to rework its proposal. Many systems and business processes needed to work with individual stores, branches and managers, and they depended on having a separate “customer ID” for each location. While many companies have separate corporations (i.e. tax IDs) for each branch, some very large companies (e.g. Walmart) do not. Because many systems and business processes required a single bank officer to service a single customer, it would have forced thousands of branches onto a single virtual desktop. It also turned out that, while cities have a single tax ID, some parts (e.g. the City of Atlanta) are not legally liable for the debts of other parts (e.g. the Atlanta airport) even though they all share the same single tax ID.
So, without sufficient analysis, things that seem like wholes, can really be collections of parts.
One of the oldest puzzles in Philosophy is the paradox of how something can change and yet still be considered the same thing. After all, if “same” is defined as “identical; not different; unchanged”, then how can it “change”? On the other hand, even if I lose that hand (pun intended), I am still the same me. In chapter 5 of Peter Cave’s new book, “this sentence is false”[1], there is a collection of example paradoxes that illustrate how our intuitions about “sameness” are inconsistent. Some paradoxes involve entities (or properties) whose definition is "vague", as in “How many cows make up a herd?” or “At what weight does adding a pound change you into being ‘fat’?” However, here I will be focusing on the change paradoxes involving things with a well defined set of parts. They illustrate the problem with defining something as merely the collection of its parts (unless of course “it” is truly only a collection, and not an entity in its own right).
George Washington's axe Harry: I have here the very axe with which George Washington chopped down the cherry tree. It’s been used by my family for generations. Sally: But this says “Made in China”! Harry: Well, over the years, the handle was replaced each time it wore out. Oh, and the blade’s been replaced a couple of times too. Sally: But those are the only two parts…that’s not the same axe at all then!!
Ship of Theseus (original paradox by Plutarch) Theseus had a ship whose parts were replaced over time such that, at a certain point, no original pieces were left. How can the latter ship be said to be the same ship as the original if they have no parts in common?
(sequel paradox by Hobbes) Suppose that those old parts were stockpiled as they were being replaced, and later they were reassembled to make a ship. NOW, which ship is the same as the original ship; the one with the original parts, or, the one with the replacement parts?
At the bottom of these paradoxes is the question of whether a thing-made-up-of-parts is the same as the collection of all its parts. I.E. can everything that can be said of the whole thing be equally said of the collection of all its parts, and vice-versa? For 2500 years, western philosophers including Socrates, Plato, and Aristotle, right through to the 21st century, have been debating this question, generating whole libraries of book and papers. In fact, Mereology is an entire field of study that is just about the relationship between parts and their respective wholes.
What does it mean to be an individual?
As discussed (at great length) in the book Parts[2], there is a whole spectrum of things in between “individuals” and “groups”, and they are referred to in everyday language by singular terms (e.g. person), plural terms (e.g. feet), and some words that could mean either (e.g. hair). There are individuals (say, a car), parts of individuals that are themselves individuals (say, a wheel), parts of individuals that are NOT themselves individuals (say, the paint), collections that do not form an individual (say, “the wheels of that car”), collections that DO constitute an individual (say, the car parts that comprise the engine where the engine is itself an individual), and so on, and so on.
A key to distinguishing whether a thing being referred to is truly a thing in its own right (and not just a plural reference masquerading as a single thing) is what sorts of things can be said about it. Orchestra is an ambiguous term because it can be used as a singular or a plural as in “the orchestra IS playing” vs the equally grammatical “the orchestra ARE playing”. If it is considered an individual then we can say things about its creation, its history, etc, whereas the plural use simply denotes a collection of players where not much can be said about “it” apart from the count of players, their average age, etc. Relational Database programmers will recognize individuals as those that get their own record in some entity table, and plurals/sets/collections as equivalent to the result set from some arbitrary query. SQL aggregate functions (like count, average, minimum, maximum, etc) are the only things that can be said about the result set as a whole. Result sets do not get primary keys because they are not a “thing”, whereas real individuals do (or should!) get their own personal identity key. Even when an arbitrary query is made to look like an entity by defining a “view”, it is not always possible to perform updates against the search results because the view is not a real entity.
What does it mean to be the same?
A big problem is that there are many different flavors of “sameness” when we say that A is the same as B. Right off the bat there is a difference between Qualitative identity versus Numerical identity. Two things are qualitatively identical if they are duplicates, like a pair of dice. Two things are numerically identical if they are one and the same thing, like the Morning Star and the Evening Star (both of which are, in fact, really the planet Venus). They are “numerically” identical in that when counting things they only count as one thing. Another complication is that there is a difference between identity (right this second) versus Identity over time which deals with the whole question of how something can be different at two different times and yet still be considered the same thing. For example, you are still considered numerically identical to the you of your youth even though you have clearly changed…although this gets into the even more involved topic of Personal Identity [which may or may not apply to an axe ;-) ] Traditionally, if x was identical to y, and y was identical to z, then x had to be identical to z. Relative Identity has been proposed such that this need not be true, thus allowing both the morning and evening stars to be identical to Venus but not to each other.
When specifically asking whether the paradoxical ships and axes are numerically identical, as Peter Cave points out, two of our usual criteria for being “one and the same thing” are in conflict. They are (a) being composed of largely the same set of parts, and (b) being appropriately continuous through some region of space and time. The continually refurbished ship meets (b) but the reassembled original parts meet (a).
In traditional logic, as formulated inLeibniz’s Law, two things are the “same” only if everything that can be said about one thing can also be said about the other. In other words, all the properties of each object/entity need to be equal if they are one and the same. By this token, the two axes and the various ships are not the same. Of course, this means that ANY change to ANY property causes the new thing to not be “the same” as the old. To avoid this, others have said that only essential and not accidental properties should be compared. This means that the definitions of “ship” and “axe” should distinguish between those properties that must remain the same throughout the lifetime of the object versus those properties that may change over time.
Java Programmers can relate to the philosophical meanings of “essential” and “accidental” in the following way. [To keep this sidebar simple, think of “entity beans” where only one bean/object/instance is allowed to represent a particular real world entity (e.g. {name=Joe Blow,ssn=123456789})…i.e. there are never multiple object instances in RAM simultaneously representing Joe.] Class definitions could have “essential” properties implemented via constants (i.e. final instance variables initialized in the constructor ala the Immutable design pattern). And, “accidental” properties are implemented via normal instance members.
The essential properties must be final because if their values were different then they would have to be a different individual. E.G. If an instance of class Person has a constant DNA_Fingerprint_Code with value of 1234567890, it would not be correct to change that value on that same object because a person’s DNA both defines them and never changes; i.e. “essential” in the Philosophy sense. The correct procedure would be to create a new instance of Person because it must truly be a different person if it has different DNA.[Of course, this brings up the whole separate topic of the difference between changing a property’s value because it has a truly new value versus merely correcting a mistaken value. Normally, computer software has not been designed to make this distinction even though it would make some systems much more robust, and able to reflect reality better if they did.]
The putative method IsTheSame(Object o) would compare either all properties, or only essential properties, of this and o depending on your philosophy.[This also brings up the whole separate topic of the Java equals() method, and the many potential meanings of “equals” apparent when thinking Philosophically.]
More than the sum of its parts
So, the particular individual parts of a thing need not all be “essential” properties of that thing, and hence they may change without affecting that thing’s identity. (You are still you even if you lose a leg or lung, but not a head). Well then, what are some potential essential properties of an individual thing? Many advocate taking a look at Aristotle’s “four causes” of a thing, where he defined “cause” as anything that was involved in the creation of that thing. His two main varieties of causes were intrinsic, for causes that are “in the object”, and extrinsic, for those that are not. The two sub-varieties of intrinsic causes were material cause (the material the thing consists of) and formal cause (the thing’s form[OOP programmers think Class]). The two sub-varieties of extrinsic causes were efficient cause (the “who” or “what” that made it happen, or “how”) and final cause (the goal, or purpose, or “why”).
By analyzing the paradoxes using Aristotle’s causes it can be argued that the Ship of Theseus is the same ship, because the form does not change, even though the material used to construct it may vary with time. Also, the Ship of Theseus would have the same purpose, that is, transporting Theseus, even though its material would change with time. The builders and tools used may, or may not, have been the same, therefore, depending on how important the efficient cause is to you, it would make more or less of a difference. So, giving priority in definitions to some causes over other causes can answer riddles like these.
Further more, analyzing the “causes” of a thing’s creation, forces one to agree on when a thing actually comes into and out of existence, how to tell it apart from other similar things, how to count them, how to recognize it again in the future, and so forth. Circularly, Causes also provide justifications for those agreements. These criteria for identity help define the sortal definition of the thing (i.e. knowing how to sort these sorts of things from other sorts of things, and being able to count them on the way).
Case Studies: BigBank “Facilities” and “Customers”
I worked on some projects at "BigBank" (a recently defunct Top-5-in-the-USA bank) where these Philosophy-inspired techniques would have really helped. Here are two case studies that illustrate the problems of modeling the parts but not the wholes.
In the first case study, BigBank (in order to meet new international banking standards) needed to retrofit its computer systems to record and report on their track record in guessing whether loans would be paid off eventually. Each guess took the form of a “default grade” for a package of loans, each known as a “facility”.
A major problem was that their various systems did not agree on the basic definition of “facility”. This was because the definition of a “facility” went so without saying that no one actually said (in a rigorous way) what it was. Everyone interviewed knew intuitively what one was but couldn’t quite put it into words, and when pressed, it turned out that they all had different definitions from each other. As a result, the various systems around the bank were built with different ontologies (i.e. models of the world). A key problem was that many of BigBank’s systems assumed that Facilities were no more than the collection of their parts, and so only the parts were recorded with no standard place to say things about each Facility as a whole. As a result, it came as a surprise to everyone that there had never been any agreement as to when which parts belonged to which wholes, nor even when any particular whole Facility came into or out of existence. Consequently, BigBank had several different “Facility ID”s, none of which agreed which each other, hence, no way to definitively report on the history of any particular Facility.
CASE STUDY: At BigBank, credit grades are calculated for "facilities". A facility is a collection of "obligations" (i.e. loans, lines of credit) that are being considered together as a single deal and graded as a whole. The particular set of obligations grouped into each "facility" changes over time as individual obligations get paid off or expire. Plus, changed or not, the facilities are supposed to be re-graded from time to time. Unfortunately, some key BigBank databases only had records for individual obligations. There was no Facility entity table.
So, for example, whenever a "facility" was (re)graded, in reality, only a set of obligation records were updated, all with the same single “facility-grade”. In fact, other than the loan officer's neurons, there was no record of which obligations had been associated with which "facility" over time. So, when there was a new requirement to store for each facility all its grading documents, there was no place to put them. Even worse, since a Facility entity had never been formally defined, the analysis had never been done to make sure everyone had the same definition of a "facility" (which they didn't). There was no agreement on what the thing being graded actually was! For some, each individual grading event was considered a "facility" (along with its own "facility ID") because "the grading sheet is what is graded".
A second case study (which I detailed back in 2006) involves BigBank's treatment of customer information. Some BigBank systems defined Customer entities and assigned a single ID for each one, but other systems gave the same person or corporation a different ID in each state and called them Obligors. Once again, some systems modeled only the wholes (i.e. customers) and other systems only modeled the parts (i.e. obligors). And once again, because the systems working at the parts level did not tie them together as a whole, there was disagreement about which obligors belonged to which customers. It had become so bad that the data model had to be changed to allow multiple customers to be tied to a single obligor, lest conflicting data feeds go unprocessed. It was like having Person records and BodyPart records, but needing to kludge in the ability to have multiple people associated with the same particular foot!
[1] chapter 5, this sentence is false, Peter Cave, 2009, Continuum, ISBN: 9781847062208
[2] Parts, Peter Simons, 1987, Oxford University Press
[3] Introducing Aristotle, Rupert Woodfin and Judy Groves, 2001
In writing earlier about a programmer’s take on the debates in the Philosophy of Action, there was a particular philosophical argument that I wanted to delve into separately because I have a suggested solution. [Notice how my intention was to not write about this while writing earlier.]
Recall that in Action Theory, loosely speaking, Events are general cause & effect “things that happen”, and Actions are things that someone (aka the Agent) does on purpose, usually involving some “bodily movement” to get things rolling. One of the debates is whether Actions are, in fact, Events or not. [For object-oriented programmers, the question is whether “class Action extends Event” or not.] Jennifer Hornsby[1] argues that the “standard story of action”, with its focus on body movements, and its claims that all actions are events, is off-track because it leaves out NOT moving (e.g. not eating that ice cream because of a desire to be thinner, spoiling the party by not turning up, etc.).
There is a subtle philosophical point here: Events are considered particulars, i.e. individual things that “exist” in the sense that each is associated with a span of time and a region of space (when and where the event occurred), and one can (figuratively) “point” to it, and count it, and tell it apart from other events. Additionally, it is common in philosophy to maintain that a “hole” (the lack of something) doesn’t exist as a particular. After all, I can’t count how many green things are not in this room, nor point to each of them, nor tell them apart from each other. So, the argument goes that since you can intentionally “not wink at me” (by definition, an action), Action can’t be a subtype of Event.
However, in thinking about what it would mean for a computer program to “not do some action”, I realized there was a way to pinpoint those occasions. For example, in special game playing programs, moves are considered, compared with other moves, and ultimately one is chosen with the rest being rejected. It seemed to me that the rejected moves are "not done" in an "intentional" fashion, in contrast to moves that were never even considered. Game programs are a particular form of the general class of programs that generate "plans" to reach some goal not unlike humans. Actions are considered or rejected as the plan is being put together. Also, in everyday programs, the logic decides to call a subroutine or not, thus the routines are intentionally not called sometimes, in contrast to not doing things that aren't even in the program. It makes sense to say that routine A was "not called" x number of times, but no answer other than zero seems to make sense when asking how many times did the program not go to Mars.
So, I came up with a theory of how one can count, for a given situation, actions that are not a positive performance (i.e. that are not “doing something”). By “given situation” I mean a particular period of time and an area of space (for example, the duration of time we were together at this table for lunch today). To count how many times an event A did not occur in a given situation (e.g. you not winking at me during lunch):
1) establish the minimum time span that actually doing A once would take, including any time needed to separate one occurrence from another. Dividing the situation duration by the minimum action duration would establish a maximum potential count. (e.g. lunch was an hour, a wink takes a second plus a second in between, therefore a potential maximum 1800 winks over lunch)
2) establish what conditions are required for A to occur once (e.g. we both must be at the table with eye contact), and eliminate all the time spans where the conditions did not hold (e.g. I was in the restroom for 10 mins, you were talking to the next table for 15 minutes, so a tighter maximum would be 1050 winks)
But, to count how many times the action A did not occur in a given situation, there must be intention. In order for “not doing something” to be an intentional action, the agent must consider doing A and decide not to. And, the required conditions have to be met otherwise the action couldn’t have taken place anyway (i.e. motive and opportunity).
3) So, the actual number of occurrences of “not doing something” is how ever many times the agent considered doing it, and didn’t, when they could have. E.G. you thought about winking 5 times while we had eye contact but only did once…the 3 times you thought about it while I was in the restroom don’t count, so, you didn’t wink at me 4 times.
Interestingly, the time it takes to consider and reject doing something may take much less time than the doing of it, so, the maximum potential number of times something wasn’t done may be much more than the max. potential times that it was. One might get-pregnant twice a year but not-get-pregnant 3 times a week.
Finally, because one must consider (not) doing something in order for it to count as an action, one can say confidently that some things did not occur zero times. There were zero times that I did not give you a unicorn (because there are no such things, hence no opportunity). There were zero times that I did not stand on your shoulders because it never even entered my mind.
A couple of years ago, I mused on the (possibly fatal) limitations of having Rationalism as the fundamental basis of the Semantic Web. Recently in the Communications of the ACM, an article added another example to the list of things that can be "known" but can't reliably be put into words. In Face Recognition Breakthough[1], a new technique was presented that performed significantly faster and with more accuracy than traditional face-recognition techniques. The basis of the technique was so surprising and counter-intuitive that, as recently as 2007, papers about it were rejected by mainstream computer vision conferences.
In very simplistic terms, the new technique finds the most compact way to represent the pixels of a picture (of say a face) by throwing them at a random set of numbers and seeing what sticks. That compressed data is compared directly with compressed versions of other face pictures to find the closest match. (If you really want the gory math details, see this video lecture.[2]) What is DOESN'T do is all the traditional figuring out of where eyes and mouth and nose and ears are, and calculating the relationships between their locations, distances, etc. In other words, it doesn't work by analyzing a face into words/concepts (eye, nose, mouth, etc) and specifying relationships between them. It DOES do weird math using random numbers that is irrational in the literal sense of the word. And apparently this weird math not only works, it works better!
The 2007 rejection of the papers as presenting outlandish claims was based on the same bias as rationalism has; if you can't put something into words, much less rational arguments, its not true, and its not knowledge. Just as neural-nets do, the mechanics of sparse representation and compressed sensing encode "knowledge" in a form that is completely unintelligible to us humans when we look at the "raw data". And while techniques that DO use more human-reason-friendly ideas are available, they often don't work as well.
[1] http://portal.acm.org/citation.cfm?id=1536616.1536623
[2] http://content.digitalwell.washington.edu/msr/external_release_talks_12_05_2005/15994/lecture.htm
Note: use IE browser; also you can skip forward past 46 minutes of theory to go directly to applications.
In my earlier blog entry about Russell's Theory of Descriptions, it gave the example of rewording "The present king of France is bald" into a special descriptive form. You may have noticed in that discussion that the phrase "X is kingly" was used instead of a more natural sounding "X is a king". This is because Russell was attempting, via his special form of making statements, to remove all implicit claims that X exists, to be replaced with mere descriptions of X.
Programmers should think of this as the difference between:
"(xinstanceof King) && x.bald && x.french"
versus
"select * from AllThingsTable where french='Y' and bald='Y' and kingly='Y'".
The former would blow up in Java with a null pointer exception if X didn't exist, whereas the latter in SQL would not blow up; it would merely return zero results meaning that none exist.
In philosophy, nouns are reworked into adjectives and even verbs all the time to make statements more precise. In Russell's template, nouns are reworked into adjectives. In process philosophy (where everything is considered a "process" rather than a "thing"), a "king" would really be considered the process of "kinging".
Lest all this awkward wordsmithing seem too artificial, a quick look at McWorter's video introduction to linguistics[1] will show that what seems natural to us, is English specific. He gives the example of "I like Pam", where "like" is a verb, but in Japanese, the equivalent "Pam ga suki" literally means "Pam likeableness". So, a concept in one language may naturally be an activity, but in another language, it's a noun form of an adjective.
While reading Looking at Philosophy[1], I came across its discussion of Kierkegaard saying that there is some existential being that is left when all the "roles" of that being are stripped away. With my advocation in Existential Programming that "roles" be promoted over "is-a subclassing", it begs a deep question. If we have factored out all state and behavior from a class, moving them into various roles, when do we know that it is time to create a new instance of a "thing" to which roles will be attached?
For example, in a language like Javascript, one can create an empty object instance and dynamically add in attributes and methods later. This capability can be used to implement "mixin" classes that each encapsulate the properties and behavior associated with some role.
While it is true that we can program the operations of instantiating an empty (i.e. essence-less) object and graft in the mixin classes for each role we expect to fulfill, the Philosophical question is, how could we know that a new blank instance is needed if we didn't have a particular "thing" in mind in the first place? I.E. doesn't a thing still have to start as a particular "kind" of thing in order to know when it is time to create a new one?
In still other words, is there an actual case of a "thing" that consists only of roles? Are we sure that one of those roles isn't a thing itself? Does the technology give us the capability to do something that makes no ontological sense?
[1] "Looking At Philosophy: The Unbearable Heaviness of Philosophy Made Lighter",2005, Palmer
In the early part of the book The Stuff of Thought by Steven Pinker, the problem of what-a-name-names, is explored with the example of Shakespeare. Pinker distinguishes between Shakespeare: the historical figure, and Shakespeare: the author of numerous plays like Hamlet attributed to Shakespeare.
In my earlier post, it was somewhat easy to see that there were multiple aspects to Superman because each aspect already had its own name; Superman vs Clark Kent. With Shakespeare however, it is much more subtle because the different aspects have the same name: Shakespeare. Additionally, we are not used to thinking that they are different aspects that can be independent of each other, any more than we think of Cher-the-person and Cher-the-singer as being independent things. But, as discussed in the book, many people over the centuries have debated whether the author of Hamlet, et al was really Francis Bacon, Christopher Marlowe, Queen Elizabeth, etc.
The interesting thing is that because Shakespeare is SO ingrained as the name of the playwright that even if Sir Francis were to be proven the author, the headline will be "Bacon is the REAL Shakespeare!" which is absurd because clearly, Shakespeare-the-historical-figure is the "real" Shakespeare. Changing the human associated with the author-of-Hamlet concept will not change the concept's name; it will remain "Shakespeare's Hamlet (written by Bacon)" and not "Bacon's Hamlet".
So, when assigning ID#(s) to putatively single entities, flexibility should be built in to allow ad-hoc collections of attributes of any entity to be grouped and named and referenced separately. Otherwise, the system would not be able to represent the statement: Shakespeare is not Shakespeare, Bacon is.
In the imposing, but handy, Oxford Companion to Philosophy[1], there are entries about "objectivism and subjectivism"[2], and "relativism, epistemological"[3] that lead to the following observations:
Objectivism says that some statements are objective, in that they are true independent of anyone's opinion. e.g. This ball is red.Alternatively, values assigned to properties can be dependent on other factors and be described by a function rather than a simple value.e.g. The color of Ayer's Rock is F(time-of-day, weather).
Subjectivism says that (potentially all) statements are subjective, in that they are dependent on the opinion of the person making the statement. e.g. This cake is delicious.
Relativism says that statements are always subjective even when the decider thinks he's made an objective evaluation. I.E. no evaluations are objective because man is always biased by his particular cultural, historical, religious, etc viewpoint, and no particular viewpoint is "the right one". e.g. This society is primitive.
Existential Programming philosophy says that even if something is supposedly scalar & objective, and even if one does not subscribe to relativism (thus implying that there is no need to ascribe to values a particular data source), the reliability of any particular data source is never perfect, and thus one needs to model data as if relativism were true. I.E. keep track of "says who" for each "fact" and therefore be prepared to simultaneously handle/store multiple values for everything, tagging them with "says who", "said when", etc. So, in effect, there are no scalar values, only functions with at least a data source as a parameter.
"Philosophical Programming" is a style of computer software development that explicitly seeks inspiration for new techniques from Western Philosophy (with a capital P). - Bruce Wallace, 2006
As Principal Consultant of PolyGlot Inc since 1980, Bruce Wallace has provided computer software development, consulting, and contract programming services around the world. Projects have been completed in San Francisco, Juan-les-Pins France, Sydney Australia, Perth West Australia, "Silicon Valley" CA, "Route 128" MA, Austin TX, Charlotte NC, Atlanta GA.
, where I was surprised to learn that there is no accepted universal definition of a biological species; there are at least 20+ competing definitions. I had thought that "being able to breed fertile offspring" was the definition, but that is only one (and of course it leaves out the vast majority of living things on earth that reproduce asexually).
”[1], there is a collection of example 
, 
, and 
, right through to the 21st century, have been debating this question, generating whole libraries of book and papers. In fact, 
[2], there is a whole spectrum of things in between “individuals” and “groups”, and they are referred to in everyday language by singular terms (e.g. person), plural terms (e.g. feet), and some words that could mean either (e.g. hair). There are individuals (say, a car), parts of individuals that are themselves individuals (say, a wheel), parts of individuals that are NOT themselves individuals (say, the paint), collections that do not form an individual (say, “the wheels of that car”), collections that DO constitute an individual (say, the car parts that comprise the engine where the engine is itself an individual), and so on, and so on.
by Steven Pinker, the problem of what-a-name-names, is explored with the example of Shakespeare. Pinker distinguishes between Shakespeare: the historical figure, and Shakespeare: the author of numerous plays like Hamlet 
Posts
