About the right tools for the job

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…

The humble parameter

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?

The Perils of Meta

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.

The mind body problem

Just started reading a book: Mind in a physical world. About the mind-body problem.

I cannot imagine any experienced programmer having a problem with the mind-body relationship. Especially any programmer that is familiar with assembler programming. The instruction

in A,$24

(from about x-ty years ago:) together with the complementary

out $26,A

would surely put at rest any issue with the relationship between the mind and the body.

Perhaps I am missing something. I will read and find out…

What is an Ontology for?

I am sure that everyone who has ever dabbled in the area of Ontology has been asked that question. Personally, I have never heard a truly convincing response; even though I strongly feel that Ontologies are quite important.

I recently listened to a radio segment in which someone in Algeria (I think) was complaining about the new law that required all teaching to be done in Arabic. It seems that most university-level education is in French, and that many parents try to send their kids to schools that teach in French. The issue was that Arabic simply does not have the vocabulary demanded by a modern high-tech education.

Arabic is not alone in this dilemma: French itself is littered with Les mots Anglais; and English is a true hodge-podge of Anglo-Saxon, French, German, Hindu, Japanese, and many other languages. It often happens that when a culture acquires a set of concepts, it does so in the language of the originators of those concepts. It is often considerably easier to import wholesale a set of concepts (a.k.a. an Ontology) than to laboriously map each term into one’s own language; often inventing new words just for the sake of it.

So here it is, modern Ontology languages are tools for capturing a collection of concepts that form a coherent whole. With an ontology you can make sense of something, even to the point of making a living at it; without it you are literally lost for words.

What does that mean? When do you know that you have one of these coherent wholes? Is it useful to be coherent?

I think two concepts are important here: closure and prediction.

A set of concepts (a.k.a. paradigm) is coherent when it is closed under the ‘idea completion’ mapping. This totally new concept refers to what happens when you take an idea and push it a bit. For example, in the world of plumbing, you have copper pipes (and iron pipes), solder, fittings, faucets, etc. etc. The set of plumber’s concepts is closed under the transformations implied by the requirements of moving hot and cold water around the house.

The second concept that is important is prediction. In the case of our plumber’s jargon, you can be fairly sure that the problems and the tools you encounter in installing central heating will all have a name. The language of plumbing is at least as important to a plumber as is the wrench and the soldered t-connector; because the language frames the problems as well as the solutions to those problems.

Ontology has its own ontology (it’s called eating your own dog food). In this case it is possible to ask if an ontology is consistent, open world or closed world, based on OWL or Common Logic (or Prolog). We also need words and more formal tools to capture the notions of closure and predictiveness.