Aug. 27, 2005 - Free but not rigorous

Warning: if you haven´t read my "Freedom languages" article this may not make much sense.  Hmm, skipping forward it may not make much sense if you have.  Perhaps I should have used MRML instead of HTMLJ

A famous old joke goes like this:

An astronomer, a physicist and a mathematician were holidaying in Scotland. Glancing from a train window, they observed a black sheep in the middle of a field.

 

"How interesting," observed the astronomer, "all Scottish sheep are black!"

 

To which the physicist responded, "No, no! Some Scottish sheep are black!"

 

The mathematician gazed heavenward in supplication, and then intoned, "In Scotland there exists at least one field, containing at least one sheep, at least one side of which is black."

I was reminded of this joke as I read through the responses to my recent article about "Freedom languages."  Excellent points were made (and some really lame ones) and a number of incorrect assertions on my part were picked apart.  In short, a lot of people had (I hope) a good time spitting in the general direction of the author and one another. 

What I came to realize as I observed the commotion is that when we discuss things as coders we use an amazingly broad range of rigor.  At times some of the discussions can be deeply formal.  In this case (although not on this site) they can go to the point of true mathematical rigor (lambda calculus).  At other times we talk about things at the highest levels of subjective impression and rely on reasoning by analogy (freedom versus safety). 

The result of this talking at multiple levels is that at times people engage in discussions that pass each other by without ever meeting in the middle as in this (made up) Carolian dialog:

Alice: "Have you seen the white rabbit?"

Mad Hatter (who has a very precise notion of whiteness): "If what you seek is white then it cannot be a rabbit."

Alice: "But of course it can I have just seen him go by."

White Rabbit (hopping up beside Alice): "No you must be mistaken for I have been with the white rabbit all day and he has not gone by me once."

Pulled in two directions

There is a reason that software engineers work at so many levels of abstraction at the same time; it is because we have to.  At the end of the day we are called on to convert the abstract notions of business into working programs.  We are the interface between meaning and action, between the vague and the concrete.  On its face this is an almost impossible task.  It is the task of the translator but with languages that are far from isomorphic and with books that have not yet been written.

It is not surprising, then, that people feel so strongly about programming languages.  They are our prime translation tool.  It is also not surprising that the languages themselves reflect different focuses and goals, often in very inconsistent ways.  They reflect the different levels at which we want to work and at which we want to abstract things. 

Because programming languages are at the bottom of the abstraction stack, there is a presumption that they should be very well suited to the application of mathematical (or at least scientific) rigor.  While this is true within a large number of domains, it is not a universal truism.  As the most basic example, the notion of "type" is an abstraction whose implementation and meaning is highly language dependent.  As a result, the application of a particular set of rules to a particular meaning of type (type system) intrinsically excludes other meanings of type and has implications for the expression of that language.

How is type different from language to language?  As an example, Ruby has multiple inheritance via mixins (given a particular meaning of multiple inheritance).  also supports multiple inheritance. "WHAT?" you say, "no it doesn´t."  Sure it does, via closures you can achieve the "same" meaning.  Java does not, but you can manually simulate it via inheritance with delegation (sort of).  Now, type in these contexts has the same meaning at one level of abstraction, but a different meaning at a more detailed level of abstraction. 

Can you apply rigor to types like these?  Well yes and no.  Since you can prove that complete static-type-safety can be achieved for certain polymorphic type systems via a Hindley-Milner inference algorithm (or similar), you can write a language that is 100% static-type-safe while still allowing a variety of polymorphic behaviors.  Will your meaning of "type" be the same as the meaning in the earlier examples?   No.  Will your language be able to do all the same things that can be done with those mentioned?  Yes, but then so can C and COBOL.  The question is never one of "can", it´s one of "how best", and "best" is not a very rigorous word by its nature.

I started this section as a discussion about being pulled in two directions, so let me return to that theme.  At the beginning I was talking in a very abstract language ("interface between meaning and action"), but I became increasingly specific.  This is the dilemma of talking about languages, the hierarchy of levels is so deep that it is nearly impossible to meaningfully address the topic at any one level.  The conversation can become muddled (as this one has).  Since passions are naturally high about languages this muddling can become extreme.

Language in the abstract

If it´s hard to talk about languages without spanning these gaps, the question naturally arises as to whether it is ever useful to discuss them at the high level of abstraction I used in my Freedom article.  There are those who feel that more rigor is always better and that working at higher levels of abstraction adds so much imprecision that it makes any meaningful discussion impossible.  My take is that this is flatly absurd and as a proof of this absurdity I refer that thinking back to itself: where is the rigorous proof that rigor is the only valid approach?

The value, I believe, in working at these levels of abstraction is that it allows you to have a conceptual framework by which to think about what you do.  These frameworks are universally wrong in multiple dimensions, but their utility is not in their completeness but in their clarity.  Removing my particular classifications  and acknowledging that some languages simply don´t fit in the model, the response I´ve gotten suggests to me that the idea of freedom versus safety, the framework itself, holds power in helping people think about what it means to work in the languages they are working in. 

The value then is in people working in Ruby becoming aware of the cost of their freedom.  It is also in people working in Java recognizing that they may need to work around the language to regain their freedom in some cases (and be willing to do so when necessary).  Finally, the value comes from encouraging people to take a deeper look at languages that they might never previously have considered using.  If it does the last of these then it was definitely a good thing, regardless of what language they finally choose to work in!