I once had to spend half an hour exploring a C++ program to find the real code – it was buried in a constructor of a superclass of a superclass of an object which got instantiated in a one line main method. The object had many superclasses thanks to multiple-inheritance, and finding it was a real chore. In this case, the meat of the program was defined in an unspoken, ‘distant’ way.

But there are times when you want a framework to do things automatically, like breaking HTML form data into an easier to manager data structure, without having to clutter your code with lots of identical explicit calls. The unspoken idea is “near” in this case (it is part of a commonly used and repeated process).

When having a conversation with a person, it is usually possible to resolve ambiguities and reveal unspoken ideas. With contemporary computing systems, the ambiguous and the unspoken are very difficult to resolve. It seems like we should only use them sparingly, when they are “near”. (And even then we need to document them extensively.)

P.S. Cleo, I think you’re on to something. The question of context and ambiguity is potentially one of the few really interesting areas of CS left. If only we were better at it, I wouldn’t get so much spam.

Now we’ve moved the other way. Inductive GUIs (like Microsoft Money) have loads of sub-states, and even buttons labelled “Do it”, which only make sense within the context of that sub-state.

Ruby has a nice “near” ambiguity where you don’t need a return statement in a function. The value of the last statement executed becomes implicitly the method’s return value.