Showing posts with label introduction. Show all posts
Showing posts with label introduction. Show all posts

Saturday, February 2, 2013

What is Philosophy?

Because I am endeavoring to teach ideas from Philosophy to computer programmers, who typically have no background in it, a question I must answer right off the bat is "what IS philosophy?"  Here is the answer I provided to a new MOOC "Introduction to Philosophy":
Given that the single word "philosophy" is commonly used to refer to multiple different (albeit related) things, all answers to the question "Q: What is [Western] Philosophy?" actually depend on one: "doing philosophy; the act of philosophizing" which I explain to even children as:
A: Being able to answer the question, Why do you think what you think? Why do you believe what you believe?
And while you want to be able to answer to someone else's satisfaction, you foremost want to be able to answer to your own satisfaction because you want to know the truth. (BTW, the western bit is "we believe humans are capable of working it out ourselves")
All the other things the word philosophy can refer to build on, and depend on, the above. e.g. Philosophy as meaning "the body of knowledge accumulated by those doing philosophy" (which entails history of philosophy, individual ideas, individual philosophers, tools/techniques/criteria for doing it well, favorite topics for philosophizing about, etc, etc) all naturally spring from someone somewhere starting to "do philosophy".

Of course for programmers who will say, "so what does that have to do with me?", I have to quickly add that even thousands of years ago, philosophers already had come up with some really good techniques for describing the world, and being able to justify that those techniques were better than our intuition.  So, since a large portion of our work as programmers is to describe the world via our data models, object models, class hierarchies, classification schemes, etc, etc, we would get better at it if we replaced our intuition with techniques philosophers know but we typically havent been taught.

Tuesday, April 13, 2010

Do Objects Have Souls?

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.

Thursday, May 28, 2009

XistP is the abbreviation for Existential Programming

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.

Sunday, December 2, 2007

Cubist Programming?

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!

Wednesday, September 26, 2007

Introduction to Existential Programming Blog

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

Sunday, August 26, 2007

Birth of a Blog

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.

Sunday, August 12, 2007

Killer App of Existential Programming?

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.

Monday, February 12, 2007

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

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.

Thursday, April 13, 2006

Do Objects Have Souls?

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. In trying to understand the 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.