Speaking my mind

Every so often I dig out my Xcode stuff and have a go at exploring developing an idea for Mac OS X. Everytime the same thing happens to me: Objective-C is such an offensive language to my sensibilities that I get diverted into doing something else.

All the lessons that we have learned the hard way over the years — the importance of strong static typing, the importance of tools for large scale programming — seem to have fallen on deaf ears in the Objective-C community. How long did it take to get garbage collection into the language? I also feel that some features of Objective-C represent an inherent security risk (in particular categories) that would make me very nervous to develop a serious application in it.

As it happens, I am currently developing a programming language for Complex Event Processing.
Almost every choice that I am making in that language is the opposite to the choice made for Objective-C — my language is strongly, statically typed; it is designed for parallel execution, it uses a functional programming foundation, it is symbolic in nature, designed to permit development of large programs, etc. etc.

Hence my allergic reaction and yet again I veer off into something that does not involve actually making a beautiful application for a platform that I much admire.

I have to also admit that I regret Apple’s choice to abandon Java development. I am not an apologist for Java, but it is significantly better for programming in than Objective-C.

I have heard that some of the features of Cocoa are impossible to do in Java. I have strong doubts about that.

I just wish that Apple’s sense of design extended to the underlying technologies as much as it does to user engineering.

Some time ago I was involved in a running debate about whether we should be using Ruby on Rails rather than the Java stack (junkyard?) that we were using. At the time, I did not really participate in the discussion except to note that everything seemed to be at least 5 times too difficult. I had this strong intuition that there were so many moving parts that that was the problem. The application itself was not really that hard. My assertions really ticked some of my colleagues off; for which I apologize; sort of.

I guess that I come from a tradition of high-level programming languages, by high level, I would say that I would consider LISP to be a medium level language, and Prolog is slightly better. I would say that it is a pretty common theme of my career that I end up having to defend the position of using high-level tools. I have gotten a number of arguments, ranging from “it will not be efficient enough” to “how do you expect to find enough XX programmers?”. I used to try to answer these questions, because I thought that they are raised in good faith. Most of them, with the possible exception of the last, have all but been made moot by progress in silicon and compiler technology.

Anyway, afterwards, I decided to take a more serious look at RoR. I picked up a book on it, and followed along. At the end of three days, I had managed to replicate perhaps 60-70% of the functionality of the site I had been working on; and I became furious.

If we had used RoR at the beginning, I began to think, it is entirely possible that I would still have a share in a company that was going to go places. Not that RoR is perfect; far from it. For example, when something goes wrong with your Ruby program a neophyte has very little support. And Ruby is a pretty weird language. But, to replicate 60% of an application that had taken 5 man years of developer effort in two days really pissed me off.

You see, one key reason that everything fell apart was that we had a competitor; a competitor who got out into the market before we did. It is hard to be sure, but we did not get the feeling that they had started before us even. What they did do was use a much easier to get going technology (PHP). So, maybe PHP does not scale; but so what? The first to market can gain enough time to re-implement should the idea prove sufficiently interesting.

So, the next time someone says that they can’t find programmers, or some other reason for not using advanced techniques; my response is likely to be more robust. If we need to train people, then so be it. Using technology that lets you get going quickly can make the difference between life or death for a startup.

I may even start pushing some of the languages that I have been involved in developing…

Rodney Brooks once wrote that robots would be human when treating them as though they were human was the most efficient way of interacting with them. (Not a precise quote.)

This is an interesting variation on the Turing test. It assumes that we decide the smartness of machines in the context of frequent interactions with them. It also builds on an interesting idea: that in order to deal with another entity, be it human, animal or mineral, we naturally build an internal model of the entity: how it behaves, what it can do, how it is likely to react to stimuli etc. That model exists for all entities that we interact with; a rock is not likely to kick you back, your word processor will likely crash before you can save the document etc.

When the most effective way to predict the behavior of a machine is to assume that it has similar internal structure to ourselves, then it will, for all intents and purposes, be human.

So, here is another thought: how do we know that another human is human? Although this sounds flippant, there are many instances where we forget that another person is a real person: soldiers must do this in order to carry out their job; terrorists must de-humanize their enemy in order to justify their atrocities.

I think that we only really recognize another person as human when we can relate personally to them. In most cases, what that means, is recognizing the other person’s behavior as symptomatic of something that we ourselves have experienced. In effect, the model building process consists largely of seeing someone’s reaction to an event and relating it to something that we ourselves have experienced. (An aside: how often, when told of some event or situation as it affects someone we know, do we react by quoting something from our own past/situation that somehow is analogous?)

