After a particularly humbling fight with the Xerces parser - trying to find a simple way of outputting the text of a tag and all tags contained therein - I had to think a little while about the ease of use of natural language interfaces and the difficulty in using artificial language interfaces.

Natural language interfaces are extremely simple to use. We know so many ways in which to derive meaning from a particular statement. Use of the ambient context of the statement implicitly. Standard rhetorical figures that form naturally to create new meanings around old ones. Rephrasing of the statement in similar forms. Just the many ways in which we can derive meaning from a word, just because it is a word of a particular kind. From nouns we can create an amazing number of different parts of speech through derivation from the noun. Our ability to derive meaning from letters, tokens, words, sentences, and conversations is extreme. The pipe dream of productivity tools is to create as rich a conversation using artificial languages.

Creating such a rich environment has so many aspects and for each of these aspects there seems to be a programming technology devoted to making that particular aspect appealing and straightforward.

• Object oriented programming is an attempt to reformulate imperative program instruction as world modeling.


• Intentional programmand and aspect oriented programming try to address the openness of natural world models in ways object oriented programming fails to.


• Template programming tries to add inflection and token derivation to the type system.


• The notion of mixins resembles aspects in the way it tries to open up class hierarchies, but has a data component, not just a program flow component.


• Real metalanguages would probably claim to attempt 'all of the above'

What I've yet to see native language support for is the promiscuity of natural language, when it comes to describing objects. When you talk about some object you adapt the understanding of the object on the fly. In a conversation it is you not the provider of the object who defines the properties and interface to the object, simply by describing them. Maybe you have to start with the description you've been given - but from that you can rapidly adapt your own description and work in terms of that instead.
The point compared to the mechanisms available is that the object remains of the original class, you're just creating a temporary interface appropriate to your situation.

Another related candidate for language innovation is 'code-free delegation' i.e. how to use stock implementations in interfaces.

The true metalanguages, and the low level text-based ones like perl, allow for something like this, but either they are not languages with rich libraries - which really defeats the purpose of something like this, or the feature is only available by accident and certainly not in a type strong fashion. The idea with an extension like this would exactly be to hang on to type strength but make crossing of type boundaries possible when needed.

The object way of doing that is to write an adapter class presenting your own interface which is then implemented in terms of the existing interface, but to write your adapter you typically have to aggregate the old object, and that then means you have to actually construct a new object which can be a time-consuming and not very on-the-fly experience.

What I'm looking for is the ability to specify - for a class already in existence - an interpretation which I guess would be the keyword used to describe it. It is basically an implicit adaptor created on the fly for another class. It cannot add data to the original class (that would just be aggregation) but only implement a new interface in terms of the old one.
This is sort of a backdoor into generics. You'd specify an interface for e.g. a containerclass, and then you would create an interpretation of an existing class to make the container hold the existing object.

An adaptor refactoring tool in a modern IDE could be the solution if done in proper two-way fashion.

It's clear that the only languages with any shot at resembling natural languages are the self-morphing text based or just very richly reflective languages. The problem with most of these is that keeping languages that open also means contracts can be hard to enforce, and you can't prove any kind of behaviour even with the sloppiest understanding of program proof without contracts of some kind. The type-system is of course the weakest type of contract and that is only enforced by a few of these languages.