Existential Programming

Not All Properties Are Created Equal (Part I: Essentials)

2010-08-10T17:35:00.009-04:00

Just a few years ago, I started reading “Philosophy 101” type books and I was immediately surprised at how relevant the ideas were to day to day software development. So relevant, in fact, that an even bigger surprise is that these ideas are not part of the basic computer science curriculum, nor mentioned in technical books & magazines (with the possible exception of graduate level artificial intelligence). The following idea was the first I encountered that made it clear to me that programmers need to know what philosophers already know. It was also my first clue that philosophy has a whole body of knowledge about developing data & object models that computer science books leave up to intuition.

Did you know that 2500 years ago, philosophers like Plato and Aristotle were doing Object-Oriented Analysis and Entity-Relationship Modeling? More surprisingly, they were already more sophisticated than software developers are now! Why? Well, for one thing, they already understood that the properties of an object are not all created equal. Whereas programmers today basically think that a property is a property, even ancient philosophers understood that there are several different categories of properties. And most importantly, only some properties define WHAT something is; the other properties merely describe HOW it is. Embracing this distinction will change the way you carve up the world into classes and relationships, and which attributes you assign to which entities. I have come to feel that creating data models without this distinction is like wearing glasses so out of focus that distinct objects blur together into indistinguishable blobs.

The properties that something must have, in order to be what it is, Philosophy calls Essential properties. Those properties that something may optionally have are called Accidental properties. For example, for you to be a human, you must have human DNA; it is an Essential property. Being named Smith, however, is an Accidental property because you would still be human even if you had a different name or even no name. So, our everyday meaning for “essential” is different than the philosophical meaning. If a client says that the address is an essential part of the customer data, that doesn’t mean that it is Essential in the philosophical sense. In fact, it is not Essential because whatever a “customer” is, it will still be that same kind of thing even if its address changes. The distinction between essential and accidental properties is even embedded into some human languages like Irish where there are two different “is” verbs; “Tá” is used for accidentals like “He is hungry”, but the verb they call The Copula is used for essentials like “He is Hungarian”.

A hallmark of Essential properties is that they are unchanging. An object’s Essential properties can not change without that object becoming a different kind of thing. There is an ancient philosophical paradox of how something can change and yet remain the same. You are different than you were as a child, and yet you are still the same you. As Heraclitus said, "You can’t step into the same river twice because the water is always different." The solution the Greeks came up with was that Accidental properties may change but Essential properties must remain the same (otherwise, a metamorphosis has occurred!). This philosophy is known as Essentialism.

Socrates taught that everything has an “essential nature” that makes it the kind of thing that it is. His pupil, Plato, taught that these essences are manifest in ideal “Forms” of which all objects are mere copies. Plato’s pupil, Aristotle, taught that Essential properties were those that defined a Form, and Accidental properties were those which distinguished one individual object from another of the same kind. Our object-oriented programming notion of Class is analogous to Plato’s Forms. Like a Class, a Form is unchanging and it pre-exists any objects which instantiate it. Naturally, Entity tables are the database equivalent of Forms with their records being the objects.

So, what is using this idea supposed to buy me? I think a case can be made for at least the following:

Better definitions of entities, classes, and relationships result because it forces you to weed out all the non-essentials (pun intended). By striving to understand entity essentials, and not just normalizing data tuples, you will be more likely to accurately model the world.
Better specifications result because there will now be a place to put all those unwritten (even unspoken) assumptions about the nature of the problem domain. Ironically, when gathering requirements and doing analysis, the essential properties of things are often given short shrift because they mostly don't get stored in databases, because.…that's right, they don't change! It is the changeable accidental properties that get stored, with the unchanging essential properties getting buried as hardwired assumptions in the programming logic.
Better system interoperability results because universal essential data is separated from local accidental data. The integration of data between a customer system and a patient system and an employee system would be much easier if they had modeled the essential entity, which is Person. When customer and patient and employee are recognized as merely accidental roles of a Person, there is an immediate common entity type to synchronize on rather than widely divergent data tables.
Better identity systems result because life-long identifiers will no longer be confused with changeable properties like names, addresses, and phone numbers.

Examples of using Essentialism

Imagine a Person table where we already understand that using the Name column as the primary key is a bad idea, simply because names are not unique. Some are tempted to create a compound key using name plus some other column(s) like address, phone, etc. With an Essentialism perspective it is clear that, while the compound key may be unique for the moment, it is composed of accidental properties and hence can change at any time! Stored references to previous keys will fail. Current keys won’t match future keys.  

We want keys using essential attributes that remains fixed for the life-time of the Person. A unique, fixed, objective, essential attribute like the person’s complete DNA sequence would do the trick! However, a government issued tax ID like SSN can be a practical substitute, plus it’s better than a proprietary “customer ID” because it is something that is effectively universal, and therefore can be used to integrate databases from multiple sources.

Lest you think this example is contrived, I witnessed a Top-5-in-the-USA bank design a customer identity system using a key composed of accidental properties rather than SSN because “we have not traditionally collected SSNs” (despite government “know your customer” security laws requiring it!) They had to continually fix their ever-changing data because they only focused on having a “unique key”.
In tutorials for any technology that uses entities, the example of a “customer” entity is almost cliche. The design of databases, XML schemas, UML diagrams, SOAP messages, Java Classes, etc, etc, have all used it. But when we ponder the essential nature of a “customer”, there is an immediate problem…  

Philosophers have devised many systems for organizing “what exists”, and one of the first of their “20 questions” is: Is its essence physical or abstract? Customers can either be a person (a physical thing that exists in time and space), or a corporation (an abstract thing that doesn't exist in space), so, which is it? This is our clue that it isn’t an entity at all. With some thought (and benefit of reading more philosophy), it becomes clear that “customer” is really just a role that different entities can play. It is part of the relationship between that entity acting as customer, client, buyer and that entity acting as vendor, seller, provider.

Whatever interpretation you would give about the essential-ness of this or that property, the main point is that it is worth knowing that there IS a distinction. And more generally, Philosophy has some ideas to which we programmers need to be exposed.

Neural Nets, Vagueness, and Mob Behavior

2010-08-08T18:57:00.031-04:00

In response to the following question on a philosophy discussion board, I replied with the short essay below and reproduce it here.

"It was then that it became apparent to me that these dilemmas – and indeed, many others – are manifestations of a more general problem that affects certain kinds of decision-making. They are all instances of the so-called ‘Sorites’ problem, or ‘the problem of the heap’. The problem is this: if you have a heap of pebbles, and you start removing pebbles one at a time, exactly at what point does the heap cease to be a heap?"

VAGUE CONCEPTS
This leads to the entire philosophy of "vagueness". i.e. are there yes/no questions that don't have a yes/no answer? Are some things like baldness vague in essence, or, is our knowledge merely incomplete? e.g. we don't know the exact number of hairs on your head, and/or, we don't know/agree on the exact number of hairs that constitutes the "bald" / "not bald" boundary?

NEURAL NETS
My personal conclusion is that there ARE many vague concepts that we have created that are tied to the way our brains learn patterns (and, as a side effect, how we put things into categories). In contrast to rational thought (i.e. being able to demonstrate logically step by step our conclusions), we "perceive" (ala Locke/Hume/Kant) many things without being able to really explain how we did it.

In Artificial Intelligence, there are "neural network" computer programs that simulate this brain-neuron style of learning. They are the programs that learn how to recognize all different variations of a hand-written letter "A" for example. They do not accumulate a list of shapes that are definitely (or are definitely not) an "A", but rather develop a "feel" for "A"-ness with very vague boundaries. They (like our brains) grade a letter as being more or less A-like. It turns out that this technique works much better than attempting to make rational true/false rules to decide. This is the situation that motivates "fuzzy logic" where instead of just true or false answers (encoded as 1 or 0), one can have any number in-between, e.g. 0.38742 (i.e. 38.7% likely to be true).

WISDOM OF THE CROWD?
Because each person has their own individually-trained "neural net" for a particular perception (e.g. baldness, redness, how many beans are in that jar?), we each come up with a different answer when asked about it. However, the answers do cluster (in a bell-curve-like fashion) around the correct answer for things like "how many beans". This is what led Galton to originally think that there was "wisdom in the crowd". This idea has been hailed as one of the inspirations for the new World Wide Web (aka Web 2.0). The old idea was that McDonalds should ask you if "you want fries with that?" to spur sales. The new Web 2.0 idea is that Amazon should ask you if you want this OTHER book based on what other people bought when they bought the book you are about to buy. I.E. the crowd of Amazon customers know what to ask you better than Amazon itself.

The problem is that there are many failures of "crowd wisdom" (as mentioned in that Wikipedia page in the link above). My conclusion is that most people advocating crowd wisdom have not realized that it is limited to "perceptions". Many Web 2.0 sites are asking the crowd instead about rational judgments, expecting them to come up with a better answer than individuals. The idea of democracy (i.e. giving you the right to vote) has been confused with voting guaranteeing the best answer, no matter the question. In fact, Kierkegaard wrote "Against The Crowd" almost 200 years ago where he recognized that individuals act like witnesses to an event, whereas people speaking to (or as a part of) a crowd, speak what we would now call "bullshit" because they are self-consciously part of a crowd. We can see this in the different results of an election primary (a collection of individuals in private voting booths) versus Caucuses where people vote in front of each other.So, Web 2.0 sites (Facebook, MySpace, blog Tag Clouds, etc) that allow people to see the effect on other people of what they are saying, are chronicling mob mentality rather than collecting reliable witness reports.

BTW, I have written several blog posts related to vagueness, for example:
http://existentialprogramming.blogspot.com/2010/03/model-entities-not-just-their-parts.html

POSTSCRIPT - May 16th, 2011
There is a new study that shows science catching up with 150+ year old philosophy with regard to the (lack of) wisdom of the crowd. Kierkegaard's observation about people (who are consciously a part of a crowd) acting differently than individuals has been verified in new studies reported here in Wired Magazine.

foo

Fuzzy Unit Testing, Performance Unit Testing

2010-06-06T15:27:00.035-04:00

Because of the topic of testing coming up in my recent post "Is Morality Eating Your Own Dogfood?", it made me finally publish the following notebook entry from 2007...

In reading Philosophy 101, about Truth with a capital "T", and the non-traditional logics that use new notions of truth, we of course arrive at Fuzzy Logic with its departure from simple binary true/false values, and embrace of an arbitrarily wide range of values in between.

Contemplating this gave me a small AHA moment: Unit Testing is an area where there is an implicit assumption that "Test Passes" has either a true or false value. How about Fuzzy Unit Testing where there is some numeric value in the 0...1 range which reports a degree of pass/fail-ness? i.e. a percentage pass/fail for each test. For example, testing algorithms that predict something could be given a percentage pass/fail based on how well the prediction matched the actual value. Stock market predictions, bank customer credit default prediction, etc come to mind. This sort of testing of predictions about future defaults (i.e. credit grades) is just the sort of thing that the BASEL II accords are forcing banks to start doing.

Another great idea (if I do say so myself) that I had a few years ago was the notion that there is extra meta-data that could/should be gathered as a part of running unit test suites; specifically, the performance characteristics of each test run. The fact that a test still passes, but is 10 times slower than the previous test run, is a very important piece of information that we don't usually get. Archiving and reporting on this meta-data about each test run can give very interesting metrics on how the code changes are improving/degrading performance on various application features/behavior over time. I can now see that this comparative performance data would be a form of fuzzy testing.

POSTSCRIPT - July 6th, 2010

I have recently come across several types of meta-data that APPLE should have been tracking during their testing.
1) CPU Temperature
2) Battery Drainage Rate
3) Antenna Receiver Strength
I have just had to deal with iMac and iPod and iPhone issues with each of those respectively. Software updates caused new behavior overheating old iMacs, draining iPod batteries, and everyone now knows about the iPhone antenna issues. Had APPLE used the proposed techniques above, they would have caught these problems.

POSTSCRIPT - Aug 11th, 2010
While Apple has not addressed the CPU overheating in older Macs, they have had to replace overheating iPods (in Japan) See http://news.yahoo.com/s/nm/20100811/tc_nm/us_japan_apple

POSTSCRIPT - Sep 21st, 2010

It wasn't obvious to me how a change in software could have such a dramatic effect on temperature until I started seeing all the hoopla about new browsers being faster because they have been rewritten to take advantage of GPU (graphic processing unit) processing power instead of just CPU circuitry. The GPU would be a major piece of chip real estate to change from cold and idle to hot and bothered. As described here in SD Times, Apple's new O/S is one of the riders on this bandwagon, which would explain the overheating of old Macs and iPods.

A hole for every component, and every component in its hole

2010-05-19T16:16:00.004-04:00

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.

Is Morality Eating Your Own Dogfood?

2010-05-16T17:26:00.005-04:00

There are two schools of thought about whether programmers should have to write tests to verify their own code (in addition to writing the code itself). The philosophy of economics, and psychology, and morality, all overlap in studies that show how people will readily abandon moral responsibilities if they are given ways to avoid the stigma of doing so. This leads me to feel more justified in my belief that programmers do a poorer job of reading, understanding, and implementing a specification when someone else has the responsibility of verification.

Changing the rules changes people’s attitudes

There is a 1998 experiment[1] that keeps popping up in the new “freakonomics”-type literature[2][3] (e.g. Economics 2.0 [4]), where a controlled subset of Israeli day-care centers started charging a fine for parents who came late to pick up their children. To everyone’s surprise, the number of people showing up late almost doubled. Additionally, when the fine was later dropped, the number of late parents stayed at the high level. It is theorized that the moral responsibility parents felt to be on time was much stronger than the economic cost of paying a fine, which was rationalized by the parents as a fee, thus removing the stigma of being late. The fee made it “just business”. As Professor Michael Sandel summarized[5]…

“So what happened? Introducing the fine changed the norms. Before, parents who came late felt guilty; they were imposing an inconvenience on the teachers. Now parents considered a late arrival a service for which they were willing to pay. Rather than imposing on the teacher, they were simply paying her to stay longer. Part of the problem here is that the parents treated the fine as a fee. It’s worth pondering the distinction. Fines register moral disapproval, whereas fees are simply prices that imply no moral judgement.”

Don’t make “not my job” “just business”

The blind experiment is a well established doctrine in science requiring that people should not know too much about something they are testing, otherwise the results are often biased. Scientists gathering their own raw data (not to mention interpreting their own data) often get the results they expected to get, where objective outsiders don’t. With that theory, it is argued that software development projects should engage external, objective, “QA testers” to develop and administer test suites against the code produced by the “programmers”. Since many programmers don’t like to eat their spinach, ahem, write their own tests (or documentation for that matter), there are not usually arguments against the idea.