At the heart of this phenomenon is something curious: conventionally, the Turing test is phrased in such a way as to decide whether the other entity is human or not. However, it may be more accurate to say that what we do everyday is try to decide if we ourselves could somehow be that other person (or entity) we are interacting with? Furthermore, it may be, that this emphasizing is only possible because fundamentally, we are all clones to 99.99%: we are all running the same operating system in our mind as it were. We can predict the other person’s responses because they could be our responses also.

What does this mean? Well, perhaps we need a new formulation of Turing’s test: an entity can be considered human if we believed that we would react the way that the entity reacts had we been that entity. Another consequence may be that machines may be smart and intelligent etc. but not human simply because the code that they run is not our code. A cultural difference between people and machines if you will.

I am probably not alone in visualizing Turing’s Universal Machine as a little animacule walking over a linear landscape of ones and zeros:

The great innovation of thinkers such as Turing and others was to reduce the complex world of algorithms and functions into something simple and elemental: all computable functions can be thought of as state machines operating over a large collection of ones and zeros, presence and absence.

There are arguably many differences between a Turing Universal Machine and a modern browser (quite apart from the fact that, being a Javascript interpreter makes a browser a TUM). But for me, one of the most striking differences is that where a TUM is an animacule in a universe of one and zeroes, the browser is an animacule in a universe of HTML, CSS, HTTP and so on.

The browser understands a different world than Turing’s computer. Were we to draw a browser as an animacule, it should look like:

There are similarities, and if you were to look at it from the perspective of a binary TUM, you would be hard put to see a significant difference between a browser and a regular TUM. But that would be missing an essential difference.

The browser understands a different world than the TUM because the concepts that underlie its state machine are concepts from the world of the web, not the world of ones and zeros. Its semantic engagement with the world is different; arguably higher level than the binary TUM. The browser stands on the shoulders of the binary TUM, but nevertheless reaches higher.

What, one may ask, would the level above the browser’s level look like? And is there an infinite stack of levels waiting for our discovery?

I have previously wondered out loud what ontologies are good for. I now believe that one of the most powerful use cases for semantic technology lies in social networking applications; and matching in general.

By social networking I mean “putting people in touch with each other”; especially in situations that are inherently asymmetric. For example, putting potential volunteers in touch with people who could use their services; putting buyers in touch with sellers, and so on.

The reason is simple: the language spoken by the two sides is inherently different: a seller or volunteer knows a lot (or maybe not) about what he or she can do or would like to do. But a consumer often does not know to translate his or her problem into a solution that the provider can offer.

Put more graphically, providers speak features, and consumers speak problems. This is even if they can find each other.

In the middle, there is an opportunity for someone to put the two together. A match maker has to be able to put the right provider in touch with the right consumer; in a sense that is the measure of the quality of the match maker.

The more that a match maker knows about the domain, the range of things being offered and consumed, the easier it is for the match maker to do a good job.

Enter the Ontology: in a modern social networking application, the domain knowledge of the match maker can be encoded and used as the underlying basis for performing matches.

This is, in my view, a killer application for semantic web technology.

One of the questions that comes up from time to time is how to define your services. This has come up for me in two independent fora: within the OASIS Service Oriented Architecture work and in the context of human provided services, for example at Genietown.

In the work on the SOA Reference Model we decided that “services are the mechanism by which needs and capabilities are brought together”; i.e., its about needs and capabilities to satisfy those needs, and the access mechanism.

However, this still begs the question somewhat. In the domain of human services, where the services are things like “building a home”, “walking the dog”, “taking care of my elderly parents”; it gets even fuzzier. Sometimes a service seems to organized around the person offering the service, for example, an architect, or a doctor. Sometimes the service is organized around a particular kind of product, such as doors or skylights. At other times, the service is organized around a material, such as glazing and paint services. Another kind of organizing principle is location; for example, landscape services involve a whole range of things in the garden.

While it is clear that a service is typically organized around a set of actions, and one or more resources; I do not believe that there is a single ’syntactic’ condition that can be applied to define a service.

Currently, we do not have a good higher-level handle on how to organize a large suite of resources and actions into well differentiated services. The standard technologist’s answer to all this is to throw the problem ‘upstairs’ and appeal to business function (e.g., accounts, sales, library book management etc.). What that amounts to is asking someone else to come up with the organizing principles for defining a service. It may just be that the business level is the right level to ask these questions.

