language parallax

A few weeks ago I noticed a new blog entry about the MIT Technology Review cover story, Anything You Can Do, I Can Do Meta

I thought I might pick out a few choice quotes and a few comments of my own:

He even has a name for his favorite gambit: he calls it “going meta.”

The idea of “meta” is one I’ve seen often in programming circles. It is a useful notion. Ultimately, though, I’d like to see this tied to other attempts to “go meta” — like the fields of linguistics and psychology. Especially his oft-repeated idea about “degrees of freedom”, which is a central concept in the study of any formal grammar. I can’t claim to be much of a real linguist myself, but after exposure to some formal study of grammar, I recognize a lot of the concepts.

Check out this fun passage from the article:

In the corner of the left-hand screen, a goggle-eyed paper clip popped up: the widely reviled “Office Assistant” that Microsoft introduced in 1997. Simonyi tried to ignore the cartoon aide’s antic fidgeting, but he was stymied. “Nothing is working,” he sighed. “That’s because Clippy is giving me some help.”

I was puzzled. “You mean you haven’t turned Clippy off?” Long ago, I’d hunted through Office’s menus and checked whichever box was required to throttle the annoying anthropomorph once and for all.

“I don’t know how,” Simonyi admitted, with a little laugh that seemed to say, Yes, I know, isn’t it ironic?

Here the author does a good job describing the accumulated artifacts of several decades worth of effort:

Ever since programmers stopped memorizing the opcodes that Simonyi used in his youth, they have been layering new abstractions upon older abstractions. Every generation of programmers uses its era’s programming languages and tools to build the programs of the next generation. Layers of abstraction have accumulated like geological strata. Messages are constantly racing up from the binary bedrock of your machine and back down again, making it possible for a mouse-click to accomplish its function. Your mouse-click triggers some code in the operating system, which sends a message to the word processing program, which instructs the operating system to save your file to a hard drive. But that apparently simple process is possible only because of many, many layers of abstraction.

This came up during a class I was taking with Dr. Alan Kay two years ago — where we spent a lot of time talking about the $100 laptop project. When faced with such a difficult financial constraint, you have to start whittling away at the underlying costs. The battery, the screen and so on. But what about the CPU? We’ve been able to ride the wave of the “Moore’s Law” and get away with the bloat that comes with layering abstraction upon abstraction. But when trying to produce a serious machine for cheap, you have to wonder what is it about today’s software engineering practices that has led us the point where the applications that run on today’s multi-core cpu’s are arguably only marginally more functional that those that ran on the old 8086’s.

I don’t know much about the architecture of PDA’s and phones, but it does seem to me that there is an awful lot of reinventing the wheel going on in that space. New operating systems, application frameworks, and even languages are being invented especially for those devices. Is that absolutely necessary? The same goes for game consoles. Most people I know who work with either type of platform express dissatisfaction with the amount of work that has to be redone in order to support development… and that it never comes out perfect in the first version.

The article describes how the idea of the “Language” plays a central role in Simonyi’s new system:

Intentional Software’s strategy borrows from a trend in programming known as “domain-specific languages” or DSLs–little programming dialects tuned to the needs of specific disciplines. Simonyi praises DSLs but says they don’t go far enough. They’re hard to create and therefore costly; you end up needing more than one (for a medical billing system, you’d need at least a medical and a financial language); and they’re incompatible with one another. Intentional Software’s system is like a factory for multiple DSLs that can talk to one another.

What does “talk to one another” mean? I believe this is what Martin Fowler was calling “symbolic integration”. Is there a formal definition somewhere?

Speaking of Fowler, he wrote that article that introduced me to the idea of “symbolic integration” in June ‘05. How has his relationshiop with Simonyi been developing?:

“I’ve felt some frustration that we haven’t got something we can actually use in production yet,” says Martin Fowler, chief scientist at ThoughtWorks. “Charles doesn’t seem to be in a hell of a hurry to ship. But one thing to bear in mind is that he has shipped things in the past–quite dramatic things, with Office.”