From my experience though…

Programmers will suffer peer pressure and social costs if they fail their own tests (which is a good thing).
Programmers who understand that they are obligated to deliver testable components, will do so more often if they must actually produce the tests themselves, compared to those where testing is “not my job”.
The act of writing a test forces a clearer understanding of both the interface and the implementation of the tested component compared to just programming it.
Programmers who fail their own tests will be much more likely to change that component’s implementation if needed, rather than obstinately maintaining that the externally-produced test is wrong.
Writing your own tests is the most systematic method of “eating your own dogfood”

Belt and Suspenders

I say, both independent testers AND the original programmers should each write independent test suites. This way you get the power of both perspectives. This is an old lesson from the days of computer punch-cards; two different people key-punch the same data so that they can later be compared, thus eliminating most typos.

[1] A Fine is a Price, URI GNEEZY and ALDO RUSTICHINI, Journal of Legal Studies, vol. XXIX ( January 2000)
http://rady.ucsd.edu/faculty/directory/gneezy/docs/fine.pdf

[2] Brain food: when does a fine become a fee?, Aditya Chakrabortty, The Guardian, Tuesday 23 February 2010
http://www.guardian.co.uk/science/2010/feb/23/brain-food-fines-and-fees

[3] Why an L.A. Times wikitorial effort went wrong, Clay Shirky, O'Reilly Media Gov 2.0 Summit, 2009-09-09
http://itc.conversationsnetwork.org/shows/detail4411.html

[4] pg 7, Economics 2.0, Norbert Haring, Olaf Storbeck, Palgrave Macmillan, 2009

[5] Michael Sandel, The Reith Lectures 2009, BBC, 9th JUNE 2009
http://www.bbc.co.uk/programmes/b00kt7rg

The purpose of a thing is in US as well as in IT

2010-05-11T17:54:00.013-04:00

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.

POSTSCRIPT - July 4th, 2011
Once again, I see that I've come to a brilliant insight that someone else did a long time ago. In the new "The Philosophy Book", I just found the following apropos quote: "Every way of classifying a thing is but a way of handling it for some particular purpose"- William James.

Class Constructors considered harmful

2010-04-21T17:24:00.003-04:00

PREFACE: There is a school of thought in computer programming that Classes are harmful in certain ways, but the basis for those arguments are very programming-technique specific. This essay is about a much more general, mind-set oriented, objection.

CASE STUDY: At a recently defunct Top-5 bank, I uncovered the fact that there were major incompatibilities in data being used to produce credit scores for borrowers and their loans. The scores depended on a grade generated for a "facility". The problem was that the very concept and definition of "facility" was not the same in various parts of the bank. If they had answered the following simple questions, they would have realized that they were not talking about the same thing: When and why does a new facility come into existence, and when/why does it cease to exist.

In the course of analysis and requirements gathering, a major goal is to identify and define the various business domain entities. But, in a vicious cycle, the definition of an entity is often too shallow with regard to its birth and death because “causal” information often stagnates as merely background text in some requirements document. This is because programmers have no standard place to put that logic into the code.

Object oriented practice has one put "all" the properties and behavior associated with an entity into its Class definition, where "all" for class Dog means "the dog, the whole dog, and nothing but the dog"[1]. However the "nothing but the dog" constraint means that, the logic involved in deciding whether an instance of class X should be created, is not normally a method of class X. Since the "cause" of X's instantiation usually involves other classes, that logic lies outside of X proper, thus, standard development methodologies leave the analysis of causation and purpose out of the design of class X. Even Factory classes are focused on object construction, rather than why it should be constructed, and why now, and by whom.

