From Visual Developer Magazine #50, June/July/August 1998

Information Poet

Coding will always be important—but the future belongs to those who can master and explain Big Honking Abstract Specifications.

If I had to go out and find work right now, here's what I'd do: Become an Information Poet. There would be a lot of study and effort involved, but I'll wager there's plenty of money in it…as long as you don't use the word "poet" anywhere on your business card. A poet, after all, isn't someone who writes poetry. A poet is someone who interprets difficult realities for ordinary people, whether those realities are things like God, love, death, or…BHAS's.

We're speaking here of Big Honking Abstract Specifications. BHAS's have always been with us, but are becoming harder and harder to avoid. The first BHAS on record, a little item IBM modestly called PL/1, was easy to avoid: Just Say FORTRAN. We avoided Ada by ending the Cold War. We avoided C++ by pulling a lot of the abstraction out of it and calling it Java, which seems to be where all the action is these days.

But the truth is that we avoided those earlier BHAS's because they were programming languages, where abstraction is an optional ingredient. The point in programming is generating code, not beautiful structures of meaning, and if you don't like abstraction you can code beneath it. Compilers are concrete creatures. Abstraction is for us, not for them.

We are, however, reaching a crossroads in the computing industry. The obsession up until now was what a program did. More and more, however, we're discovering that what we really need to understand is not what programs do, but what their raw materials—data—means.

Compared to action, meaning is a very tricky business. What you mean by something is not necessarily the same as what I mean by that same something. Nor do we express the same meanings in the same forms, as evidenced by the multitude of human languages and alphabets. To get around problems like this, we must employ abstraction, to "get above" differences of simple presentation, and focus on what a piece of data really is.

When we begin to address problems like that, we run into the really Big Honking Abstract Specifications like SGML, which is so big and so abstract that almost no one knows all of it and not many could tell you what it really is or does. (What SGML really does is define tools to help us separate meaning from expression—a job more suited to philosophers than programmers, but one ideally suited to poets.)

SGML, and the shower of sparks it's throwing off right now (XML, SXL, MCF, and so on) will be utterly necessary to create a globally interconnected world where every workstation on a network can trade any kind of data with every other workstation on the network. And the confusion I've sensed about the nature of all the various ideas and technologies involved (will XML replace HTML? Can you write applications in SGML? What about DHTML? Are MCF and RDF the same kind of thing? Arrgh!) suggests that after the Year 2000 thing settles down, the big opportunity for bright, flexible, articulate people will be sorting out the multilayered mess by which we impose meaning on our data, and then explaining it to other people. Of course, the mess changes daily, which only adds to the fun.

As I'll explain in our cover story, the future of programming will not be code-driven so much as meaning-driven. Call it data design. Call it semantic engineering. What it means is seeing the meanings inside the meanings within the data, and capturing it in a form that our computers—and all of us—can understand and use on a global basis. This is a job for information poets—and may be the first time in history that the poetic muse can bring home a living wage.