Favorite phrases
Several months ago after a long talk with my advisor, he noted that it sounded like I had identified “my phrases”. And that each phrase should essentially become a paper, which in turn becomes a chapter. I forget exactly which phrases I mentioned in that conversation, but I thought I might try to recap that list.
Language Cacophany
The modern day Tower of Babel story. There seem to be more languages, not less. Every so often a new language will come around and there will be excitement within the community that finally we have the one language to end all languages. But it never happens.
Instead of working to make it happen, we should embrace this problem.
Tyranny of the Dominant Decomposition
This phrase is usually used as motivation for aspect oriented programming. Everyone who has worked in a team has experienced this. Someone else’s code isn’t exactly the way we would have written it. And even though we don’t want to change the behavior, per se, we often have an urge to phrase things differently. Many times this is more than an urge, and is actually a necessity to make certain kinds of changes and analysis tractable.
I think this phrase is a little too limited in scope, as I’ll explain later. It’s not just that the decomposition is tyrannical. The language plays a role in the tyranny as well.
Ontological Relativity
This title of a WVO Quine book caught my eye in a bookstore several years ago. I never read the whole thing (who reads entire Quine books?), but what I do remember was about the problem of learning a foreign language.
It gave several examples of what I think Wittgenstein was getting at when he said “The limits of your language are the limits of your world.” Acquiring a new language expands that perspective. But the process of acquisition must pass awkward stages of intermediate understanding where the new language is understood in terms of the old one.
The fact that language acquistion is a more difficult problem than simply mapping lexical elements and grammatical structures is known as ontological relativity. (If I understand it correctly.)
Language Oriented Programming
I first saw this phrase in Martin Fowler’s white paper from June ‘05. At first my reaction was “Oh,no, not another instance of ‘X-oriented programming’” But as I read what he (and Sergey Dmitriev) meant, I understood that this was a good label for what I’ve been working towards for many years.
I’ve been making lists of development tools on napkins and scraps of paper for years. Hoping that a pattern (and eventually a dissertation) would pop out. The pattern’s name is the “Language”, and I believe it is the single most important design pattern for anyone hoping to see the big picture of information systems. It is necessary to be this explicit about what a Language is if we are ever going to really make sense of the jumble of development tools: compilers, optimizers, editors, refactoring tools, source code control, debuggers, testers, and so on.
Linguists have always been much more explicit and declarative about languages. They often refer to a class of language as “scripty L” whose members are L_1, L_2, …, L_N. Where L_1 might be Spanish and the rest are the other Romance languages, which would make “scripty L” the class of Romance languages.
Have you ever seen java referred to with a single formal symbol? We often use “java” in prose. And sometimes we have something like a java.gg file to refer to the syntax of java. But the syntax is only a piece of what we mean by “language”.
Language oriented programming is the first time I’ve seen computer scientists embrace this notion. JetBrians has done a great job of applying this technique to real language like java. Intentional Software seems to be emphasizing langauges other than programming languages (though that’s just an impression I get). So far these are the only two groups actively working on this stuff that I’m aware of.
Symbolic Integration
This is probably my favorite phrase of them all. Though I can’t quite define it. It’s another phrase coined by Fowler in that June ‘05 paper.
As I understand it, it’s the ability of LOP to map a transformation in one language to a transformation in another. An example of what I think it means: Let’s say a company designs a language L for use by its business analysts. The code written in L is passed through a code generator to turn it into java. If the languages are “symbolically integrated”, then we can refactor (change variable names, inline/extract methods, and so on) in either language and see the corresponding changes in the other language. It also means that we can express new constraints in either language — such as a new coding convention — and automatically have that constraint enforced in the other language.
Without having experience working with the tools people are labelling as LOP tools, I can’t be sure to what extent that’s true. And I haven’t formalized this to the point where I know if this stuff is even tractable. But I feel that it should be possible, and from what I’ve seen of LOP, I think it is possible.
I’ll go out on a limb and off on a tangent a bit and say that I think “symbolic integration” is the key to understanding the tension between the “bottom up” and “top down” techniques in artificial intelligence. Neural networks and other connectionist strategies at some point always become terribly inefficient and unproductive. I think this is because the “higher” level or algebraic understanding of their dynamics is not “symbolically integrated” into the search. I think the phrase also sheds some light on why the connectionist solutions always seem too “brittle”. Such as when the problem description changes — it’s rarely the case that there’s a way for the connectionist solution to efficiently adapt to changes which seem very small in terms of the problem space. The only way to bring that efficiency to the low-level search is to “integrate” the higher level, algebraic problem space into the low-level fabric.
This year’s OOPSLA conference has the word coherence is its theme. I don’t think that particular word sheds a lot of light on the problem. I hope to see the Language pattern and something like “symbolic integration” play a central role in that discussion.
Relative Declarativity
This is my own phrase — we’ll see how long I stick with it. Most programmers will eventually run into the proverb “One man’s code is another man’s data” (no doubt a play on “one man’s garbage is another man’s treasure”). Programmers usually move toward playing with this boundary. This manifests itself as objects that have “execute” methods. The “data” essentially becomes an executable program.
We usually don’t think about the role that the language is playing. It’s all still “written in java” (or whatever) to some extent. But aren’t we also creating a new language? The reason it doesn’t seem like it is that we don’t have a new syntax. If we emphasize the use of the Language pattern, we can be explicit about it.
I believe this kind of thinking is what undergrad “formal languages” classes are trying to teach us. The equivalence of pushdown automata and CFG’s. Or of a 1-tape, 1-head Turing Machine and a 3-tape unidirectional, 2-head Turing Machine, with an alphabet of 7 symbols.
I need to say a little more about this one and maybe provide some examples in order to make it concrete. I’ll return to this point later or write another post in the future.
Posted by Adam Pingel @ September 15th, 2006 under Software Engineering.
Comments: none






Write a comment