The Mediation pattern comes to mind as a place to put this sort of logic because it involves multiple classes. The logic that decides it is time for a Sculptor to use a Chisel to carve a Statue out of a block of Marble doesn’t belong solely in any of those classes. A programmer would be tempted to put a “carve” method in Sculptor since that is a “behavior” of the sculptor, but Philosophy considers it an essential part of the definition of the statue itself. And that is a problem with Mediator classes in the first place; the desire to have everything relevant to X be “nearby in the source code” (a raison d'être for classes) is defeated when some of it is off in various Mediators. Having the teleology of Statue off in some CarveMediator isn’t much better than it residing in Sculptor.carve().

With event-driven systems (e.g. MOM, SOA), the series of events that trigger the creation of an entity instance may be complex. And whether event-driven, or "batch processing", the sub-systems are often distributed, increasing the value of encapsulating this logic in a single place. With Java EE and service oriented designs, there would be value in having the entity services include this logic.

In any event, I believe that there is a need to learn from Philosophy that their concept of "form" (which is the equivalent of OOP's class) has always included the purpose of a thing as well as its blueprint.

[1] Object Oriented Analysis and Design, Grady Booch, 1991

&lt;p&gt;&amp;amp;amp;amp;lt;p&amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;lt;p&amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;br&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;amp;amp;amp;amp;gt;&amp;amp;amp;amp;lt;/p&amp;amp;amp;amp;gt;&lt;/p&gt;

Silver Bullet: Model the world, not the app

2010-04-19T14:50:00.001-04:00

DISCLAIMER: Ok, I admit it...this is cut/pasted directly from my brain fart notebook, i.e. not ready for prime time...but dammit Jim, its just a blog!

In the arsenal needed to fight unsuccessful software development projects, it will take a whole clip full of silver bullets. One of those silver bullets, I believe, is more accurately modeling the world using knowledge of Philosophy.

There is a great struggle between getting everything "right" up front, versus, doing "just enough" specification and design. When trying to balance "make it flexible" in order to support future re-use, versus XP mandates like "don't design what isn't needed today", it is hard to know (or justify) where to draw the line. Due to "changing requirements", those "flexible reuse" features (that were merely contingent at design time) are often mandatory before the original development cycle is even complete.

WELL, lots of requirements don't change THAT much if you are modeling correctly in the first place.

Humans haven't changed appreciably in millennia, even if the roles they play do. So, if "humans" are modeled separately from "employees", it is that much less work when you later need to integrate them with "customers". [Theme here is "promote roles programming", the justification of which is made more obvious when taking essentialism to heart.]

In general, the foundation of one's data/domain/business/object/entity-relationship model is solid and unchanging, if all "domain objects", "business objects", etc are modeled based on a clear understanding of the essential versus accidental aspects of the "real world", and NOT based on the requirements description of a particular computer system or application. Modeling based on "just what is needed now according to this requirements document today" is too brittle, both for future changes, and especially for integrating with other systems and data models.

After all, adding properties and relationships to entities is fairly easy if the entities themselves are correctly identified. It is much harder to change the basic palette of entities once a system design is built upon them. Also, all the more reason to be sure and not confuse entities with roles they can take on.

Example: I don't have to wonder who I might have to share employee data with if I realize that an "employee" is actually just a role that a person takes on. If I model the essentials of the person separately from the attributes of the employee role, it will be much easier to integrate that data with, say, a "customer" database later. If the customer data model recognizes that "customer" is just a role that a person takes on, its Person table is much more likely to be compatible with my Person table than would be the case with my naive Customer and their Employee tables (and still other Patient tables, etc, etc.)

Do Objects Have Souls?

2010-04-13T18:08:00.005-04:00

While writing the article, Implementing "Real" Classes in JavaScript for Developer.com, I was tempted to add a sidebar with the provocative title "Do Objects Have Souls?". The article itself demonstrated a technique for simulating Java-like classes in JavaScript, and as introductory material, it explained the difference between Java's "class"-based semantics versus JavaScript's "object prototype"-based semantics.

For Java programmers: In a nutshell, Java creates object instances that have all, and only, the properties of its Class, and the property list is fixed over the life of the object. In JavaScript, object instances have no "real" class, however, each object is free to add and delete properties at any time. Because of this, JavaScript Object objects are pretty empty compared to Java Object objects at birth because they can become anything after they have already been instantiated [hence Existential Programming!].

In trying to understand the language differences myself, I began musing on the parallels between philosophical notions of "the soul" and JavaScript's empty shell of an "object" that is generated by obj = new Object;

Souls as property containers

In western philosophy there has been a 2500 year old school of thought that "things" (aka objects) have properties, some of which can never change (i.e. essential properties) versus those which may change over time (i.e. accidental properties). One concept of "soul" is that it is the bundle of essential properties that constitute a thing. This idea has also been equated with "identity". Attached (non-permanently) to the attribute bundle are the various accidental properties. This sounds a lot like the "empty" JavaScript object which is ready to add and update and delete [accidental] properties, while all the time keeping constant the essential, unchanging, object identity (as referenced by obj !).

When medieval alchemists distilled liquids into their essences they called them spirits because they were the "soul" of the grape, herb, flower, etc. To insure removing all of the accidental properties, they distilled things 5 times to produce the quintessential spirit. Distilled spirits in the alcohol sense often have names that reflect the notion that they have a life essence captured in them. Whiskey and Aquavit are both names that translate into "water of life" in their original languages. In the movie Perfume, a villain repeatedly attempts to distill the essence of pretty women using the same techniques as distilling flowers into perfume. [Spoiler Alert: flowers don't survive the process...]

When the Well of Souls runs out of RAM

Another aspect of souls that rhymes with JavaScript is the ancient lore that newborns are given a soul at birth which is plucked from a "well of souls" (aka the chamber of Guf). In JavaScript, as empty objects are created and given an identity, they are plucked from a heap of available memory (i.e. dynamic memory allocation). In both cases, bad things happen when there are none left.

When the well of souls runs dry, the Messiah will come and reboot the world; when your browser runs out of heap space, your JavaScript will gag and someone will have to come and reboot the browser (or at least the web page). The plot of the 1988 Demi Moore film, The Seventh Sign, is based on the Guf mythology. Demi's baby is due to be born on February 29 which is the date on which the last soul will leave the Guf and it will be empty.

Moore's Paradox... I'm just saying!

2010-03-30T17:48:00.007-04:00

The popular phrase "I'm just saying" has been around long enough for most people to have heard it, but not long enough for it to be well-documented as to where it originated. I heard a great stand up comic bit about it in the 1980's by Paul Reiser. There are several blog sites that muse over its origin and solicit theories:

It turns out that the most common definition of the phrase exhibits a logical paradox from Philosophy. The book "this sentence is false" is a collection of philosophical paradoxes, and it describes Moore's Paradox (as developed by G.E. Moore). I summarize it as follows:

Normally, everything that can be said about the world can be said by anyone. I can say the moon is made of green cheese, and you can say it. The state of the world described by me can equally be described by you with no logical paradox...EXCEPT... I can say that the moon is made of green cheese, and I can say that you do not believe that the moon is made of green cheese, but YOU can not say the same thing. I.E. you can not say that X is true and at the same time say that you do not believe that X is true. Note that you are not saying that you could be wrong in your belief, you are saying that you both, believe X is true, and X is not true, at the same time. A logical contradiction.

However, whenever you use the phrase "I'm just saying!", you are in effect performing Moore's paradox.

Don't Call Names...It IS polite to point!

2010-03-22T19:40:00.390-04:00

Mom always said "Don't call names!" and "It's not polite to point!". Ok, so how am I supposed to refer to "you know who" over there? Too late! I already "pointed" verbally when I said "over there". But, not only is that ok for programmers, it is actually preferable to point rather than to use names. And a half-century before computers even existed, Philosophers already knew this. So why are programmers still calling names?

A bit of background first for programmers...
The philosophical use of the word "reference" (and hence "refer") has a subtle technical meaning that, luckily for us, corresponds with the object-oriented technical term "reference". In Philosophy, the only way words can say something about the real world is via "reference". In Java programs, the only way to say something about an object is via an "object reference". In other programming languages it is via a "pointer". Interestingly, according to the 20th century philosopher Bertrand Russell, the only way one can truly refer to a thing (using language) is via a "demonstrative" (i.e. pointer words like "this", "that", "those", "these").

Contrary to previous thinkers, Russell held that proper names (e.g. Joe Blow) do not "refer". OOP programmers can relate to this because a reference (or pointer) to a Person object can access that object's properties, but the string "Joe Blow" can not...

Person p = new Person("Joe Blow"); // get an object reference "p"
p.weight = 175; // THIS WORKS!
"Joe Blow".weight = 175; // THIS DOESN'T WORK!

Now, the string/name "Joe Blow" could be used in a query that describes a Person object and returns a reference to it. And WAAAY before computers, Russell said the same thing. Names are a description of something and not a reference to it.

(Descriptivist) Philosophers declared that names were not references because there are a number of problems in logic that arise if they are. I have written about several of these in earlier blog posts, but in a nutshell:

names can change even though the object doesn't (e.g. maiden names)
names can have meaning over and above referencing an object (e.g. Superman vs Clark Kent)
objects can have more than one name (e.g. Morning Star vs Venus)
names can be given to objects that don't actually exist (e.g. Unicorn)
not every object has a name (e.g. that piece of paper over there)

While OOP programmers may know that a pointer or reference to an object is different than a "name", many database designers haven't absorbed that yet. Of course, they can be forgiven somewhat because the relational database model does not really give them references or pointers. The only way to access the properties of an object (aka entity) is via a query (and hence a description). This has led to the common practice of creating an artificial property (aka surrogate key) that can be made to have a unique, unchanging value for every different object/entity, and is a close substitute for a "reference".

On the other hand, there is also the practice of using the name property of an object (or any other real world properties) as a reference mechanism (aka natural key), and so naturally there is great debate about whether this is ok or not, and when to use one or the other.

Philosophy would counsel (as would I) to not call names (i.e. don't use natural keys), and don't use artificial keys that the world knows about (like Social Security Numbers because even those have duplicates!). Below are a few case studies of problems arising from name calling rather than pointing. They share a base problem that the natural key data is almost never "essential" in the philosophical sense; i.e. the data is capable of changing over time even though the object is considered to be the same object.

Case Study: Yahoo Bookmarks

It turns out that once a bookmark is created on the Yahoo Bookmarks site, there is no way to change the URL associated with that bookmark. Someone decided to use the URL as a natural key (which by definition should never change), so, the URL can't be edited. The problem is that a "bookmark" (by my thinking) is not synonymous with a URL. It is a marker that enables me to return to a web page. With web sites being revamped all the time, and most URLs not being "permalinks", the same page can have it's URL change over time. If I need to update the URL, Yahoo makes me delete the old bookmark, create a new one, and re-enter the name, comments, etc from scratch.

Case Study: Qlubb site names

There is a web portal where one can create free web sites for small organizations (i.e. clubs aka qlubbs). To create a site, you select a club name and then customize the generic site created for you. However, in the help page, they warn that there is no way to change the name of your club once it is created because

"We currently do not support the ability to change the Qlubb name as there may be database consistency risks. However, if your Qlubb really want to change the name, please have a Qlubb administrator send a note to help at Qlubb with your request. We will evaluate each request and perform the change manually, if it is safe to do so."

Obviously someone mistook a name for a unique and unchanging key.

Case Study: Semantic Web

For all those programmers groaning at the last example, asking how anyone can still make that old mistake in this day and age, the same thing goes on in the new frontier of the Semantic Web. In most tutorials on the Semantic Web, or tutorials for logic programming languages like Prolog, and yes, even in my youthful whack at a semantic network database, names of things are confused with references to those things. As I wrote about the flaw in my SN database back in 2007, this causes real problems in all the ways that Philosophers recognized a century ago.

Some Parts have a (sex) life of their own

2010-03-11T17:30:00.027-05:00

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.

<iframe src="http://rcm.amazon.com/e/cm?t=existenprogra-20&o=1&p=8&l=bpl&asins=0582832489&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="padding-top: 5px; width: 131px; height: 245px; padding-right: 10px;" marginwidth="0" marginheight="0" align="left" frameborder="0" scrolling="no"><iframe src="http://rcm.amazon.com/e/cm?t=existenprogra-20&o=1&p=8&l=bpl&asins=0582832489&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="padding-top: 5px; width: 131px; height: 245px; padding-right: 10px;" marginwidth="0" marginheight="0" align="left" frameborder="0" scrolling="no">

Model Entities, not just their parts

2010-03-04T13:32:00.019-05:00

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 in Leibniz’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

POSTSCRIPT - April 19th, 2010

I almost said that a person's DNA was unique until I remembered twins, triplets,etc. So, I started to add a reference to DNA+epigenetics in order to be able to say "unique", except that the "never changes" bit would no longer be true.

Interesting "paradox" that epigenetics is needed to uniquely define/identify someone but it is ever-changing. This gets at the heart of the notion of essential versus accidental...it is unique to something but not essential to that same something.

Counting Intentional Non-events

2009-09-16T21:44:00.015-04:00

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.

[1] Jennifer Hornsby, Agency and Actions, Cambridge Univ Press, 2004
http://eprints.bbk.ac.uk/95/

[2] Jennifer Hornsby, Actions (International Library of Philosophy), Routledge, 1980

Why did the Action Philosopher cross the road?

2009-09-15T18:06:00.024-04:00

“Why” is such an ambiguous question; it asks about an event…

what were the “causes” (i.e. the physical producers of effects)
 what were the “actions” (i.e. who did what) 
what were the “reasons” (i.e. thoughts, motivations by someone that led to their (in)actions).

And to make things worse, each of those categories of questions can be answered at many different levels of abstraction. “Why did Y die?” could be answered with:

causes: “Y’s car crashed” or more specifically “Y’s brakes failed”
actions: “X sabotaged Y’s car” or more specifically “X cut the brake line”
reasons: “X wanted revenge” or more specifically “X wanted Y dead”.

And still worse, each of those categories exist in a chain such that each answer to “why” produces a new “why” question. Each cause has its own cause, actions occur in ordered sequences, and reasons are triggered by previous events. So, “why did X want revenge?” because “Y intentionally ruined X’s wedding”, “well WHY did Y do that?”, and so on. “What is happening” is an equally ambiguous question because it can also be answered in terms of causes or actions or reasons.

The Chicken crossing the road joke is so old, with so many new punch lines, that people sometimes don’t get the original joke anymore. It, of course, is that the answer “to get to the other side” is too much of a HOW rather than a WHAT (i.e. confusing proximate and ultimate goals). In the Philosophy of Action, which seeks to differentiate things done on purpose from things that merely happen, many philosophers have difficulty in separating what a person is doing from how they are going about doing it (not to mention, where their concept of “intention” fits in). Distinguishing what from how is so central to writing specifications, programs & documentation, that we Programmers should have something useful to pass along to Philosophers. I would teach them about our knowledge of: levels of abstraction, the difference between top-down and bottom-up views of the world, and the difference between the “intention” of the logic versus an instruction trace. Not that programmer’s have no problems in this regard…

Top Down: Good Grief! Why don’t you move this code out into subroutines? There are fifty pages of code in one switch statement here! I can’t see the forest for the trees. 
Bottom Up: Good Grief! How can I tell what the program is doing when it is ten levels deep in function calls!
Top Down: At the very least, put some comments in here to say what the program is doing. 
Bottom Up: I don’t believe in comments because the source code tells you exactly what the program is doing. 
Top Down: Ok, so what does this part of your program do?
 Bottom Up: Well, “i” is set to zero, and then it gets incremented each time through this loop here, and… 
Top Down: No, really. Put comments in English telling what the program was supposed to be doing. 
Bottom Up: Ok…. ++i; /* Increment i */

Events & Causes vs Actions & Reasons

“What is left over if I subtract the fact that my arm goes up from the fact that I raise my arm?" - Ludwig Wittgenstein, Philosophical Investigations §621

Human Agency, Intention, Actions, and Events are topics in Philosophy of Action and Philosophy of Mind. Events are simply “things that happen”[2] in a chain of causes and effects. Agency is a philosophical term for what programmers call “a thread of control”. Human Agency is the capacity of human beings to make choices and act upon them. In Action Theory, if an AGENT A has the DESIRE for X plus the BELIEF that doing Y will result in X, then A will have the INTENTION of doing the ACTION Y. If A actually does Y, then that desire and belief should be considered CAUSES of the EVENT of Y happening (…or not: “There has been a notable or notorious debate about whether the agent's reasons in acting are causes of the action”[3]). Unless specifically noted as unintentional, actions are only those that an agent does intentionally, so falling off a cliff would not be an “action” but jumping off would. Actions usually involve “bodily movements” that effectively translate mental intentions into physical events. (“Actions are bodily movements that are caused and rationalized by an agent’s desire for an end and a belief that moving her body in the relevant way will bring that end about.”[5]) Further, there is a certain moral component to human (in)actions that doesn’t apply otherwise. One can ask “should this have happened” about human actions (say, not pre-evacuating New Orleans), which would make no sense for events & actions that involve no human decisions (e.g. Katrina hits New Orleans, or, the spider killed the fly). Finally, in the Identity Theory of Mind[4], it is held that mental states, processes, and events (like desiring to eat ice cream) are mirrored by brain states, processes, and physical or physiological events (like this and that neuron firing).

Background: philosophers/metaphysicians are interested in figuring out what is “really real” versus just a story our mind made up in trying to interpret all those real-world inputs we get from our senses. They have decided that a way to prove that a thing is “real” is to show that it can affect an event happening or not: “a test of the reality of a property is that it can be causally efficacious”[6]. So, that is why there is so much interest in the relationship between actions/reasons/intentions and the scientifically measurable physical events/causes. If one can’t show how the intention to perform the action of eating an ice cream cone somehow translates into a synapse causing a tongue muscle contraction event, then maybe actions and intentions aren’t really real.

So! All settled then! Well no. Here is just a sampling of technical disagreements between philosophers:

Is the “action” of moving a body part the same as the actual movement of the body part? Or is the action just the “intention” bit.
Contrary to the Identity Theory of Mind, some say[5] that you can’t map intentions onto brain states because intentions aren’t events, so you won’t find any corresponding physical events to map to. That’s why, explanations in everyday conversation, even by pro-ITOM philosophers and scientists, are in terms of intentions (“she crossed the road to catch the bus”) rather than mental and brain states. Still others say that “intention” isn’t real, it is only a story we tell to explain the world.
Some say “that which causes an action constitutes the agent’s reason for it.”, others say that you can’t explain the “reason” why somebody did something by just looking at what “caused” it.[5]
Causal Fundamentalism says that everything can be explained at the “physics” level of causes and effects, others say no.[5]
Some say actions are a subclass of events; others say actions are a relationship between an agent and an event, i.e. actions are instances of the relation (agent, “bringing about”, event). [Programmers think: difference between “class Action extends Event” versus “create table BringingAbout(ActionID,AgentFK,EventFK)”]

So, does the action of “turning on a light” include “the light illuminating”, or does it stop at “flipping the switch”, or at “the hand movements that flip the switch”, or at “trying to move the hand”? Does it include the firing of the neurons? the muscles contractions? the moving of the bones? Are they all separate actions, or not actions at all? Are they the only actions with no overarching “flip the switch” action?

As I wrote about the mind/body problem, I think we have a levels of abstraction problem here.

Programmers understand that systems are built in layers where each layer exposes WHAT it can do on top, hiding the HOW it does it underneath. The how of one layer uses the what of the layers below it. There are layers on top of layers, and there are layers within layers. Computer software forms a layer on top of computer hardware, but there are multiple layers within each. Within software there are layers for programs on top of High Order Languages on top of Assembly language. Within hardware there are layers for processors & memory on top of logic circuits & amplifiers on top of transistors & resistors on top of literally layers of silicon dioxide & gallium arsenide. Some of these layers are so complete and versatile that they form their own independent paradigm such that events can be completely described at their level with no reference to layers above or below it.

Another way to look at levels of abstraction is in the way that the same series of events can be interpreted in a hierarchy of meaning. For example, this text has meaning as a series of sentences, but it can also be interpreted as just a series of words, which are just a series of letters, which are just a series of ASCII codes, which are just a series of hex digits, which are just a series of binary digits, which are just a series of alterations between zero and five volts on a chip. Same universe but simultaneous multiple levels of interpretation into events.

The WHAT defines the intention to do some action, and The HOW is the planned (in advance or on the fly) set of more detailed actions to accomplish it. One can describe and explain the action at any level, but confusion occurs when jumping around from one level of abstraction to another. This is a problem when programmers or philosophers do it. Intermixing instructions at one level with more detailed instructions from lower levels makes it hard to follow the logic at either level. Non-programmers can understand this by imagining a cake recipe that goes into the instructions for growing wheat in the section that “desires” a cup of flour.

SO, human agency is equivalent to the “top level of abstraction” that is deciding WHAT ultimate goal state is desired, and it entails all the lower levels. And like a software process (i.e. agent), there is a “thread of control” that threads through the call stack, traversing down through the levels of HOW, returning back up through layers of WHAT.

Intention

What is it for a person to “will” or “intend” an action? Does the intention to raise one’s arm manifest itself as a brain state that can be seen in some scanner, as distinct from the actual activity of raising that arm? Jennifer Hornsby rejects “the physicist’s Fundamentalism”, because it lacks “intentionality”[5]. As described earlier, each level of abstraction can simultaneously tell the story in its own terms, BUT, that doesn’t mean being able to see “intention” at any level just from looking at “what happened”. In the first place, it is hard to translate upward in the abstraction layer cake. Secondly, looking only at the events that occur leaves out the intentional logic paths not taken.

Even though programmers know that there is “intention” in programs (because that’s how we write them!), in programs written by someone else it is often difficult to divine what it is. To translate back up to the “WHAT was intended” from the “HOW it was implemented” is so hard that we tell programmers to write it explicitly in comments in the code. When faced with fixing a flawed program whose intention isn’t clear, programmers will prefer to rewrite it from scratch rather than trying to figure out what it was doing.

Programmers know that when analyzing an ICE instruction trace (think flight data recorder for programs), it will not show all the “intention” in a program because it will not show the paths in the program logic that were not taken. You might infer that a decision was being made by the code when it executed certain test and branch instructions, but you won’t see the “road not travelled”. That’s why in debuggers it is crucial to have access to the source code to see the complete logic, whether it was executed or not, otherwise one could not diagnose and correct any incorrect translations of “intention” at one level of abstraction into a “plan of action” at the next lower level.

Also, with regard to looking for intention in brain (or computer memory) states, it is in the program logic, not the “state data” nor the instruction trace. BUT, intentions are not mystical nor abstract, they are physically embodied somewhere. With computer programs, it is in the encoded logic which sits side by side with state data in memory hardware. Because, at the right level of abstraction, the encoded intentional logic IS just data.

Now, like action theory rules, workaday computer programs lay out the “intentions” in designed plans of explicit rational language. In artificial intelligence programs, the intentions are often implied via weighted scoring of alternative actions. And, the brain may act more like the ant colony example of emergence. The “purposeful” behavior of the colony as a whole “emerges” out of the actions of all the individual ants who presumably have no clue about the “intentions” of the colony. So brain/colony intentions may not be “designed” as much as “evolved”. On the other hand, programmers are painfully aware of inexplicable behavior by programs that they designed. And, lest non-programmers assume that rationally designed program behavior can’t mindlessly evolve, there are many times when bugs get fixed by making a local logic change with no idea of the global consequences; and if that band-aid causes a new bug over there, then another band-aid is placed over there, and so on, until the behavior has evolved just enough to pass inspection. However, in all those cases, while the intentions at one level may be hard to map to those at another, they are, in fact, all there at once.

SO, why DID the chicken cross the road? Well, because the muscles in the left leg contracted causing it to move forward, then the muscles in the right leg…

[1] Philosophy Bites podcast on agency 
http://philosophybites.com/2008/06/jennifer-hornsb.html
[2] Casati, Roberto, Varzi, Achille, "Events", The Stanford Encyclopedia of Philosophy (Fall 2008 Edition)
 http://plato.stanford.edu/archives/fall2008/entries/events/
[3] Wilson, George, "Action", The Stanford Encyclopedia of Philosophy (Fall 2009 Edition)
 http://plato.stanford.edu/archives/fall2009/entries/action/
[4] Smart, J. J. C., "The Identity Theory of Mind", The Stanford Encyclopedia of Philosophy (Fall 2008 Edition)
 http://plato.stanford.edu/archives/fall2008/entries/mind-identity/
[5] Jennifer Hornsby, Agency and Actions, Cambridge Univ Press, 2004
 http://eprints.bbk.ac.uk/95/
[6] Jacob, Pierre, "Intentionality", The Stanford Encyclopedia of Philosophy (Fall 2008 Edition) 
http://plato.stanford.edu/archives/fall2008/entries/intentionality/

Prestigious Programmers Process Persons Philosophically

2009-09-12T11:42:00.008-04:00

Like the “mind/body problem” discussed earlier, I think Programmers have interesting input for Philosophers on another perennial topic of theirs: “personal identity” and the side topics of teleportation and duplicating people (“persons” in philosophy speak). In addition to a perspective on whether the transported person is the same as the original (which is the normal focus of attention), programmers also have an insight into an oft overlooked aspect: Why would a duplicate ever act differently than the original?

Beam Me Up, Scotty

In [Western] Philosophy, “personal identity” is the thing that links a past, present, and future “you” such that it is right to hold “present you” accountable for the acts of “past you”, and “present you” cares about what happens to “future you”. In many philosophical discussions of “what is a person”, and “what is consciousness”, the topic of teleportation (aka teletransportation) comes up. To the non-philosopher, it is probably surprising that science fiction is discussed in scholarly debates about what is “really real”. The Star Trek transporter (and many variations of it) are discussed because it stops participants from getting away with shallow “common sense” answers. It presents problems with simplistically defining a person as the collection of atoms that embody that person, or as an unbroken series of memories, or as a soul (of the Judeo-Christian type).
For example:

When you re-materialize from transporting, if you are made up of different atoms than constituted you before you left, are you really you? Or, are you a clone with the original you having died?
When you re-materialize, are you still you because you are made up of the same unbroken series of memories? But, if you say yes, what happens if the transporter fails to destroy the original? If the one now on Mars is you then who is the person still standing on the transporter pad here on Earth?
If you consider teleportation as constituting a “break” in memory/consciousness, and therefore you would not be the same person, then why are you considered to be the same person after being unconscious with no memories for 8 hours each night?
If you have/are a soul then what happens to it? Does the re-materialized you get it? What if the original you wasn’t destroyed?

Artie Deco and 4-Q-2

A variant on transporter discussions is simply around duplicating a person, and it is here that I would acquaint philosophers with the Unix system call: fork().

In the Unix operating system, there are “processes” that run (apparently) simultaneously, and are analogous to persons. Like a person, each process has its own memories, its own intentions, and its own “location in space-time”. And, via the fork system call, processes can be duplicated. In fact, the fork scenario is even stranger than a transporter…

Imagine a special small room, and inside is a black vending machine with a single button. If you enter the room and push the button, a cell phone is dispensed. Except that when you pushed that button, a copy of you was created in another dimension, and to both you and the copy, it seems like nothing has happened. It appears to each that they are the one who just pressed the button and was given a phone. When each copy leaves the room, they are back in the same original dimension, and each may encounter and interact with the other.

Now, how would you know if you are the original or the copy? Does “original” and “copy” even have meaning here? Most people would try to answer in terms of “who has the original atoms” and the like, and if one copy did have them then the situation is the same as the broken transporter scenario. So, imagine further that until either copy does something to cause its body to diverge from the other, the copies even share the same atoms. On an atom by atom basis, each copy only gets its own as either copy does something to diverge on that particular atom. And, it is effectively random which copy keeps any particular atom as they diverge over time. SO, which one is the original, and which one is the duplicate? I.E. which one is the “same” person as the one that originally hit the button?

As contrived as that scenario sounds, that’s what happens when Unix forks a process (with the help of copy-on-write virtual memory). And programmers have an answer as to which one is the “same” as the original. …drum roll please… ahem…

“It is so arbitrary that God has to tell each whether they are the original or the copy!”

What do you think the cell phone is for? Actually, the cell phone serves two purposes (to keep the analogy really strict); each phone has a text message with either the phone number of the copy (meaning that YOU are the original), or a zero, meaning that you are the copy. The original is free to call the copy.

But I Don’t Want To Be The Copy

Here is the part that Star Trek, et al, usually gets wrong, and Philosophers don’t seem to ponder: Why do the copies act differently than each other? One mitigating factor is that each copy is usually materializing in a different location, or a different time, or with special defects (like milquetoast Capt. Kirk versus Mr. Hyde Capt. Kirk), so they can be forgiven for not having each copy act in lock step. But in the fork scenario, they exist in the same situation, and therefore would do exactly the same thing as each other. Whoa! What about Free Will and all that stuff? Well, given the same location, environment, memories, “programming” if you will, why shouldn’t they do exactly the same thing as each other?

With Unix processes, unless the programming takes note of whether it is the original or not, and unless it does different things based on that information, each copy will attempt to do the same things. They will only diverge as they both attempt to do something that only one will be allowed to do. For example, locking a file, or reading the very next bit of data from an already open file. The Unix operating system (aka God), will arbitrarily pick one of the copies to succeed when both try simultaneously. [Think multiple CPUs all you geeks shouting that they don’t really do things simultaneously.] So, the copies begin to fitfully diverge as one succeeds then does what it planned to do upon success, and the other one fails then does what it was planned to do upon failure.

Now, programmers know that to be productive, they must decide what they want each copy to do, and write the program in such a way that each does what it is supposed to. With people, you must know what will happen when you press that vending button, and why you are pressing it, and what you want each copy to do, AND HAVE THE WILLPOWER TO DO IT!

It does no good to have a plan about what the “copy” is supposed to do if you have the personality that is going to decide after it’s too late that you don’t want to be the copy! If your "programming" is such that, after pressing the button, you decide to not look at the text message because now you don't really want to know...well then the OTHER copy is going to do the exact same thing! [If you do look but decide to ignore it then, unlike a program, it gets to be a psychological issue of whether you really can ignore it.]

There is a wonderful exploration of all these aspects in the movie “The Prestige”. I would point out each scenario, but I so want you to see it if you haven’t already, and I don’t want to spoil all the twists and turns at the end.

[1] http://www.amazon.com/Hardware-Wars-30th-Anniversary-Collectors/dp/B001OTSFE4/

Programmer: What Mind/Body Problem?

2009-09-02T18:00:00.008-04:00

While my general project these days is trying to teach programmers the many things they can learn from Philosophy, I am once again struck by how many philosophers get confused by things that programmers understand quite well. In today’s particular case, it is while reading "Which Physical Thing Am I?"[1], and once again, it is related to the "mind/body problem". That essay ends “if this philosophic hypothesis seems implausible to you, you try to formulate one that is less implausible.” Well, my reply is "let me teach you about levels of abstraction and RAID drives”.

Mind/Body Problem

Thinkers over time have recognized that a person remains the “same person” even though their body undergoes changes over time, even to the extent of losing parts; say, an arm, or a leg. In 1954, it was discovered that "98% of the atoms in the human body are renewed each year"[2]. This has led many to conclude that what makes a person a person, must be different and separate from their body. For some, this different thing is a "soul". For others, it is a "mind" or “consciousness”. In general, this is often called mind-body dualism.

Others have concluded that, because nothing exists outside of physical reality, the mind can't be different from the body, but since the body does change over time, there must therefore be some subset of the body (say, the brain) that is identical to the mind. Jews and Muslims believe[4] that there is a bone in the spine, called the "Luz", that doesn't decay, and from which the entire body will be rebuilt during resurrection. Dr. Roderick Chisholm, thinks that, while it probably isn't the Luz bone, it likely is something microscopic within the brain. In "Which Physical Thing Am I?"[1] he writes,

"I am literally identical with some proper part of this macroscopic body, some intact, nonsuccessive part that has been in this larger body all along."

[By "nonsuccessive", he means something that is NOT a series of different parts over time. By contrast, an army regiment is successive in that it can exist for hundreds of years even though no individual soldier does.]

Software/Hardware Non-problem

Now keep in mind that the Stanford Encyclopedia of Philosophy[3] describes Chisholm as "widely regarded as one of the most creative, productive, and influential American philosophers of the 20th Century", and that Chisholm published the above in 1989 (not 1889), and it is included in anthologies[1] as recently as 2008 (not 1908). It is not just ancient philosophers who get confused over this topic. What are they confusing that programmers know?

Programmers know that software (like the mind) runs on hardware (like the body), but it isn’t synonymous with the hardware. That doesn’t make software mystical or beyond physical reality; it is just at a higher level of abstraction. At that more abstract level, software exists as an information process whose data state at any given point in time is embodied in some set of physical components. But it would be the same software even if running on other equivalent hardware.

In fact, there are several layers of abstraction between your typical program and hardware, what with Java code compiled into virtual machine code, interpreted in a VM written in C code, that compiled to Intel assembly code, that assembled into hexadecimal machine code,… And we haven’t even made the leap to electrons flowing through transistors yet! The point being that software doesn’t care which transistors, even though every i+=1; statement runs in lock step with some transistors somewhere doing something specific to implement them. If that flip-flop didn’t flop then that bit wouldn’t change, and that auto-increment instruction wouldn’t increment, and so on. But, a programmer understands that it isn’t the electrons running through the NAND gate that “makes” a program DO what does, any more than some x=0; statement makes a Square.draw() method DO what it does. They all happen simultaneously at different levels of abstraction.

RAID fights bugs

To Chisholm’s particular point that continuous personhood requires (at least some) continuous body bits, programmers know that the “life span” of any particular set of data, is not tied to any particular physical component. Information is independent of the media used to record, or embody, or carry a copy of, that information. A perfect example is a RAID device containing multiple disk drives. Data in a RAID is kept in multiple physical locations such that any particular location can be destroyed without losing the data. So, an arbitrary set of data (say, a file) can exist unchanged over time, even though the hardware storing it has completely changed. With a “hot swap” RAID, a system using that file would have no idea that a drive died, was removed, replaced with a new drive, and that new drive re-populated with data.

And, just like a mind’s constantly changing data set, that file’s contents on the RAID device can be constantly changing. And those constant data changes are totally independent of the constant drive changes that might be taking place inside the RAID.

The point here is not “the brain is a RAID drive”; the point is that a RAID drive is an existence proof that ongoing software processes do not require “intact, nonsuccessive” hardware. And the larger point is that Mind and Body can both be understood as simultaneous lock-step processes at different levels of abstraction in the same way that C++ method calls are in lock-step with CMOS chip voltage changes.

[1] Metaphysics, the big questions, 2nd Ed., 2008, chap 35
[2] Time Magazine, Oct 11, 1954 quoting Dr. Paul C. Aebersold of Oak Ridge
http://www.time.com/time/magazine/article/0,9171,936455,00.html
[3] http://plato.stanford.edu/entries/chisholm/
[4] http://en.wikipedia.org/wiki/Luz_%28bone%29

Faces with je ne sais quoi

2009-08-11T08:55:00.009-04:00

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.

An Adjective is a Noun is a Verb

2009-06-10T14:01:00.017-04:00

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:
"(x instanceof 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.

[1] Understanding Linguistics: The Science of Language, John McWhorter
- http://www.teach12.com/ttcx/CourseDescLong2.aspx?cid=2270&pc=Social%20Sciences

- Understanding Linguistics: The Science of Language (Parts 1-3) DVDS & Guidebook

XistP is the abbreviation for Existential Programming

2009-05-28T14:32:00.001-04:00

After having written many blog posts, essays, emails, etc, etc using the phrase "Existential Programming", it is getting pretty tedious to keep spelling it out. An official abbreviation is needed!

Unfortunately for me, XP is already taken for "Extreme Programming". XSP is taken TWICE!
Once by Apache for eXtensible Server Pages, and also for an ASP.Net server implementation. XIST is the name of an RNA gene, XSTP is the eXtended Satellite Transport Protocol, xISP/XISP/Xisp is used for all sorts of things, ...

...so, the not so short (but shorter than the whole phrase) XistP is my choice for the official abbreviation for Existential Programming.

A rose is a rose is (not) a rose

2009-04-07T02:06:00.010-04:00

In several of my earlier blog entries, there was discussion as to whether words like "rose" have meanings, or are only references to things. Shakespeare thought they were only references to things when he wrote "A rose by any other name would smell as sweet". My conclusion to the contrary (based on "salt") has been given empirical evidence, as described in a story on National Public Radio[1].

Lera Boroditsky, an assistant psychology professor at Stanford University, had conducted experiments in which people were shown to be unconsciously affected by the language they spoke when they described things. In languages like German and Spanish that have "gender", each noun (unlike English) is either male, female, or neuter. However, languages aren't consistent with regard to the gender of any particular word. In German, the word for bridge is feminine, and in Spanish it is masculine. When test subjects were asked to provide words describing a picture of a bridge, the Germans came up with fragile, elegant, beautiful, peaceful, slender, and pretty, whereas the Spaniards came up with strong, dangerous, long, sturdy, big, and towering. Even when the test subjects were taught a completely made up language that had gender, they chose descriptions of things that matched the gender of the made up word for that thing.

So, when doing the business and technical analysis of systems, be aware of attached connotations and concept interrelationships before translating rich natural language words like Salary into antiseptic variable names like Foo.

[1] "Shakespeare Had Roses All Wrong", Robert Krulwich

http://www.npr.org/templates/story/story.php?storyId=102518565

Class Constructors considered harmful

2009-01-22T17:19:00.001-05:00

My basic project these days is to learn Philosophy 101 and contemplate what impact that knowledge should have on software development practices. After reading topics like the Philosophy of "becoming", and Aristotle's "four causes", it is clear that Philosophers spend much more time trying to define the circumstances of an entity's creation than do system analysts and programmers. While Philosophers have long been concerned with WHY did WHO do WHAT to cause an object to come into being, programmers are mostly concerned with the mechanics of HOW an object should be constructed. It strikes me that this is due to the tunnel vision encouraged by the class constructor method. [And, due to destructors and automated garbage collection, an even worse situation applies to object “death”.] So, to paraphrase a famous title, I (albeit tongue-in-cheek) consider Class Constructors harmful.

In the course of analysis and requirements gathering, a major goal is to identify and define the various business domain entities. But, in a vicious cycle, the definition of an entity is often too shallow with regard to its birth and death because “causal” information often stagnates as merely background text in some requirements document. This is because programmers have no standard place to put that logic into the code.

Object oriented practice has one put "all" the properties and behavior associated with an entity into its Class definition, where "all" for class Dog means "the dog, the whole dog, and nothing but the dog"[1]. However the "nothing but the dog" constraint means that, the logic involved in deciding whether an instance of class X should be created, is not normally a method of class X. Since the "cause" of X's instantiation usually involves other classes, that logic lies outside of X proper, thus, standard development methodologies leave the analysis of causation and purpose out of the design of class X. Even Factory classes are focused on object construction, rather than why it should be constructed, and why now, and by whom.

The Mediation pattern comes to mind as a place to put this sort of logic because it involves multiple classes. The logic that decides it is time for a Sculptor to use a Chisel to carve a Statue out of a block of Marble doesn’t belong solely in any of those classes. A programmer would be tempted to put a “carve” method in Sculptor since that is a “behavior” of the sculptor, but Philosophy considers it an essential part of the definition of the statue itself. And that is a problem with Mediator classes in the first place; the desire to have everything relevant to X be “nearby in the source code” (a raison d'être for classes) is defeated when some of it is off in various Mediators. Having the teleology of Statue off in some CarveMediator isn’t much better than it residing in Sculptor.carve().

With event-driven systems (e.g. MOM, SOA), the series of events that trigger the creation of an entity instance may be complex. And whether event-driven, or "batch processing", the sub-systems are often distributed, increasing the value of encapsulating this logic in a single place. With Java EE and service oriented designs, there would be value in having the entity services include this logic.

In any event, I believe that there is a need to learn from Philosophy that their concept of "form" (which is the equivalent of OOP's class) has always included the purpose of a thing as well as its blueprint.

[1] Object Oriented Analysis and Design, Grady Booch, 1991

Does data have velocity?

2008-12-14T11:06:00.009-05:00

While reading I am a Strange Loop[1] by Doug Hofstadter, where he is trying to come up with an appropriate metaphor to explain his notion of a single human "mind/soul" being distributed over multiple human brains (somewhat like a country is distributed over its many scattered embassies), it made me muse on the boundary between an actual distributed mind/soul and other mind/souls that are merely affected/influenced by that mind/soul. This is of course a particular instance of the general problem of determining the boundary of a diffuse object. The boundary of a solid asteroid is easy to determine whereas the borderline between one planetary ring and an adjacent ring is harder. Any individual "rock" residing in the region where two rings overlap could be a part of either ring.

A data example of this problem is the one where lots of individual names/addresses need to be clustered into identities even though there is variation in the various names/addresses. There are cases where it is ambiguous which identity "owns" a particular name/address when the fuzzy blob of one identity cluster overlaps the fuzzy blob of another identity. How to tell which one it belongs with? Why do we even think that there are two overlapping blobs instead of just one oddly shaped blob?

AHA - Look at velocity!

The problem of determining which points belong to which overlapping fuzzy regions is hard when looking at a static picture, however it is easy when there is movement. When looking at which stars belong to which of two colliding galaxies, we look at the velocity of the star to see which galaxy it is moving with.

So, can this be applied to data? Is there some "velocity" that can be determined for each data point such that it can be associated with the "proper" data cluster? Is there a velocity associated with a name/address instance?

[1] "I am a Strange Loop",2007, Hofstadter, Basic Books

Silver Bullet: Model the world, not the application

2008-10-22T13:27:00.049-04:00

DISCLAIMER: Ok, I admit it...this is cut/pasted directly from my brain fart notebook, i.e. not ready for prime time...but dammit Jim, its just a blog!

Your Pipe Inventory Record is not a Pipe

2008-04-30T12:04:00.004-04:00

In this blog, I recently posted: Reality is the System of Record. Unfortunately, I just found a lost reminder to myself about a really good introductory example to use. Even though it didn't make it into the original post, it seems worth mentioning here anyway...

La trahison des images is a famous painting by Magritte which seems to pose a riddle. It contains nothing but a pipe and the phrase, "This is not a pipe". However, it only seems enigmatic because the solution is too obvious.

As Art critic Robert Hughes explains in The Shock of the New, "This, indeed, is not a pipe. It is a painting; a work of art; a sign that denotes an object and triggers memory". As Magritte himself once remarked, "Of course it's not a pipe. Just try to fill it with tobacco".

In other words, it is a representation of a pipe, not to be mistaken for an actual one. And as obvious as that seems, computer system developers make the same mistake all the time. They do so when they forget that their Customer data table & business domain objects are not actual customers, but only representations, i.e. memories, i.e. copies of information. So, as with all cached copies of external data, it is the duty of your so-called "system of record" to keep in sync with the real customer, in the real world, because Reality is the System of Record ...

Reality is the System of Record

2008-04-17T13:03:00.927-04:00

"The system of record is the place where there is a definitive value for some unit of data... If you have no system of record for your bank account or if you have multiple systems of record for the same account, something is fundamentally wrong."
Bill Inmon, father of the data warehouse.[1]

Over my years of consulting in large enterprise environments, I've heard arguments over whose system is the "system of record" for some particular piece of data. I have seen programmers officially acknowledge another system as the SOR, all the while building their own system as if it were. I've also heard corporate developers say that something is a customer if and only if it has a record in the SOR (never mind what the customer thinks, nor if the record literally has the name "Donald Duck"). I've seen that same customer information system built with so little regard for mirroring the real world that it defined Frankenstein customers, some of whom were composed of parts from multiple actual people. Owning an SOR seems to breed a certain lack of humility which (IMHO) could benefit from learning a little Philosophy. It will teach you that you are never the system of record, and instead, merely a "faint copy" of one of many idiosyncratic conceptions of the world.

Representationalism

In modern Cognitive Science, there is the assumption that "the mind has mental representations analogous to computer data structures". The idea in Philosophy that "the mind perceives only mental images (representations) of material objects, not the objects themselves"[2] is called Representationalism (and more generally indirect realism), and it can trace its roots across 2400 years of Philosophy of Mind. Socrates says (in Plato's Parable of the Cave) that most people only see shadows of puppets instead of reality. Aristotle said thoughts are likenesses of things, and words refer to things indirectly through thoughts. Rene Descartes proposed that all sensory information is transmitted by the nerves to a central "theatre", where the soul makes contact with the physical body and watches it. John Locke said, "The mind represents the external world, but does not duplicate it." David Hume thought that ideas were "faint copies" of physical sensations.

Skepticism (i.e. the notion that we don't know what we think we know) is one of the oldest ideas in Philosophy, and the raison d'être for the entire branch called Epistemology (which asks how can we be sure we know what we think we know?). They were born from the ancient realization that our formation of ideas, concepts, and representations out of our sensory input (hidden behind a "veil of perception") is a very inexact process, complete with optical illusions, dreams, hallucinations, color-blindness, double vision, etc, etc. In Immanuel Kant's "Critique of Pure Reason", he argues that because our minds are hardwired to perceive the world in certain ways, they actively shape experience rather than passively record perceptions. His claim was that our sense perception is effectively a pair of tinted glasses that we can't take off. Because we've never seen the world without them, it takes effort to see the world as it is really is. One of the very reasons to practice Philosophy is to understand the true nature of things and avoid the "naive realism" of "common sense". Guides to this understanding are found in the branches of Metaphysics and Ontology which explore how to understand and model the world respectively. One of the tactics of Epistemology to aid in this effort is the doctrine of Verificationism which says that a statement has no meaning if there is not a way to verify its truth.

For programmers, the big epiphany here should be that their business database is really just one particular representation of reality, not reality itself. Reality is the System of Record. A developer should be humble, and realize that it is difficult to accurately model the world such that it integrates with the data models of other systems. They also should be skeptical that their actual data is both accurate and up-to-date, developing ongoing mechanisms to actively verify each.

Syncing the Systems of Record

When any system keeps copies of data for which it is not the system of record, that system is actually just a cached copy of that external data. And like any cache, it has the responsibility to keep track of whether its copy is "stale", and to implement mechanisms to insure "cache coherence". Once one realizes that reality is the system of record, it becomes clear that it is not enough to keep databases in sync with each other; they ALL must chase after the ever-changing state of the world.

In a large organization, each database is just one of many competing representations. In the same way that different people have different mental representations of their shared reality, different databases will each have their own slightly (or largely) incompatible data models, and sets of data values, for the same domain entities. A side-effect of this is that many systems keep copies of external data that they've transformed in some way for their own use. When systems don't realize that their SOR data represents the same real-world entities as other SORs do (e.g. patient DB versus employee DB), the eyesight of the entire enterprise goes out of focus as each data-set drifts apart.

CASE STUDY: ChoicePoint

ChoicePoint was an independent company prior to being bought out by Reed Elsevier in 2008. It collected and combined data about businesses and individuals from a wide variety of sources, selling access to both private and public (i.e. government) clients. While consulting there, I saw first hand how data was effectively only verified if someone phoned in to complain about inaccuracies. I also was informed by management that no access control mechanisms were to be included in the design of a new system, despite Congress exploring adding requirements for such. They said that ChoicePoint wanted to be able to protest at the cost of adding the controls after the fact in the hope that it would defeat the requirements in the first place. There have been a whole series of lawsuits and government actions against ChoicePoint for out-of-date data, inaccurate data, and selling data to unauthorized buyers which cost it so much money that it had to be sold.

[1] The System of Record in the Global Data Warehouse, Bill Inmon, Information Management Magazine, May 2003
http://www.information-management.com/issues/20030501/6645-1.html

[2] Representationalism, Encyclopædia Britannica
http://www.britannica.com/EBchecked/topic/498476/representationism

The Logical Positivists were Test-Infected(Is that a good thing?)

2008-03-20T13:59:00.020-04:00

While reading Looking at Philosophy[1], I came across the section about Logical Positivists[2] whom I immediately recognized as "test infected"[3]! The Logical Positivists (circa 1910s-1930s) promoted the idea British philosopher, A. J. Ayer, named "the principle of verification"[8][9] i.e. "the meaning of a proposition is its method of verification". In other words, a statement is meaningless if it can't be objectively tested. This is the same big idea of Test Driven Development[5] and more specifically Test Driven Specifications[6] (aka Test Driven Requirements[7]); namely, don't create a requirement (or interface definition) that is so vague, subjective, or contradictory that an automated computer program can't be written to test for compliance.

In other words, all that verbage[12] that usually passes for a specification/requirements document is really just commentary to the REAL specification which is encoded in a comprehensive compliance test suite. [BTW, this isn't just a software concept since IC chips have long had not only "testbed" circuit boards to test chips, but also ICE (in circuit emulators) to test circuit boards via simulated chips (which software copied with "mock objects").]

The goal of both Logical Positivists and test-driven engineers is to weed out statements that are so poorly conceived and worded as to be effectively meaningless. The way to ensure this is to submit each statement to this rigorous method and rework any statements that come up short.

What did Logical Positivists have to say about "how" to do tests?

My whole excitement about finding philosophy movements that parallel aspects of software engineering is the notion that "top men"[11] have already thought and argued long & hard about this stuff, and therefore we programmers can benefit from what they've already learned the hard way. So, what method did they advocate? Basically, it is the idea that all statements should be broken down into "protocol sentences" plus logical conclusions built on top of them. Protocol Sentences were to be simply observation reports (based on first hand direct sensory experience). This was ultimately unworkable for humans, but everything in a computer test is based on its first hand direct sensory experience (of electrical signals anyway).

Karl Popper, among the most influential philosophers of science of the 20th century, said that claims could only be considered "scientific" if they were falsifiable, meaning that there should be some observation or experiment specified that, if it were verified, would prove the claim false.

Logical Positivists claimed that unverifiable statements were LITERALLY meaningless, and therefore they dismissed entire disciplines like metaphysics, morality, and ethics. Other, more moderate philosophers held that untestable propositions were merely unproductive to work with. Popper claimed that his demand for falsifiability was not meant as a theory of meaning, but rather as a methodological norm for the sciences.

Uh oh, Logical Positivism was considered a failure...Will Test Driven be too?!

I was all happy about a philosophical foundation to being test driven (since I was test infected years ago), until I got to the part where Logical Positivism has been so devalued by other philosophers that one wrote "Logical positivism is one of the very few philosophical positions which can be easily shown to be dead wrong, and that is its principle claim to fame."[10] OUCH!

By saying that so-called metaphysical claims were meaningless, they unwittingly said that the very claim "metaphysical claims are meaningless" was itself meaningless! I.E. there was no way to prove the statement that "only provable statements had meaning".

Lessons for the Test Driven Approach

Luckily, Logical Positivism was only an extreme position in the spectrum of ideas under the Verificationism[4] umbrella. In the conclusion of "Verificationism: Its History and Prospects"[8], some points were noted...

one can't reduce every statement to be a logically equivalent statement about sensory experiences. (i.e. not every thought comes under the umbrella of "natural science")
one can say that "a statement lacks legitimacy or objectivity if there would be no evidence for or against it; if it is insulated from reason, where reason is linked to the possibility of public evidence for or against the statement from other, already established statements"
one must admit that some more abstract statements are understandable even if not testable.

So, the bottom line seems to be that the Test Driven approach is a good one if you...

concentrate on testing what can be tested,
create tests that would actively prove statements to be false, and
know that you probably can't prove (with tests) that the test driven approach itself is correct.

[1] Looking at Philosophy, Donald Palmer, 4th Ed. 2005

http://www.amazon.com/Looking-At-Philosophy-Unbearable-Heaviness/dp/0072828951/ref=ed_oe_p

[2] ibid, pg 327

[3] http://c2.com/cgi/wiki?TestInfected

[4] http://en.wikipedia.org/wiki/Verifiability_theory_of_meaning

[5] http://en.wikipedia.org/wiki/Test-driven_development

[6] Acceptance Tests and the Test Driven Specification

http://www.theweightlesseconomy.com/?p=12

[7] Test Driven Development or Test Driven Requirements?

http://www.infoq.com/news/2007/11/tdd-or-tdr

[8] Verificationism: Its History and Prospects, C. J. Misak, 1995

http://books.google.com/books?id=e8hZ64yWG_EC

[9] Language, Truth and Logic, Alfred Jules Ayer, 1952

http://books.google.com/books?id=2CSkYN2KGjQC

[10] Prolegomena to Philosophy, Jon Wheatley, 1970

http://worldcat.org/wcpa/top3mset/83152

[11] "top men", Raiders of the Lost Arc

http://www.youtube.com/watch?v=yoy4_h7Pb3M

[12] verbage vs verbiage

http://foldoc.org/verbage

Scott is Scott

2008-03-11T23:37:00.016-04:00

While reading Looking at Philosophy[1], I came across its discussion of Bertrand Russell's Theory of Descriptions[2]. It was a proposed solution to several problems that occur when logic propositions are made about an entity's existence or identity. One of the problems being solved was that a statement like "Scott is the author of the novel Waverley", if it is true, reduces to the statement "Scott is Scott". This is because in traditional logic, two terms that denote the same object can be interchanged without affecting the meaning or truth of a statement. But since "Scott is Scott" doesn't seem to be equivalent to "Scott is the author of Waverley", Russell proposed that a better way to state the latter was using the template:

There is an entity C, such that the sentence "X is Y" is true, iff X=C.

This would produce the sentence "There is an entity C, such that "X wrote Waverley" is true, if and only if X=C; moreover, C is Scott". What Russell was getting at was that there was a problem with the traditional view that a definite description could be exchanged with a proper name. A phrase describing something (e.g. "the author of Waverley") means something different than a name (e.g. Scott) because while it is true that "George IV wanted to know if Scott was the author of Waverley", it is false that "George IV wanted to know if Scott was Scott". Russell's template solved this problem along with others like making claims about non-existent things. E.G. "The present king of France is bald" is problematic because there is no present king of France. If it were considered false then "The present king of France is not bald" would have to be considered true. This is avoided by saying instead: There is an entity C, such that the sentence 'X is French, bald, and kingly' is true iff X=C. THAT statement is false (because there is no entity that fits that description), and its opposite is true (i.e. There is NOT an entity...).

[1] pg 322, "Looking At Philosophy: The Unbearable Heaviness of Philosophy Made Lighter", 2005, Palmer
[2] Existence and Description, Bertrand Russell from "Metaphysics: an anthology" by Jaegwon Kim, Ernest Sosa - 1999

Is there anything left after all the roles are stripped away?

2008-02-07T20:44:00.007-05:00

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

Word Matters: Words Matter

2008-01-25T01:16:00.011-05:00

In my earlier blog entries, I noted the debate over whether words had meanings, or were only references to things. It was noted that while "rose" and "gulaab" work equally well for speakers of English and Urdu, "Superman" was not interchangeable with "Clark Kent". This was because Superman and Clark Kent both referenced different aspects of the same entity instead of both referencing the same entity as a whole.

However, the actual words still didn't matter in that discussion. While Clark Kent was different than Superman, the actual word "Superman" didn't matter...it could have been "Clark Kent is different than Foo" (if everyone called the man of steel "Foo" instead of Superman).

After reading Salt: A World History[1], I've decided that words DO have their own meaning because of all the connotations, and rich web of connections with history, culture, and language, that go along with each. The book is chock full of nuggets like the following (paraphrased):

The first of the Roman roads, the Via Salaria (i.e. Salt Road), was built to bring salt not only to Rome but across Italy. It was important because at times the Roman soldiers were paid in salt which was the origin of the word salary and the expression "worth his salt" and "earning his salt". The latin word for salt (sal) became the French word for pay (solde) and that was the origin of the word soldier.

The book makes it obvious that the word Salt couldn't really be much different given its linguistic lineage. Words DO matter because each has a whole slew of connections to other things, and a past history, because each is part of a naturally evolved language. Words evolve from other words; they were not picked out of the air. There is a family tree of related words just like there is a family tree of organisms with related DNA.

Knowing the rich set of interconnections of words, their origins, history, etc makes a word like Salary carry many connotations that "foo" would not. A whole semantic network of related concepts lights up in my mind with the word Salary that would not have if the word for salt was foo.

[1] Salt: A World History, by Mark Kurlansky, 2002

Shakespeare is (not) Shakespeare

2007-12-25T14:38:00.015-05:00

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.

POSTSCRIPT - March 30th, 2010
In addition to the attributes of one aspect not being identical to the aspects of another (e.g. clark vs super), different aspects of a person may hold different beliefs. As described in the 2010 book, "this sentence is false", there is the paradox of the person who, in their role as a physician, believes in high cigarette taxes, but in their role as a smoker, does not.

Clark Kent is (not) Superman

2007-12-19T08:33:00.018-05:00

It delights me to find out that what I thought had been a particular nugget of wisdom, specific to building Identity matching computer systems, actually has a deep principle at work. While working on one of these systems, I learned the strategy of NOT merging all variations of an individual identity's name/address/phone/etc into a single canonical version. It turns out that the need to keep, and assign a unique key to, every variation of identity data (as opposed to only the "canonical" one) has deep roots in language itself...

While reading the Intellectual Devotional (which I highly recommend), I came across its page about "Philosophy of Language" and it had an immediate resonance with a project at my current client. The page describes the "problem of reference" where ideas about what a name "means" have been debated and changed over time.

One theory says that "names" don't have any meaning, in and of themselves, they merely refer to some thing that has meaning. Hence, Shakespeare's quote "A rose by any other name would smell as sweet" summarizes the position that the word "rose" is not meaningful, and could be exchanged with any other word that refers to the thing "rose". That is why "gulaab" (the Urdu word for rose) can work just as well for speakers of Urdu.

Another more modern theory though, says that names not only refer to some thing, they also carry the connotation of "in what sense" is the thing being referenced. The book illustrates the example of Superman and Clark Kent both being names for the same thing (the being Superman), but they are not interchangeable. Clark Kent (mild mannered reporter) has a work address of the Daily Planet whereas Superman (superhero able to leap tall buildings) does not. It matters which name is used when talking about Superman.

So, in the same way that Clark Kent and Superman both refer to different aspects of the same entity, and are thus not interchangeable, a computer system managing legal entity identity data can not translate name/address variations into a single entity ID# when those variations actually refer to different aspects of the entity. For example, if there is data that is specific to a particular store branch, that branch needs its own well-known ID# even though it is only a portion of a single legal entity. Further, since legal entity names are not unique (for example, I personally own two different corporations with the identical legal name), the entire name/address/phone/etc combination needs managing rather than separate "alternate name" lists. It is also not sufficient to support alternate name/address records merely as search aids that still ultimately result in the ID# of the entity-as-a-whole. Otherwise one would loose track of the fact that we were talking about Clark Kent, not Superman.

Cubist Programming?

2007-12-02T15:31:00.000-05:00

In The Stuff of Thought by Steven Pinker, the book talks about human minds being able to hold multiple viewpoints simultaneously about the same event, and that resonates with my ideas for Existential Programming. It also reminded me of my thoughts that Cubism tried to illustrate the same idea. Cubist paintings simultaneously attach different viewpoints of something to the same single "object" (as Existential Programming would have different viewpoints/models of the same "data entity" kept together in the same object).

So, Existential Programming might well have been named Cubist Programming!

Subjective, Objective, Relative, Existential

2007-11-10T12:49:00.002-05:00

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.

[1] Oxford Companion to Philosophy, 2nd Ed, 2005
[2] ibid, pg 667
[3] ibid, pg 800

"Strong" typing not so strong?

2007-11-04T08:27:00.000-05:00

I've been in debates about the wisdom of defining web services with "strongly" typed messages (with specific fields of "specific" types) versus more general messages with, say, fields containing XML content. I have argued that so-called strong types like integer and string are no more "strong" than a segment of XML. This is because the string (and to a lesser extent integer, float, etc) data types are so broad that they can't really be called "strong". Strings are almost always further interpreted by the software and people on both ends of a message.

This notion is embodied by the testing technique known as Equivalence Partitioning. [A good summary is in the article "Make Child's Play of Equivalence Class Partitioning".] It says that there is more detailed structure to data than string and integer and to only test at that level is to miss many crucial test cases. It defines subranges and such to guide what to test, in effect, defining more granular data types. Languages like Pascal and Ada had more refined data types like subranges but those ideas were lost when C-like languages (including C++ & Java) came into vogue.

Existential Programming would change the way data types are defined to get away from simply defining a structure that is an aggregation of "primitive data types". It would let data types define a function that computes whether (or how closely) a putative value meets the requirements for that data type. While one could put that logic in a "setter" method of a class, that doesn't work with direct assignments (via assignment operators) of values (at least in Java-like languages).

To see where even subrange definitions like Pascal/Ada allowed (e.g. 3..27) are not sufficient, look at the logic required to validate the month/day/year values of a date as detailed in the ECP article. Only an algorithm can encode what is required for legal values, not simple declarations of string and integer properties.

So, "strong" typing is a relative term.

atonal versus pantonal

2007-10-21T20:59:00.003-04:00

While reading the Intellectual Devotional[1], I came across its page about the composer Arnold Schoenberg that described how his new musical composition technique (12-tone serialism) was described as "atonal" but he preferred the term "pantonal". This resonated with my desire that Existential Programming be recognized as multi-type programming rather than "type-less".

The analogy here is between the key signature of a piece of music, and an ontology of classes used in a program.

A key signature (e.g. C-major, d-minor) defines which notes are to be used, and the special relationships between different notes. To be "tonal" is to follow the rules of a particular key signature. To be "atonal" is to NOT follow the rules of any key signature. To be "pantonal" is to simultaneously follow the rules of multiple key signatures.

An ontology defines which types/classes are to be used, and the special relationships between different classes. To be "strongly-typed" is to follow the rules of a particular ontology. To be "type-less" is to NOT follow the rules of any ontology. To be "multi-typed" (i.e. existential programming) is to simultaneously follow the rules of multiple ontologies.

[1] "The Intellectual Devotional",2006, Kidder, Oppenheim
http://www.theintellectualdevotional.com/index.shtml

What is redundant?

2007-10-17T20:35:00.001-04:00

In the handy Philosopher's Toolkit book[1], there is a section[2] explaining the difference between "analytic" statements and "synthetic" statements, and in another section[3], "a priori" versus "a posteriori". They are both similar in that they are trying to distinguish between what is known about X just from its definition versus things that would have to be thought through or experiments done to discover them. E.G. "all triangles have 3 sides" and "Joe, the bachelor, is unmarried" are obvious just from the definition of triangle and bachelor. Other statements like "water boils at 212 degrees Fahrenheit" and "Joe, the bachelor, has red hair" are not "entailed by" or "contained within" the definitions of water and bachelor.

There are arguments by philosophers, however, about what IS entailed by a concept or contained within a definition. Some would argue that the boiling point of water *is* contained within the concept of water whether a particular person happens to know that or not. Similarly the statement "all triangles have 180 degrees as the sum of their internal angles" is true independently of whether we know about it, (but a lot of people *wouldn't* know that).

So, in general, there will not be agreement from one ontology/model to another about which statements (i.e. data/attributes/relationships) are redundant. Should the "age" of an applicant for a job be stored because it was a field in the application form? Or, should it always be calculated from the birth date and the date of the application? Should a "short cut" relationship between 2 distantly related entities be explicitly supported by a model, or should it always be "calculated" by traversing all the intermediate links through the "six degrees of separation"?

Even though E/R models will normalize data to an objective standard, different modelers will break normalization for "performance reasons" on a subjective (and thus inconsistent) basis. Existential Programming counts this lack of agreement on "what is redundant" as yet another reason to embrace/support multiple ontologies simultaneously.

[1] The Philosopher's Toolkit, Julian Baggini and Peter S. Fosl, Blackwell Publishers, 2003, ISBN: 0631228748
[2] ibid, section 4.3
[3] ibid, section 4.1

Relativism, Absolutism, and Existential Programming

2007-10-16T20:01:00.001-04:00

In the handy Philosopher's Toolkit book[1], there is a section[2] explaining the difference between relative statements and absolute statements (and similarly relativism and absolutism). As a prototypical example, it explains how before Einstein, the "time" an event occurred was considered an absolute statement. In other words, the whole universe would know what it meant because time was the same everywhere (just different time zones). However, Einstein revealed that time is relative to the location and speed of the observer and can't be the same everywhere. Plus, since there is no place and speed that could/should be considered the "official" one, all "times" are equally valid.

Because there are many aspects of reality and opinion that are considered relative by some number of people, Existential Programming counts this as yet another reason to embrace/support multiple ontologies simultaneously. Absolute vs Relative points of view are yet another aspect of modeling the world that traditional object-oriented and relational database modeling make assumptions about.

[1] The Philosopher's Toolkit, Julian Baggini and Peter S. Fosl, Blackwell Publishers, 2003, ISBN: 0631228748
[2] ibid, section 4.2

A Scanner Darkly: Identification via Accidental Properties

2007-10-12T07:24:00.000-04:00

It is the case that while it is "essential" properties that (by definition) define something, people very often identify types and individuals via a collection of "accidental" properties. For example, in a computer system, accidental (i.e. changeable) properties like name, address, phone number, etc are used to find/recognize/identify people even though they all can change thus producing the age-old problem of "identity over time".

Visually, people normally identify/recognize other people from their accidental attributes like face/hair/sex/etc. These can all be altered and not change their DNA or soul but that's what people normally use. If these change over time people use other attributes, or in the cliche science fiction scenarios where someone has been completely changed / possessed / transferred-essences-with-an-alien / etc, a shared set of secret shared knowledge is used. "Jim, it's really me, otherwise how would I know the name of your pet hamster on Rigel Seven?!" [Banks, Credit Cards, etc have recognized this and have started asking questions like "what's your favorite movie?" before letting you change your password.]

But for visual only recognition, say, for tracking someone through a crowd via a security camera, you are dependent on those accidental attributes not changing in real time. That is the premise for the "camouflage" in the movie "A Scanner Darkly". There is a cloak that constantly changes the appearance of every piece of the face/clothes, and this is illustrated via the rotoscoping and animation used in the movie. This would confuse automated tracking software and you would get lost in a crowd.

In thinking about this, though, I realized that people could still actually recognize the people in these cloaks BECAUSE WE DO IT WHILE WE ARE WATCHING THE MOVIE! A *real* cloak would be much more effective if it didn't change *pieces* of faces, but rather change whole faces at a time. It is easy to pick out the person in the funny changing cloak unless *everyone* is wearing one. Even then, humans can still keep track of who is who (short of a big crowd) because we track the various individuals at a "thing" level. I.E. I can see that there are some "things" in the room and when they move I can still tell who's who because despite their constantly changing "skin", they are still contiguous space-time blobs of matter (that walk a lot like people!).

Introduction to Existential Programming Blog

2007-09-26T22:24:00.006-04:00

This first entry for "Existential Programming" is meant to act as an introduction to the topic and an explanation for the backdated entries to be added over time. Around May, 2006 I had a series of brain farts (ahem, epiphanies) about computer software engineering that led to a theory I decided should be called "Existential Programming". Because I have now collected about a year and half of unedited notebook entries, and I now have enough of an idea of what I mean by Existential Programming to write it up, but because I don't yet have the time to polish a Manifesto into a magazine article, much less an academic paper, I have decided to start this blog and back fill it with my notebook contents, as well as, putting future entries here. The goal is to plant my flag on the topic and its ideas now, even if I can't write "Existential Programming, the Book" yet. [BTW, see my std blog disclaimers.]

A meta-idea above Existential Programming itself, is the more general notion that there should be much more explicit cross fertilization between ideas from Philosophy (with a capital "P") and ideas from software engineering (as practiced in industry). I call this "Philosophical Programming". Early on during my epiphanies, I had the intuition that Philosophy probably had something to say about my topic (even though I'd never taken a philosophy class). So, at age 50, I started reading Philosophy 101 books. It quickly became obvious that Philosophy has SO MUCH to say about data/class modeling topics that it is criminal how little explicit reference to it there is in the software practice literature. I distinguish between industry practice (and their books, blogs, magazines oriented towards tools and "best practices") versus academia. After I learned enough terminology to search for papers covering ideas similar to mine, I found that there is a whole subculture writing academic conference papers that don't really bleed over into industry conferences for things like Java or AJAX or SOA. So, my general "project" these days is to try to come up with practical application techniques based on otherwise esoteric topics.

What is "Existential Programming" and what are the central ideas associated with it? In a nutshell, it means to embrace the notion that "existence precedes essence". I.E. develop data models, object models, programming frameworks, etc. without imposing a single E/R model, OO class hierarchy, ontology, etc. By using techniques where "objects" and "entities" exist independently of a single "strong type", they can integrate multiple "strongly typed" data models by letting objects simultaneously reflect all those models. This differs from weakly typed programming, or completely type-less programming, as can be found in scripting languages like JavaScript. Ironically, it takes a "type-less" foundation to really seriously do strong types in a "multi-cultural" world. [And actually, JavaScript is not a bad platform to implement these ideas precisely because of its class-less orientation.]

The ZEN thought here is that until one can create a type-less object, one can not create an object which can be all types simultaneously.

The ideas that flow from this general notion (or more correctly, caused me to refactor the general notion out of these specific ideas), fall into general categories like:

mixins
data integration using semantic mapping
code integration of uncooperative APIs and Frameworks
promoting "roles" over "is-a subclassing"
open classes and external methods
ontology mediation
object evolution and class/API versioning

My Blog Disclaimers

2007-09-26T22:19:00.011-04:00

The following are my standard disclaimers that apply to this entire blog...

Disclaimer 1: my usual mode of operation is to "discover" something for myself and then later search the literature to discover that someone else, (say Plato) has already had that brain storm. Thus my intuition that "this means something, this is important" only provokes a "DUH" if you already know that it was first written by a philosopher twenty-five hundred years ago, or in a Norwegian PhD thesis 10 years ago. Have patience with the wide eyed innocence which will eventually be made wise. These entries are a journey.

Disclaimer 2: in transcribing my notes a year and a half after the fact, I will sometimes use a philosophical term (e.g. essential/accidental) that I did not know at the time, in order to make it more clear what I was trying to say at that time.

Disclaimer 3: having just started teaching myself Philosophy 101, I know just enough to be dangerous. However, I have 30+ years of hands-on software engineering knowledge and experience, so I feel qualified to recognize gaps in today's state of the art (as practiced in the real world, i.e. corporations, not academia) which can be filled with concepts developed in Philosophy.

POSTSCRIPT - March 1st, 2010
I found a quote that echoes my disclaimer number one. From "Corporate Entity" by Jan Dejnožka: "It is usual to say that in studying philosophy of X, that we do best to acquire a pre-philosophical understanding of X before philosophizing about it. The more we know about X pre-philosophically, the better our philosophy of X will be."

The Savant Semantic Network Database

2007-09-21T22:35:00.005-04:00

Back in 1983, when "expert systems" where just starting to be all the rage, I had a contract (and was later hired as Chief Scientist) with a startup company that wanted to develop several microcomputer based "business" applications. I realized that they were all essentially database applications with a forms-centric user interface. [Mind you, this was back before there were real databases on PCs, and 80x24 color text was the state of the art for user interfaces.] I decided to build a general database and forms UI engine from scratch, and then quickly create the business apps (e.g. contacts, H/R data, calendar, memos, etc) using the engine. The engine eventually became a product in its own right and was dubbed Savant. Mark Wozinac (brother of the famous Woz) ran an early computer store in Silicon Valley and was an early enthusiast for the technology.

Having always been interested in AI and general knowledge representation, and with expert systems looking hot, I took a semantic networking approach. Savant had an interactive development mode where the user could move the cursor around the screen and dynamically define form fields, associating each field with an EAV (entity/attribute/value) data triple (way before the term EAV was widespread). The name of each form field was the "attribute", the value entered into the field was the "value", and the "entity" was the value of some other form field that the user specified. Savant let users create their app, complete with database, on the fly, with the form definitions stored in the same EAV database. I had some novel techniques to optimize the data retrieval (using my written from scratch B+/B* tree DB kernal). All this was written in UCSD Pascal (grandpa to Java) such that it ran on IBM PC, Radio Shack TRS80, Apple ][, and exotic 32-bit computers, and ran on FLOPPIES! Only shortly later, when Corvus hard drives for Apple ][ and the IBM XT came out, did it benefit from their size and speed. To UCSD's credit, I didn't really have to change any code.

One of my inspirations was to make a more intuitive approach for non-technical users than was required by a popular database of the day, pfs:File. It also let users create form screens and save the data from each screen into its own "table". I thought that it was too complicated to know which screen each bit of data you wanted was on, plus, you couldn't share data between screens! My goal was to have all data available from all screens/forms without having to know about tables and schemas. One would just design forms and the data would magically go to the right place.

The other day, I stumbled across, MindModel, a product that looks very similar to Savant (except its written for the new-fangled graphic user interface :-) It also looks like it may have the same fatal flaw that my system had. Namely, Savant didn't (because I didn't) understand that the value of a "name" attribute of an entity is not the same thing as the entity itself (nor is it a key). E.G. (JoeSmith,phone#,123-456-7890) does not represent the same information as (key123,name,JoeSmith) plus (key123,phone#,123-456-7890). So, if you change JoeSmith to JoeBlow, you either lose the association with other attributes tied to JoeSmith, or you must remap them all. So, Savant changed all the JoeSmith references to JoeBlow in all triples, but then what to do about the phone number changing? If you change all 123-456-7890 references to 321-654-9999, you have not only changed JoeSmith's phone number but anyone else who shared that number. In other words, it didn't really understand the concepts of entity and attribute.

I see the same fuzzy understanding of entities and attributes in many articles about the Semantic Web and how easy it is to encode data such that any lay person can do it intuitively. They show the same (JoeSmith,phone#,123-456-7890) flavor examples. We all need more basic metaphysics and ontology training in grade school!

POSTSCRIPT - April 21st, 2010
How funny...I just stumbled upon an old blog post where someone had stumbled upon MindModel, and in their post they used the term "existential programming". http://caet.blogspot.com/2004/12/mindmodel-fascinating-easy-to-use-true.html with follow-up post http://caet.blogspot.com/2004/12/more-on-mindmodel.html

Quantum Math for Fuzzy Ontologies

2007-09-09T16:23:00.106-04:00

In my earlier post "Existential Programming as Quantum States", I mused that objects that were simultaneously carrying properties from multiple ontologies (i.e. multiple class hierarchies or data models), were like Quantum States in Quantum Physics. This led me later to wonder what math had been developed to work with quantum states...i.e. is there some sort of quantum algebra that might be applicable to Existential Programming? It is needed because, in Existential Programming, a property of an object might carry multiple conflicting values simultaneously, each with varying degrees of certainty or confidence or error margins.

I found Wikipedia page on Quantum-indeterminacy which looks applicable.

Quantum indeterminacy can be quantitatively characterized by a probability distribution on the set of outcomes of measurements of an observable. The distribution is uniquely determined by the system state, and moreover quantum mechanics provides a recipe for calculating this probability distribution.

Indeterminacy in measurement was not an innovation of quantum mechanics, since it had been established early on by experimentalists that errors in measurement may lead to indeterminate outcomes. However, by the later half of the eighteenth century, measurement errors were well understood and it was known that they could either be reduced by better equipment or accounted for by statistical error models. In quantum mechanics, however, indeterminacy is of a much more fundamental nature, having nothing to do with errors or disturbance.

AHA! It dawns on me that going beyond the mere fuzzy logic idea of values having a probability or certainty factor, Existential Programming could have a fuzziness value for the property as a whole...as in "it is not certain that this property even applies to this object"...and even further it could mean "it is not certain that this property even applies to the entire Class". A FUZZY ONTOLOGY: method of associating attributes/relationships with entities where each entity is not conclusively known. The value of a property may be certain (i.e. not vague or probabilistic), but whether that property belongs to this object is fuzzy.

Why would you want that ability? How about data mining web pages where several people's names and a single birth-date (or phone number, address, etc) are found. Even though it isn't known which person's name is associated with the birthday, one could associate the birth-date with each person with some fractional probability. With enough out of focus wisps of data like this, from many web pages, the confidence factor of the right birthdate with the right person would rise to the top of the list of all possible dates (analogous to the way that very long range telescopes must accumulate lots of individual, seemingly random, photons to build up a picture of the stars/galaxies being imaged). The fractional probability assigned could be calculated with heuristics like "lexical-distance-between-age-and-name is proportional to the probability assigned". This could make the "value" of a scalar property (like birth-date), in reality, the summarization of a complete histogram of values-by-source-web-pages.

POSTSCRIPT - May 21st, 2010

Came up with another AHA this AM that I later found in a French university's academic journal. I had the bright idea of "fuzzy frames" and sure enough later found "A theory of Fuzzy Frames" here...
http://www.listic.univ-savoie.org/modules.php?name=Busefal&func=AfficherVolume&no_volume=31

I am not sure it is exactly the same since I was thinking of applying neural net type "learning" (of the sort used to recognize handwriting) on semantic network relations. The inspiration was the problem of how to handle all the variations on a "restaurant scenario" frame (see original Schank book).

Fuzzy Unit Testing, Performance Unit Testing

2007-08-31T14:35:00.090-04:00

In reading Philosophy 101, about Truth with a capital "T", and the non-traditional logics that use new notions of truth, we of course arrive at Fuzzy Logic with its departure from simple binary true/false values, and embrace of an arbitrarily wide range of values in between.

Contemplating this gave me a small AHA moment: Unit Testing is an area where there is an implicit assumption that "Test Passes" has either a true or false value. How about Fuzzy Unit Testing where there is some numeric value in the 0...1 range which reports a degree of pass/fail-ness? i.e. a percentage pass/fail for each test. For example, testing algorithms that predict something could be given a percentage pass/fail based on how well the prediction matched the actual value. Stock market predictions, bank customer credit default prediction, etc come to mind. This sort of testing of predictions about future defaults (i.e. credit grades) is just the sort of thing that the BASEL II accords are forcing banks to start doing.

Another great idea (if I do say so myself) that I had a few years ago was the notion that there is extra meta-data that could/should be gathered as a part of running unit test suites; specifically, the performance characteristics of each test run. The fact that a test still passes, but is 10 times slower than the previous test run, is a very important piece of information that we don't usually get. Archiving and reporting on this meta-data about each test run can give very interesting metrics on how the code changes are improving/degrading performance on various application features/behavior over time. I can now see that this comparative performance data would be a form of fuzzy testing.

Birth of a Blog

2007-08-26T19:09:00.003-04:00

On this date I had the blinding realization that after a year and a half of thinking and note scribbling about this thing I was calling Existential Programming, I should grab the domain name and start a blog to plant my flag on the name and topic. I had the thought while recording notes on the original ideas that led to Existential Programming...

Recalling the inspiration for Existential Programming, the concept

While working on a Javascript project in early 2006, I became aware of the differences between Java class-based objects and Javascript's prototype-based objects. I wanted to work with Java-like classes and researched existing attempts to implement them and what it would take to "do it right". In the course of comparing different attempts, I came across different definitions of "class".

Once I realized the ability to dynamically add and delete attributes of an object in Javascript, I realized that one could nicely map them onto semantic-network relations/tuples. I already knew about EAV database schemas. I had the epiphany that O/O and E/R and S/N modeling could all be made isomorphic once one had class-less objects as Javascript had.

Once I realized that classes were isomorphic to semantic networks, and having already known that computer ontologies were anything but universally agreed upon, I had the epiphany that OO class structures were too restrictive because they assume a single ontology. On the other hand, I did not want to give up the benefits of strong typing. So I had the idea that objects should be able to simultaneously house the attributes of multiple ontologies, and with class-less objects I could see how to implement the whole system.

Together, these trains of thought somehow gave rise to the intuition "I'll bet people have already thought about this...like maybe in Philosophy?". I quickly discovered it had everything to do with this topic. And once I found out what Existentialism was, it became clear that class-less objects have the same deep idea.

So, I coined the term "Existential Programming" to refer to the whole "project" of exploiting type-less objects to implement multiple strong types simultaneously.

Which came first - the Chip or the Socket?

2007-08-26T17:54:00.019-04:00

Q: Which came first, the integrated circuit chip, or the socket into which it fits?

A: The socket came first (at least conceptually). Before a chip is designed, there is a framework defined into which the chip will integrate: Digital vs analog signals, voltage levels for digital one and digital zero, power requirements, clock rates, transistor type, etc. This usually results in the design of whole families of chips that are intended to work together.

SO, no chip is created in isolation, just as no software component should be. Otherwise, the result would be that there is no common framework with which other components can be attached (Super-glue, play-doh, and duct tape not withstanding).

Of course, as I wrote back in 2000, there is no such thing as a component (in the same way that there is no such thing as a donut hole).

Killer App of Existential Programming?

2007-08-12T17:31:00.000-04:00

Ok, with all this theorizing about "existential programming", what the heck is it good for?
I.E. What is the killer app of existential programming?

The answer could be "integration of uncooperating systems"...

Data Integration
Data Model (i.e. schema) Integration
Application Integration
Frameworks API Integration

By developing an information (code/data) environment where different paradigms can coexist without even being aware of each other, uncooperating systems can be mediated between that otherwise could not.

Things vs Stuff, Individuals vs Commodities

2007-07-28T17:55:00.002-04:00

In thinking about "what is a thing?", I had this brain fart about the dividing line between things that have an individual identity and "commodities" or "substances". That dividing line is between those things that are chosen or manipulated by "amounts" rather than "names". I.E. When you ask for X number of things (a dozen donuts), or Y ounces of stuff (an ounce of prevention ;-) (i.e. mass nouns), instead of asking for "that one" (i.e. using an indexical), you are referring to things that may actually exist as separate things (e.g. pork bellies, batteries, molecules) but they are so similar that we quit referring to individual ones as individuals. EVEN WHEN picking out a single screw from the basket of screws at the hardware store, it doesn't really have an individual identity! We picked "one", not "that one", much less "Joe".
In fact, to give "names" back to things that have become commodities, we resort to assigning serial numbers to make them each unique.

[Ed. Note - 11/21/07: as per my disclaimers, once I start looking for my epiphanies on the net, I find them. E.G. in this case, see "Conceiving of entities as objects and as stuff". Congrats Bruce, you've just discovered that there are mass nouns vs count nouns.]

POSTSCRIPT - >March 11th, 2010

It turns out that our notion of stuff versus things is so intuitive that they are already being processed by different brain parts during visual processing, long before making any "conscious" decision.

At http://www.journalofvision.org/4/8/510/
see Cant, J. S., Valyear, K. F., & Goodale, M. A. .. (2004). 'Stuff' versus 'things': Neural processing of the material properties and geometric form of objects in human visual pathways [Abstract].
Journal of Vision, 4(8):510, 510a, http://journalofvision.org/4/8/510/, doi:10.1167/4.8.510.

Different orders of Polymorphism

2007-06-11T21:05:00.001-04:00

When most computer science texts refer to polymorphism (in the context of object oriented programming) they are referring to either refining the implementation of a method via subclasses overriding that method, OR, by defining more than one behavior (method) with the same name. The former case (hopefully) preserves the semantics of the method name, the latter overloads multiple semantics on the same name. In either case, it is only the method that is multifaceted, not the entire object much less the class hierarchy.

With Existential Programming, a different order of polymorphism (i.e. "a single entity can take on multiple forms") is at work. Here a single entity in its entirety can take on multiple forms. Heck, it can take on multiple ontologies (aka class hierarchies). This means either supporting multiple (albeit, fundamentally similar) views/conceptions of an entity, OR, trying to knit together very different models where the object instance is in some sort of oscillating Schrodinger's Cat-like state (except that we can look at it and not affect its state :-).

Rationalism of the Semantic Web a Flaw?

2007-05-14T13:59:00.004-04:00

In thinking about how knowledge is represented in the real world, it occurs that, in addition to the traditional rational representation via human and formal languages, there are at least two other biggies: DNA and neural nets.

Many, if not all, of the things we learn are represented in our brains as complex networks of (mathematical) functions that are simulated in computers via the technique of neural networks. And, if you have ever looked at the data associated with a neural net that has been trained to, say, recognize a handwritten letter "A", you've seen how there isn't any way to put that knowledge into words. In fact, it is not clear by simply looking at a net's matrix of fuzzy weights that it knows anything at all, much less what it knows!

In a similar vein, DNA obviously encodes tremendous amounts of knowledge, like how to make a beating heart, that are also very hard to translate into explicit "facts". In fact, DNA, like self-modifying source code in Lisp, is hard to verbalize because what it "does" can be very far removed from what is "says".

Now because the whole theory and strategy of representing knowledge via "facts", whether in a traditional database, or a semantic network, assumes that everything can be put into a fact format, there are huge amounts of knowledge in the world that can't be used. Yes, one can simplistically use a BLOB to stuff anything reducible to a number string into a database tuple, but that doesn't really put the knowledge into a form that can be "reasoned" about via inferencing rules. And it is that sort of inferencing that is the rationale behind the Semantic Web and why we should bother to create it.

Is this a (fatal) flaw in the foundation of the Semantic Web? Many philosophers have claimed it is a fatal flaw in Rationalism which is the philosophical equivalent to semantic networks. Phenomenologists insisted that many other flavors of knowledge had to be handled beyond the ones covered in rationalism and logic. How will the semantic web handle these? Is it even possible philosophically?

== considered harmful

2007-05-14T10:36:00.004-04:00

Once one realizes that objects aren't entities, and that they very often are representations of real world things, one realizes that the "==" (equals) operator is dangerous!

As shown in the diagram below, it is quite possible that two different objects can represent the same real world thing, and the same object can, at different times, represent different things. Since "==" simply says that two different references to objects point to the same object, it has little to do with the references pointing to the same "thing".

What is the difference between an Ontology and a Taxonomy

2007-04-16T21:11:00.000-04:00

The following has been posted on a few sites and I don't know which was the original. In any event, it is very germane to my purpose, so I republish it here...

A controlled vocabulary is a list of terms that have been enumerated explicitly. This list is controlled by and is available from a controlled vocabulary registration authority. All terms in a controlled vocabulary should have an unambiguous, non-redundant definition. This is a design goal that may not be true in practice. It depends on how strict the controlled vocabulary registration authority is regarding registration of terms into a controlled vocabulary. At a minimum, the following two rules should be enforced:

If the same term is commonly used to mean different concepts in different contexts, then its name is explicitly qualified to resolve this ambiguity.
If multiple terms are used to mean the same thing, one of the terms is identified as the preferred term in the controlled vocabulary and the other terms are listed as synonyms or aliases.

A taxonomy is a collection of controlled vocabulary terms organized into a hierarchical structure. Each term in a taxonomy is in one or more parent-child relationships to other terms in the taxonomy. There may be different types of parent-child relationships in a taxonomy (e.g., whole-part, genus-species, type-instance), but good practice limits all parent-child relationships to a single parent to be of the same type. Some taxonomies allow poly-hierarchy, which means that a term can have multiple parents. This means that if a term appears in multiple places in a taxonomy, then it is the same term. Specifically, if a term has children in one place in a taxonomy, then it has the same children in every other place where it appears.

A thesaurus is a networked collection of controlled vocabulary terms. This means that a thesaurus uses associative relationships in addition to parent-child relationships. The expressiveness of the associative relationships in a thesaurus vary and can be as simple as "related to term" as in term A is related to term B.

People use the word ontology to mean different things, e.g. glossaries & data dictionaries, thesauri & taxonomies, schemas & data models, and formal ontologies & inference. A formal ontology is a controlled vocabulary expressed in an ontology representation language. This language has a grammar for using vocabulary terms to express something meaningful within a specified domain of interest. The grammar contains formal constraints (e.g., specifies what it means to be a well-formed statement, assertion, query, etc.) on how terms in the ontology's controlled vocabulary can be used together.

People make commitments to use a specific controlled vocabulary or ontology for a domain of interest. Enforcement of an ontology's grammar may be rigorous or lax. Frequently, the grammar for a "light-weight" ontology is not completely specified, i.e., it has implicit rules that are not explicitly documented.

A meta-model is an explicit model of the constructs and rules needed to build specific models within a domain of interest. A valid meta-model is an ontology, but not all ontologies are modeled explicitly as meta-models. A meta-model can be viewed from three different perspectives:

as a set of building blocks and rules used to build models
as a model of a domain of interest, and
as an instance of another model.

When comparing meta-models to ontologies, we are talking about meta-models as models (perspective 2).

Note: Meta-modeling as a domain of interest can have its own ontology. For example, the CDIF Family of Standards, which contains the CDIF Meta-meta-model along with rules for modeling and extensibility and transfer format, is such an ontology. When modelers use a modeling tool to construct models, they are making a commitment to use the ontology implemented in the modeling tool. This model making ontology is usually called a meta-model, with "model making" as its domain of interest.

Bottom line: Taxonomies and Thesauri may relate terms in a controlled vocabulary via parent-child and associative relationships, but do not contain explicit grammar rules to constrain how to use controlled vocabulary terms to express (model) something meaningful within a domain of interest. A meta-model is an ontology used by modelers. People make commitments to use a specific controlled vocabulary or ontology for a domain of interest.

Don't confuse (OOP) Objects with Entities

2007-04-13T18:44:00.003-04:00

AHA! (OOP language) Classes are too general to think of as synonymous with (Philosophical) Entities! OOP classes/objects can represent roles, or values of properties (e.g. Red), or PropertyTypes (e.g. Color), NONE OF WHICH are Entities. SO, the "isA" relationship between a superClass and its subClasses is not always analogous with the "isA" relationship between an Entity and the collection of Entities constituting an entityType.

"Red isA Color" is different than "Joe isA Human" or "Human isA Mammal". Red is not an entity, Joe is and a Human is. Why? Red is not countable and not distinguishable from another "instance" of red; Joe, humans, and mammals are. [Ed. note: this intuition will later be recognized as the problem of universals as the author reads more books. ;-) ]

With "domain objects" (aka "business objects") being roughly equivalent to philosophical entities, it is dawning on the IT industry (e.g. POJOs, "domain driven development") that there are at least 2 kinds of classes/objects: "domain" and "non-domain". There are wildly different ideas of what "non-domain" classes are, but they generally are meant to include all that programming implementation logic kind of stuff rather than the direct modeling of the world.

The main point here (and the AHA moment), is recognizing that lots of confusion about how to divide a problem into programming language classes (along with what logic goes into their "equals" methods) boils down to a lack of understanding about first philosophy concepts of entities, universals, etc. We programmers confuse the ability of programming languages to implement everything as a class/object with the idea that down deep everything is the same kind of thing.

Philosophy would say that red is fundamentally different than Fred, and both are fundamentally different than a "process" (i.e. an OO method) or an "event" (i.e. an OO "message").

"isA" and "asA" Relationships

2007-04-12T19:34:00.001-04:00

In modeling the world, (object-oriented, entity-relationship, etc), the emphasis has been on distinguishing between "is-a" relationships and "has-a" relationships. (human isA mammal, human hasA head) There is another fundamental relationship that is under-emphasized in modeling; namely, the "as-a" relationship. This is the relationship between an entity and a "role" that that entity can take on. Many putative "entities" (e.g. customer, employee, etc) are not really entities at all, but are "roles" that the actual entity (e.g. a person) can take on. [see a case study here]

Roles are often implemented as classes, and multiple-inheritance is used [or worse, lots of glue code is written] to gain the lexical convenience of referencing joe.employeeID and joe.resign() versus joe.employeeRole.getID() and joe.employeeRole.resign(). Of course, "static" classes can be used to encapsulate the role details resulting in AsEmployee(joe).resign() references.

THE PHILOSOPHERS' PROJECT

2007-03-27T01:00:00.004-04:00

Here is a bit of Philosophy jargon that will be new to programmers: "project". It may best be explained via this excerpt from the world-wide best selling book, Sophie's World...

THE PHILOSOPHER'S PROJECT

Here we are again! We'll go directly to today's lesson without detours around white rabbits and the like.

I'll outline very broadly the way people have thought about philosophy, from the ancient Greeks right up to our own day. But we'll take things in their correct order.

Since some philosophers lived in a different age--and perhaps in a completely different culture from ours--it is a good idea to try and see what each philosopher's project is. By this I mean that we must try to grasp precisely what it is that each particular philosopher is especially concerned with finding out. One philosopher might want to know how plants and animals came into being. Another might want to know whether there is a God or whether man has an immortal soul.

Once we have determined what a particular philosopher's project is, it is easier to follow his line of thought, since no one philosopher concerns himself with the whole of philosophy.

Captain's Log: My (new) niche in the World

2007-02-12T12:55:00.003-05:00

Captain's Log, Lincoln's Birthday: After being absorbed in my new pastime these past several months trying to learn enough Philosophy to know whether it is worth learning at all to be of any practical use in my Software Engineering career, I have decided a decidedly *yes*. Not only is it worth continuing to pursue, it could well be my next career: Exploring and writing about the intersection between Philosophy and Computer Science. i.e. "Experimental Philosophy" or "Empirical Philosophy" or some such.
I can already see that Philosophy is a deep ocean to get drowned in; better to take on the much smaller pond that is cross-disciplinary studies. Nobody in mainstream computer programming is aware of this stuff! I know because I have a computer science degree and have been doing hands on development for 30+ years from the days of spaghetti code thru structured programming thru modular programing thru embedded programming thru object oriented programming thru distributed programming thru AJAX. I think I saw one article about Plato in CACM once. There is a book in this; dare I say a series? At the very least I ought to start a blog to put these notebook entries someplace in the meantime.

POSTSCRIPT - Aug 26th, 2007
Having made the decision to focus on practical programming tips based on basic ideas from Philosophy (as opposed to diving into the deep end of pure philosophy), I ironically find that "Pragmatism" is specifically American and so my pragmatic approach is apparently a foregone conclusion given my American birthright.

Identifying Ontologies with URIs

2007-02-01T16:52:00.001-05:00

As noted before in my original ephiphanies #10 & #15 and Level III Existential Programming, there should be a whole collection of meta-data around each "fact" documenting the source of that data, the time that data was acquired, etc, etc. This meta-data in effect constitutes an ontology definition; one per each different source/timestamp/etc. To be sure, these various ontologies are largely similar to each other and could benefit from an inheritance tree (ala OO class hierarchies).

In Java, such collections of definitions can be grouped into Packages. In XML, they can be grouped into Namespaces. So, a pragmatic way to factor out this metadata (such that it is not copied into every "fact"), is to give the ontology a name and tag each fact with that name (in the same way as each Java value is "tagged" with a data type that includes the Package name/path). And since, XML has already defined URIs as the format for namespace identifiers, and it is easy to map Package names with URIs, Existential Programming systems/languages could use URIs to identify the ontology associated with some set of facts. Since Existential Programming systems seek to seamlessly convert between an O/O and an E/R and an S/N representation, having OO packages easily mappable to data exchange mechanisms like XML is a good thing.

POSTSCRIPT - Nov 23rd, 2007
It is hard to tell which of my epiphanies are new and which are things I read long ago but later remembered as if they were a new idea...I'm sure I read this URI stuff in the Semantic Web articles (see Principle #1), but only "remembered" it when stumbling back across it today. At any rate, it was only recently that Tim Berners-Lee wrote this post about Linked Data using URIs.

Imaginary Numbers paradigm for Existential Programming

2007-01-21T22:18:00.000-05:00

It occurs to me that one of the things that Existential Programming hopes to enable is the ability to continue working with data that is vague, fuzzy, semi-inconsistent instead of screeching to a halt as would be the case with a strongly-typed implementation of a single ontology.

An analog to this is the invention (discovery?) of Imaginary Numbers in mathematics. The imaginary number "i" is defined to be the square root of -1. Now the mildly mathematical reader will note that you can't have a square root of a negative number because any time you square a number it is always positive. So, when early mathematicians came to a point in their formulas where a square root of a negative number was required, they were stuck. By creating a way to talk about and manipulate numbers that "can't exist" (i.e. imaginary numbers), formulas could be worked through such that "real" answers could eventually emerge.

By developing techniques to work with data that is not consistent with a single ontology (i.e. existential programming), programs can get past the "thats not legal data" stage and work its way to answers that ultimately do result in "legal data".