The Magical Power of Statues

Many moons ago, in a time when the Internet was still not unindated in the Eternal September we find ourselves in today, I was an ancient historian. And the issue that fascinated me was why do we believe what we do. Why do we create the mental models we use to live our daily lives. Why do we believe in things like The State, God, Money, Civilization, Race, Class, and Magic. When you come right down to it, these have all been historically really useful fictions. Even to this day, large numbers of people part with vast quantities of funnily colored paper in the hopes that some charlatan can perform some ritual which will solve a problem. And I am not just talking organized religion here. I am talking about every cool fad that hits, every new panacea, every new programming language or framework.

Magical thinking was the topic of my masters thesis on the Byzantine Christian attitudes towards the magical properties ascribed to certain great works of Roman artwork. Even 800 years after the birth of Christ, 350 years after the fall of Rome, most Christians believed that the old gods still had power and would be dangerous to cross. The literature is never terribly clear on the differences between gods, demons, angels, anima, pnuema, and a host of other imaginary beings that occupied the mental model of the Medieval mind. It isn't until the Enlightenment and the subsequent Inquisition that occultists formalize the nomenclature and actual dogma gives any definitiveness to these terms. But the country folk, the paganus, still held on to the memories in some syncretic fusion of Roman, Catholic, German, Pict, Gaelic, Dacian, Egyptian, Judeo-Christian mysticism.

We see the same behavior among programmers, their schools of thought, and the magical thinking they use to justify which clan, tribe, or guild they associate with. Terms which seem like a desirable or good idea like Object Oriented get mutated and morphed as people try to redefine it to conform to their traditions, ignoring the fact the guy who came up with the concept is not just still alive, programming, and kindly answering emails. It isn't like Alan hasn't written extensively on what he meant, except since what he meant doesn't fit an Algol in funny hats idiom it gets ignored by those who like wearing funny hats. You can see this syndrome in the Android API, where because Java isn't really object oriented, you have Handlers, Loopers, Threads, and Message objects with which you can build rudimentary support for message passing objects on top of the library layer in application space. Since there is no notion of "doesNotUnderstand" in Java, and method calls to non-existent methods throw fatal exceptions in dalvik, there's no safe way to implement true message passing even with reflection.

But in spite or in ignorance, we also find immense amounts of literature on OO programming in Java. We educate the young in the traditions and indoctrinate them in the belief that they are doing OO in java. We then have programmers who try to write Java-style OO in JavaScript. Javascript's prototypal object model is based on a pure message passing language, Self. Self is a work of beauty, and one of my favorite environments to hack in. It is OO done right. All computation is a product of mesage sends, and all entities are objects, including blocks of code. There is also a distributed version of the language which allows passing messages between objects on different machines. In effect, a single idiom captures all of the modeled behavior, and implicitly prohibits direct modification of another value's internal state. Encapsulation is a strong property of the language, and not a compile time check hacked on by the compiler.

Conversely, self uses message passing to simulate direct manipulation of the objects themselves. Since all behavior is driven by message passing sending the message 'click' to an object would execute it's click behavior. A mouse object could be simply modeled as an objectthat sends click to what ever object's bounding box intersects the pointer. Not additional layers of handlers, queues, messaging subsystems, and dispatch handlers need be introduced. Same can be said for just about any object. You can do something similar in JavaScript,but it requires extending the base language. For example, you can make all of your objects of type function, and make them take a string first argument as their parameter. This parameter is consumed and applied as a method invocation on a named property of the same name, applying that named method to the function object itself in addition to any remaining arguments. You can then have each method be a closure which returns the object itself and chain a bunch of such calls in adjacent () invoking the functional return value as an explicit chain of invocation.

Needless to say such linguistic gymnastics are unnecessary in languages which are properly OO with message passing as the means of computation.