In the newest issue of the 3000 NewsWire, Shawn Gordon writes:

"..I have to say that Wirt Atmar's plans for his built-in HP3000 graphical
interface are nothing short of astounding. I'm going to be very curious to
see how this plays out in the future. I can see lots of uses for it, but I'm
wondering if it's almost too late to have a significant impact on the
3000-based software developers."

Because Shawn is a long-time friend, and because I'm sure that he won't take
offense, let me take this opportunity to disagree with him a bit, in part
because I've heard this "possibly too late" comment several times now. There
is an ancient Chinese proverb that says: "The best time to plant a tree is a
hundred years ago. The next best time is today."

While several people have half-jokingly asked me, "Why didn't you develop
this ten years ago?", I actually can't think of a better time for something
like QCTerm than now. The internet is changing everything. And everything
we're doing with QCTerm is aimed at making the process of putting an
extraordinarily pretty front end on an HP3000 application be as simple, as
reliable, and as efficient as possible, particularly so over the internet.

We're truly at the cusp of a new day. You can forget much of what's gone on
in the past. And whenever these sorts of times occur, they tend to be marked
by confusion and chaos, simply because of a panoply of choices all burst onto
the scene at about the same time. Clearly we're at that point now. But it has
been my experience that, in the end, simple and easy-to-understand almost
always wins out over the complex and convoluted, and that fast and nimble
almost always wins out over cumbersome and slow, and that pretty and colorful
almost always wins out over the dull and gray, and that simple and efficient
almost always wins out over the bloated and inefficient, and that reliable
and robust almost always wins out over the fragile and complex -- and that
cheap just plain always wins.

If there's any advantage in getting older, as I am, it's experience. As a
consequence of that experience, these six criteria: simple, fast, colorful,
efficient, reliable and cheap are governing everything we're currently
putting into the design of QCTerm.

As you all well know, the subject of what single thing would do the HP3000
the most good comes up rather often on this list. The common answer is:
Applications! But the second paragraph in that discussion almost always has
something to do with HP paying massive amounts of money to some vendor to
port their application over to the HP3000.

I've always rejected that answer. A vendor recruited in such a manner will
have all of the loyalty of the pet robot dogs that are popular in Japan at
the moment. They'll bark and roll over for whomever pulls their string, for
exactly as long as someone keeps pulling their string. The only truly loyal
-- and truly efficient applications -- are those that are developed for a
particular target machine. In the new world of "apps-on-tap" that's coming,
where the server will be hidden from the user, and may be in fact thousands
of miles away, the former religious wars regarding which platform to buy and
run are simply going to go away. The user doesn't know or care what the
platform is, so long as it never goes down and it reliably handles his data.
But precisely because of that, the pressure to develop "open systems"
applications is also going to disappear. Efficiency and elegance are going to
become the buzzwords again. Eschew heterogeneity. Promote simplicity.

Fifteen to twenty years ago, when most organizations were first computerizing
their central business operations, the standard business advice was, "Buy the
application -- and then buy the platform it runs on."

That rule began to change about ten to twelve years ago. What had changed was
by that time, almost everyone had their chosen hardware systems well in
place. The investment in current systems had become so high that the former
standard business advice was no longer feasible. If you were a vendor, and
your application didn't run on the users' hardware, you lost a sale. And
nothing so impresses a vendor as a lost sale. Or a potential customer who
can't get a superior solution on his boxes. Thus, the demand for "open
systems" became a crescendo, software solutions that would run anywhere.

There are two common approaches that arise whenever the cries for
universality recur: (i) the birth of a thousand standards committees and (ii)
middleware. For the most part, the most recent standards committee phase has
come and gone. The "standards" that exist have now been weeded down to a very
few, and they tend to be rather simple, things such as TCP/IP and JPEG files.
We're now left only with middleware as a potentially attractive solution.

But it's also been my experience that middleware also has a relatively short
lifetime before it too disappears. The same ideas that currently underlie
CORBA and DCOM are exactly the same ideas that underlay device-independent
graphics files fifteen years ago and device-independent word-processing files
25 years ago.