As any software engineer will know, it is often easier and better to design a system that is too general for the particular task at hand and then to govern the actual behavior with a parameter. At one extreme you get sort functions with the comparator supplied as a parameter to the sort. At the other extreme you get entire policy-based frameworks where the parameters that govern the system are represented as rules.

A similar phenomenon occurs in mathematics: it is often simpler to solve a more general problem than to solve the particular problem. The more general solution is often parameterized in such a way that the particular solution falls out of the general case.

Recently, I learned of a use that Nature has put to the parameter, it seems that Finches’ beaks may also be governed by one or two genes (BMP4) which show up in many wildly different animals (Finches, fish, butterflies, …). I would suggest that what is going on here is that we have a general mechanism (the HOX genes) with a system of parameterization that is easily modified.

There seems to be a general principle at work here — that the pattern of having a general mechanism tied to a parameter to give particular instances — applies to many things and in many areas of the world. Perhaps this is one of those natural joints that philosophers love to carve.

Perhaps a Math grad student would be interested in designing an algebra of parameters?

An age ago there was a time when the solution was “meta-level”, and “What was your question?” This was during the heyday of Logic Programming when it seemed that we were going to take over the world (when they woke up to it that is).

Meta-programming is extremely powerful, and it seemed that there was nothing that could not be solved using some kind of meta-level approach: compilers, debuggers, abstract interpretation, program transformation, utility programming; the list had no end.

Unfortunately there were, and are, some problems with meta-level programming. From a logic perspective a key problem was that you had to prove, again, the logical validity of the meta-level inferences that you made in your application. More pragmatically, there were issues with the ’standard’ way of reflecting from logical formulae to data structures in Prolog that caused logical and practical problems.

Like most Prolog-ers, I have been somewhat amused by the apparent enthusiasm for all things meta in the Java world. It has had a distinct been-there-done-that kind of feel about it.

Recently I came across one of the down-sides of the meta-fever. Wicket uses a lot of reflection to simplify programmers’ tasks. However, the down-side is that using a string to denote a method confuses most IDEs; making refactoring a tricky proposition.

Today, in our telcon we invented something. It is not often that we can claim that; but today we did.

There are, it sometimes seems, people who think that everything is an event. There are others (including a lot of philosophers) who think everything is an action. (Well, everything that people are involved with anyway.)

Well, they are wrong.

In human communication, the only way of getting someone to understand something you want them to is by saying something to them: by performing one or more speech actions. In the SOA we interpret this by committing to a view that participants in a service interaction denote the actions to be performed by exchanging messages. I.e., an appropriately formatted message that is effectively communicated between participants counts as an effort to perform an action.

But, not all messages encode actions. Some encode events. For us, an event can be defined as something that happened that someone has an interest in. We can encode a description of an event as a message, in exactly the same way that an action can be so encoded.

So, what is the relationship between events and actions?

If you look at the message that denotes the action, you can call it an event (the event is the performing of the action). On the other hand, traditional speech act theory would encode an event as a speech action: an inform of the change.

Personally, I do not like the smushing together of events and actions in this way: each is a first class idea, not to be subordinated by the other. But they do seem to be very closely connected; almost two sides of a coin — a yin to a yang.

So, we now have two fundamental ‘things’ being communicated: actions and events. Incidentally, an event can be used to communicate a real world effect - one of the cornerstones of the SOA Reference Model. And that is our invention for today.

I have had reason to look at the job boards recently. I am struck by something: nearly all the jobs in the IT industry have a sameness to them: there is some list of acronyms that you are supposed to have had x years of experience with (sometimes x is longer than the technology has been available) and apply those acronyms to the job at hand.

There is very little room, it seems to me, for someone who has a deeper experience but who does not fit into the cookie mould.

There are several unfortunate consequences of this (apart from the obvious one): any business that seeks to differentiate themselves from the competition cannot do so effectively if they slavishly follow the deeply rutted road trod by those before them; and some of the hardest problems in the Industry have nothing to do with applying the latest technology to yesterday’s problems.

One thing that I have learned in life (here he puts on his tri-cornered hat) is that there is always someone who will be faster than you, and there will also be people who are slower than you. Instead of trying to win the race, it might be better to think more carefully about what you really need.

It is also true that what you need may not be what is on offer at the local store.

But, it seems to me, the biggest problem in the IT industry is the relationship with its customers: the business community (shorthand for anyone who needs computers to do their work).

The gap between IT and business is famous; famously difficult and famously wide. Yet, you very rarely see ‘able to cross the divide between IT and business’ on a job listing; even on senior ones. That takes something other than acronym soup.