Ambiguity near and far
In Dreaming in Code I wrote a lot about the difference between ambiguity in programming, where it is often a source of trouble, and in “natural” languages (i.e., English or French or Mandarin), where it is often a source of value.
Jason Kottke points to this fascinating essay by Perl creator Larry Wall, in which Wall distinguished between “local” and “distant” ambiguities:
People thrive on ambiguity, as long as it is quickly resolved. Generally, within a natural language, ambiguity is resolved rapidly using recently spoken words and topics. Pronouns like “it” refer to things that are close by, syntactically speaking. Perl is full of little ambiguities that people never even notice because they’re resolved so rapidly. For instance, many terms and operators in Perl begin with identical characters. Perl resolves them based on whether it’s expecting to see a term or an operator, just as a person would. If you say 1 & 2, it knows that the & is a bitwise AND, but if you say &foo, it knows that you’re calling subroutine “foo”.
In contrast, many strongly typed languages have “distant” ambiguity. C++ is one of the worst in this respect, because you can look at a + b and have no idea at all what the + is doing, let alone where it’s defined. We send people to graduate school to learn to resolve distant ambiguities.
Wordyard RSS feed
May 7th, 2007 at 3:23 pm
This is well understood in programming languages. It’s called “context.” Programming languages are “context free” languages while natural languages are “context sensitive.” These are compiler grammar terms. C language may have started some of the problems you’ve described since it has very little in terms of functionality built in. Instead the creators of C chose to use an external “library” of functions unlike PL/I of the day. PL/I had many built in operations, including string and matrix functions. But the “context” you describe involves further, non-standard function and operation – external libraries which can vary from vendor to vendor and “house” to “house.”
May 7th, 2007 at 9:25 pm
Yeah, but having computing be able to resolve ambiguities as they operate is something programming languages don’t take into account. That’s something that will be required if the future of computing is to progress beyond what we have today. But this would make programming languages irrelevant. Personally, I think the notion of computers being able to recognise context to be extremely fascinating.
May 8th, 2007 at 1:47 pm
1980s GUIs were praised for being “modeless”, meaning that the user interface had no (or very few) sub-states. It was believed this was a good thing because icons and mouse actions would have a single & consistent meaning throughout the app. This is similar to the idea of a context-free grammar in a programming language.
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.
May 9th, 2007 at 2:16 pm
This is an important point for all programmers to think about. I think it related to a similar question of when it is better to make something explicit, as opposed to making it happen automatically. This is a similar to ambiguity, but perhaps better described as the “unspoken but understood” portion of a conversation, or programming language.
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.
May 28th, 2007 at 5:48 am
[...] Rosenberg’s post on ambiguity was right on. Ambiguity is a double edged sword – it can make things elegant, or intractable. [...]