In an article in InfoWorld ([PETRELEY]),
the inimitable Nicholas Petreley talks about object oriented
programming in the context of the Star Trek universe. In
particular, he cites an incident in
Star Trek: The Undiscovered Country where our heroes
retrofit a photon torpedo’s guidance system with a plasma gas detector
in order to blow up an otherwise undetectable enemy ship.
Petreley talks of some possible difficulties in interfacing the
detector to the torpedo:
- The gas detector reports magnitude only, torpedo requires magnitude and direction. You need to introduce a spinner that samples in different directions.
- The parts may have different plugs or jacks that might not fit each other.
- They may also have different voltage ranges or requirements that may need to be scaled or inverted.
- You may also need to introduce some sort of feedback algorithm to correctly “steer” the torpedo.
His conclusion is that standardization is the key:
It seems to me that the only way we can ever get life to imitate
art—that is, to make programming as easy as tossing together a
custom photon torpedo in Star Trek—is to get to a point where
almost everyone supports a single distributed-object standard.
— Nicholas Petreley
But I think he misses an important point, and a key point that can
explain how some of the miraculous Star Trek technologies
If the key is to achieve a level of standardization, then how
is it that the Federation stuff works with both Klingon and
Romulan technology as well? Surely they don’t all sit on the same
standards boards? And yet they are always borrowing some bit of
alien or enemy technology and plugging it in with little trouble.
Dramatic license aside, how could that actually work?
The secret isn’t standardization per se, it’s metadata.
That is, data about data. Once you have self describing data,
and self describing systems, then a little bit of machine intelligence
is all that is needed to let the system itself figure out how
to do what is necessary.
One possible ideal in programming is to have a completely declarative
programming language—to specify exactly what you want done,
and to neither specify nor care how. Procedural languages,
and even object oriented languages, concentrate on the how.
For example, look at Enterprise Java Beans (EJB). Part of the EJB
spec lets you declaratively specify what sort of transaction
processing you want your bean to perform. You put no code in the
bean you write to handle transactions; rather, that is done on your
behalf according to the spec. This implies that you can then
dynamically change how transactions are performed without
changing the source code of either the bean or the system!
Have you ever seen a character in Star Trek recompile a program? Especially when some enemy ship is firing away? Not likely.
In order for this to work, the system itself has to figure out
how to accomplish a given task.
Let’s look at the torpedo example. If you asked the plasma gas detector
what it does, it may reply:
- Detects (some long chemical formula for the gas in question)
- Reports amount of gas per physical unit.
- Units used.
- Range of detection.
- Interface considerations: connectors supplied, voltage levels used,
The torpedo, being a complex device, may have a great many things
to report about itself! But for now, consider simply the guidance
system. It tells the torpedo where to go. Where the guidance
system interfaces to the torpedo itself, we can ask the torpedo what
it needs to know:
- Units and ranges for both.
With sufficient metadata, you can achieve a fully adaptable
system. A sophisticated piece of software, perhaps functioning
as an agent, can query and negotiate between disparate systems
to automatically create a meaningful, semantically correct interface
between them. You can see the beginnings of this approach in
data communications—something as simple as two modems agreeing
on protocols, speed, and compression, for instance.
This isn’t just limited to software! Hardware can dynamically
adapt itself as well. There was just an update in the
paper ([WSJ]) describing the latest
improvements in a trend started by the first FPGA (Field
Programmable Gate Array) devices. The article quotes the possibility
of a cell phone that could work in any country:
Somebody traveling around the world could find that their phone
would automatically reconfigure itself several times in a day.
It goes on to mention the usefulness of such a technology in places
where physical access to perform an upgrade is impossible—like
in a satellite in orbit.
So if we can architect systems that fully describe themselves,
including their capabilities, and even programming instructions,
coupled with software and hardware systems that are capable of
dynamically reconfiguring themselves, then we are well on track
to creating the sort of technological universe that the writers
of Star Trek envisioned.
We may even solve a few sticky business problems along the way.
Takahashi, D. “Xilinx Creates ‘Reconfigurable Chips’ Allowing
Online Upgrades of Hardware”
Wall Street Journal, November 12, 1998 page B6.
Star Trek is a registered trademark of Paramount Pictures in
the US and other countries.