Whenever a new technology blossoms, there are inevitably a great number of
new players that enter the field almost simultaneously. In evolutionary
biology, the phenomenon is called "the novel incursion into a new adaptive
zone." In the end however, only one or two solutions survive. All of the
initial diversity disappears. In computer marketing, the process is called a
"shakeout," but it's exactly the same process.

For that bit of time when the diversity of solutions exists however, there is
an inevitable pressure for the development of a device-independent middleware
solution -- and there was precisely such pressure to develop middleware
during the epoch of the large, expensive standalone word processors. The
command sequences that represented bold or underline on one machine were for
the most part chosen arbitrarily and -- as a consequence -- were virtually
guaranteed to be different from all of the other word processors. If files
were to be exchanged between different manufacturer's word processors,
translation first to a device-independent file and then back again into the
target machine's code was by far and away the easiest solution. The
alternative was to attempt to translate your word processing document
directly to every other possible file structure, in one step, without going
through the device-independent step. When the diversity of solutions is high,
translating anything to anything becomes an impossibly difficult task for the
various vendors to maintain.

But this middleware phase never lasts very long. For one reason or another,
the diversity disappears. In the case of standalone word processors, the
newly arrived from-out-of-nowhere, PC-based, WordStar word processing program
single-handedly killed the entire standalone word processing industry, in the
process losing hundreds of millions of dollars for companies such as Exxon,
Vydec, Raytheon and IBM that had invested heavily in standalone
wordprocessors, even though WordStar wasn't nearly as good. But it was
enormously cheaper.

Wordstar itself was just a few years later killed by WordPerfect, which was
subsequently killed by MS Word. While there are other word processing
solutions still available -- and you can see faint remnants of the original
bushy evolutionary tree -- competitive exclusion has now trimmed the bush
down to just one overwhelmingly dominant solution, as it always does.

But even during that period when the demand for middleware may seem high, it
is still never much more than a marginal solution, a bandaid to patch over a
mess, laced with a dozen unnecessary points of failure.

Beginning with the terminal model and skipping all of this middleware has
several salutary attributes: It is the most backwards compatible display
client approach possible. It is, by its very nature, compatible with almost
everything that has gone on before, thus there is enormous investment
protection implicit in using a terminal emulator as a starting point.

Secondly, enhancing the terminal emulator is the most genderless approach
possible. QCTerm makes absolutely no demands on the user organization
regarding what developmental languages are to be used on the HP3000. They can
be ancient (ALGOL, FORTRAN, COBOL, BASIC, etc.) or they can be so new as to
be essentially unproven (Perl, Java, REBOL, etc.). The only real concerns in
choosing a language for new applications development -- and that's what we're
truly interested in -- are selecting a language that can manipulate strings
and files with ease, be simple to understand by your successors, easily
maintained, and yet have a very tight integration with IMAGE intrinsics.

Thirdly, there's not even very much about QCTerm that ties the emulator to
the HP3000. We're taking our time and choosing what we're going to support
and how we're going to implement it with a great deal of care, simply because
there is a possibility that QCTerm can eventually become a standard. If it
doesn't, c'est la vie. But if it does, we don't want to have to go back and
make some fundamental changes.

In that regard, as some of you know, we're not going to do anything to try to
extend the life of VPLUS, although QCTerm will fully support existing VPLUS
applications. I've always considered VPLUS to be difficult and clunky.
Instead, we're putting together a new forms mode that should be very, very
simple to implement on the host side, using virtually any language, with no
intrinsics and no escape sequences. This attribute too will only make QCTerm
all the more genderless; it could be made to work just as easily with any
operating system (Linux, NT, BeOS, etc.). The only reason that you might want
to choose the HP3000 as the primary platform is because of its extraordinary
reliability and inherent simplicity (which are reasons enough for me).

Shawn also wrote:

"Maybe [QCTerm] will inspire a new generation of vertical market development."

That is precisely our hope.

Applications development used to be simple, easy and fast. We want to make it
that way again, if not outrightly enjoyable. I also firmly believe that small
projects have a very much greater chance of success than large, complex ones
ever do. I very much want to encourage small IMAGE-based applications
development on the HP3000, where something like a time-card collection system
can be put together by the local staff in just a week or two.

If we're going to plant trees today, I would rather help plant a thousand
tiny saplings than try to jury-rig one massively large oak.

Wirt Atmar