Forever ago I started a response to something Dave Darnell posted under the
heading of "picking a language", but my response rambled and then I got
stuck doing yearend and never got back to it. Given the discussions going on
centered around OpenMPE, I thought I would post this anyway instead of
delete it from the drafts folder.

CAUTION - This is LONG.

Over the years I have read things many things on this list which, if I
accepted at all, had to be taken with a large pile of raw salt.  An example
of the exact opposite appears below.

Dave Darnell writes:
> OK, OK, what's my point? A "good programmer" can make almost any language
readable and maintainable, and a hack can make any language obscure, hard to
maintain.  I believe it's the programmer's discipline, traingin and
commitment to methodology and principle that make the difference.

That has more truth to it than most of what I read in the weeks following
11/14.  YES!  The programmer is the difference.  In more general terms: the
people make the difference.

When I first started learning "web" languages, I would surf the web and when
I found a site which I thought was well designed or showed some intriguing
scripting, I would "VIEW SOURCE" and pick it apart.  Not to favor machines
over humans on this vein, but you can always tell pages that are written by
other softwares.  They tend to be organized, with standardized formats
(read: indention, variable naming and imbedded comments), and would be easy
to maintain by the humans who come afterwards.  Conversely, it is just as
easy to identify code written by a 19 year old whose had one too many JOLT
colas.  To play devils advocate, it is also VERY easy to tell pages whose
code was written by BAD software: even more difficult to read than the
caffeine laden scrawlings mentioned previously, or worse crammed full of
functions whose only applicability must be to the way ONE person at the
orignating firm likes to see things.

All of which describes my greatest concern about open sourcing MPE, which I
view as a great opportunity, and a pretty hefty challenge.  If I know Jeff
Vance's or Mark Bixby's hands have been in the mix for some change to MPE,
I'm fairly certain (read: I'd bet money) that it will not break some other
portion of the OS on which my programs, and processes are dependent.  Or at
least, that it will be documented clearly what will break and why.

I'm intrigued by the idea of an open source version of MPE, for various
reasons; not the least of which is that I like thinking the 911 emergency
systems running on a 3000 should remain as stable and reliable as they are
now, or that this platform I've come to love won't fade away.  Opening the
source also means that the product will not disappear without HP maintaining
it.  The only models for open source I've seen, however, are not exempt from
problems that I think only the volume of participants has staved off in
other products.  The competing needs of users demanding changes while
focusing resources on maintaining the structure and strengths of the system
(oh, and don't forget backwards compatibility whenever possible) is not
something two guys in a garage can maintain for long.  Okay, a few decades,
max.

I had always taken it that Open Source meant that if your shop can't use the
standard, then roll your own.  That's good and bad: good because it means we
don't have to wait for the powers that be to write, test, incorporate, test
further, release as beta, approve, and general release a product; but, bad
because it means that the stability of a baseline disappears.  "You're
getting an error in THAT subsystem?  But nothing's changed that touches it?
Oh, YOU changed it.  Okay, revert to the standard and remove all your own
modules then duplicate the error, okay?  Thanks."

Something about the 3000 which I fear may be lost in the transition we face
is that the product in general, the community in particular, and the
hardware model generally promoted good data processing methodologies (at
least to get good performance) which have been sadly lacking in many of the
systems which came after.  "We don't need to make it efficient....we'll just
get more RAM and another parallel processor."  Or would anyone like to
explain to me why there was a flight simulator embedded in Excel 97.
Bloated code (or maybe "obscenely bloated code") is not something that could
make it past the knowledgable, involved, user base that would call CSY on
it, had it ever happened.  With clients spending the kind of money that the
ISV's have gotten for the platform, there was/is a need to get great value
from the product and that is not compatible with what you frequently see in
the software and hardware industries today.

Okay, so we won't be able to input a series of key strokes and get someone's
video game from the CI; but that extreme is indicative of the problems we'll
face if too many of the existing shops opt to leave the platform rather than
fight for it in an open source model.  Without that broad user base to catch
problems and report them, the product will lose at least one pillar to its
strength.  The gurus (and since I have hit the decade mark in usage, but
only eight years in development I don't qualify) upon whom we depend are the
key to making open source work, and if they get swallowed by other HP
divisions/projects/etc....

I have been wondering if a "temporary" open source solution is better: the
open source entity (we'll call it "BOB") works on MPE, migrating it to IA64,
and working it closer to the unix model (read Mark Wonsil's post discussing
the merge of HPUX and MPE).  If BOB can play well with HP, why wouldn't they
want to incorporate back into HPUX the core strengths of MPE, and thereby
potentially gain back the wayward children who wouldn't come in from playing
after the sun set.  Or would BOB be better off finding someone else with
whom to play this game....maybe another truly open source software (there's
a name that starts with "L" that noone can pronouce).  Hmmmmmm.

I saw a posting on slashdot that basically said a really good way to make
some money would be to write an MPE emulator to run in the the Linux shell.
It suggested that someone should write a fancy process trap that segregates
a section of memory to appear like MPE for whatever application was running
in it, capture all calls, and translate them into whatever was needed to
integrate with the remainder of the system.  I didn't reply, because my
response would have gone in about eight directions at once.  I would like to
ask Jeff, Mark, Ken, et al, how hard would it be to get HPUX (or Linux for
that matter) to do whatever pieces are missing from their models?  Maybe I'm
being dense, or missing huge pieces of the puzzle, but...aren't we all
running shells?  Isn't the main difference between starting a session on a
unix box and starting a session on the 3000, that we are automatically tied
to a process running CI.PUB.SYS, which then acts like a filter for every
additional call or instruction we make?  If that description isn't too far
off, then CSY has already done what was described on slashdot.  It just runs
in the korn shell instead of Linux, and it's called CI.

On an entirely different track (okay same heading but three tracks over).
If the overhead of maintaining MPE is so extreme that HP/CSY is giving up
the ghost, how can BOB do it for any great length of time?  Certainly the
resources exist to get BOB to accomplish some set of goals (IA64, Unix
merge, etc), but for another 30 years?  I have to repeat "hmmmmmm".  Yes,
we'll lose some things in the process, but if we get the reliability and
flexibility of our platform incorporated into *nix, and maybe teach those
user groups a few of our lessons on being a community in the process,
doesn't that gain us what we need now, and what we would need to go forward?
If the solution includes even a scaled back CI emulater which can keep us
from having to completely rewrite applications, doesn't that give us what we
have to have?  I know, I know, I want my MPE, too!  But, I'm not Winston and
I don't get to say whether or not it will be possible.

Just my $.0178 (that falling interest rate, again).

</ramble>

I just wish CSTM wasn't such a piece of .... lower quality software.  And,
yes, even with the power rates in California, I'll keep a 3000 at home to
work on, and add my talents to the open source pool when the time comes.

signed, concerned in concord,
Rs~

Russ Smith
(not listing any companies....it's personal)

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *