The Joy of Star Trek

—Andy Hunt

10/01/1998
Published in Toolshed Newsletters

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

But I think he misses an important point, and a key point that can explain how some of the miraculous Star Trek technologies work.

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?

Meta Data

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, etc.

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:

Direction.
Speed.
Units and ranges for both.

Adaptable Systems

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.

References

[PETRELEY] Petreley, N. “Mr. Spock and Dr. McCoy give an object oriented programming tutorial”
InfoWorld, September 14,1998.
http://www.infoworld.com/cgi-bin/displayArchive.pl?/98/37/o12-37.112.htm
[WSJ] 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.

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.