Fabulous IT

I have had a feeling for quite some time now that something was wrong. For over two decades now I have been programming. Granted the types of programs I was writing in 1989 were quite trivial, mostly Commodore Basic. My first exposure to object oriented (OO) programming was PIL, an interpreted scripting language for the Pirch IRC client. It was around that time I also started tinkering with Javascript.

It wasn't until after I started college classes that I really worked extensively with OO programming, in fact by the time I started my undergraduate work that was the only style of programming taught to computer science majors aside from a semester in assembly. My program was even transitioning to Java which is an exculsively object oriented langague, as opposed to mixed languages like C++. I had some exposure to Lisp through my AI class and PERL. While I loved LISP, my real love has been PHP. PHP itself has become increasingly OO over the past two versions.

Some programmers take OO for granted. It is an established paradigm. What I have learned gradually over the past couple of years, but have only recently become aware of is how Object Oriented design fits into the bigger picture. This is something I am starting to come to terms with, but bit by bit it becomes more clear.

Douglas Crockford's Javascript: The Good Parts is another step towards this understanding. Javascript and object oriented Lisp have a lot in common. Though syntactically (and thus superficially) Javascript is more like C and thus also to an extent Java (of which it is an even more superficial namesake), it's concept of objects comes from Self and Scheme. Scheme is one of the two major Lisp variants.

Reading through Javascript: The Good Parts, I was reminded of another book I had read recently about, Common Lisp Object System (CLOS) which is an extention of Common Lisp, the other major variant of Lisp. The concepts raised in both books reminded me of Date's rants on oobject oriented programming versus the Relational Model.

The most striking conclusion that I can draw from all this information is that while there are things I like about OO, it is much less of a science and much more of a belief system. The prototyping variety of OO seems to be the more technically sound and correct way. While class-instance based OO is easier to grasp assuming one can settle on one implementation it imposes limitations that make sense, but the variations from language to language are arbitrary.

This makes modern OO, which is predominantly the class-inheritance variety, little more than a programmer religion. We make leaps of faith based on the models that seem "right". There is nothing inherently wrong with this, it is a humanistic approach. The important consideration is to be cognizent of the motivating factor. We embrace class-inheritance for the same reason we program in high level languages, it is a more conveneient way to comprehend.

As much as I rejected Date's notions early on, there are things he has to say about OO that make sense. The effectiveness and flexbility of the prototype approach to OO certainly seems to support to his arguments. This version eliminates many of the issues while making OO a more expressive. It does seem to make things more complicated, but in the case of Javascript this has a lot to do with the C like syntax.

The features of Javascript that fly in the face of class-inheritance OO are certainly tempting. They bring eligance to OO in different ways than the type-oriented approach I am working on. Hopefully as I get closer to implementation some new doors will open up.