In a way it’s nice to see that he’s taking the time to think this through. Though the field is going to be crowded in a few years, and he may at some point soon get some pressure to nail things down and make them more public.

Now the criticisms of the technology:

Intentional Software’s work provokes two main lines of criticism. Some theoretically minded skeptics say Simonyi’s goal of capturing computer users’ intentions is implausible. “How do you represent intent?” asks computer scientist Jaron Lanier. “As soon as we know how the brain stores information, maybe we can represent intent. To me it just seems like a fantasy.”

I think this is more of a matter of the company’s name and brand not conjuring up the right issues. “Intentional Software” sounds too AI-ish. I don’t think that’s what they have in mind at all, but unfortunately by using the word “intention”, they inadvertently acquire connotations of all the AI projects gone wrong from decades past.

Another criticism:

Another argument, common among programmers, is more practical. Many programmers love their text-based editors and distrust tools that distance them from raw code. As for graphical programming languages like Visual Basic and the integrated development environments (IDEs) that automate routine programming tasks, they regard them with condescension: such tools, they say, impose their own ways of doing things, constrain creativity, and keep programmers from the code that, sooner or later, they must confront.

I’ve seen this a lot. But I think people are turning the corner, now that JetBrains and Eclipse have pushed the envelope. I was surprised to learn that Microsoft’s Visual Studio didn’t have “real” refactoring until 2005. Until then, most of the refactoring available in that IDE was based on regular expressions that didn’t have full awareness of the language they were transforming (such as the type system). So I think we’re going to continue to see skepticism of “fancy, whiz-bang GUI” persist for a while yet.

There’s also a bit about how this compares to previous efforts like UML:

Intentional programming encourages computer users to express their needs in their own familiar language, then shows them comprehensible views or “projections” of the emerging design before the executable code is assembled. It’s not the only programming philosophy that relies on such graphical representations; the Unified Modeling Language (UML), developed in the mid-1990s at Rational Software (now part of IBM), also uses graphical diagrams to represent a program’s function, structure, and behavior. But UML diagrams can’t be transformed into finished software, which is Simonyi’s dream for intentional programming.

Any system that does code generation is going to fall victim to this problem. The phrase “round trip” seems to be the way people are talking about this problem. Some systems advertise the ability to do round-trip refactoring… but I’m somewhat skeptical that they’ve solved the general problem of cross-language refactoring. And they lack Simonyi’s powerful notion of “projecting into a language”. There are so many underlying assumptions in software engineering — like the idea that the textual representation of code is more “raw” — that I believe that in order to be successful, the next generation of tools is going to have to embrace a set of higher-level abstractions.

The final criticism I have seen of this technology comes from the title of a comment posted in response to the article:

Sounds like lisp to me.

Again, I think Intentional is suffering from a marketing/branding issue. They talk about the “intentional trees” that underly the projected forms. The article shows one, and it does in fact look a lot like a LISP expression.

I hope to help argue why the new wave of tools is not just a reincarnation of Smalltalk or LISP. I’ll save those expositions for later posts. They’ll require a little more careful thought and planning that I have at the moment.

I’d like to ask Intentional why it has to reveal the internal structure at all. My guess is that the language “projections” are defined in terms of these trees. That the tree form is the “Rosetta” form that all other languages are described in terms of. But is that absolutely necessary? It may explain why they’ve chosen the word “Kaleidoscope” to describe the system/UI that manages these projections.

What I’m obliquely suggesting is that these DSL’s could be defined in terms of projections of other DSL’s — without that projection being mediated through the tree representation. That question is all built on guesswork and conjecture, but it’s the vague direction that my thoughts take me when reading what little public info there is about the system.

Update: It looks like they do in fact define the transformations in terms of the tree. From their OOPSLA paper:

The representation is in a uniform format for all domains: the intentional tree. Display and editing is performed by projecting the tree on a display by a number of reversible transformations

I’ll write more about the content of this paper later…