A rose is a rose is (not) a rose

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

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?

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