Re: Hello, translated world!

[Michael McClary <michael>]

[Comment from Roger, addressed directly to me, noted but not quoted.]

> From tribble Thu Apr 26 00:17:35 1990
> 
> and if you don't send messages about your translator changes, I'll
> shoot you.

I'll tell you about mine if you'll tell me about yours.  B-)

(By the way - in the gun culture, talking about shooting people
 is never entirely a joke.  I'll try to keep my irritation
 under control in the rest of this letter.)

> Note: many little hacks are already in the transaltor in
> one form or the other.

Yes.  I have encountered a few of them.  One of them was what
prompted my previous message.

(The translator assumed ALL translated programs would want to
suck in the X++ support, unless they were defining part of it,
in which case they'd want to suck in its foundation.  This is
a not-unreasonable thing for it to do, since it is primarily a
tool for building our backend and frontends, which will all be
linked with X++.  But it set off my presenting-non-obvious-
features-to-naive-users-considered-hazardous alarm.)

(By the way, I want to mention that my first close encounter with
the translator gives me the impression it's a >wonderful< thing.)

> If you can send out a description beforehand,
> we might save lots of trouble.

Then I am expected to continue to poke at smalltalk on my own,
determine what functionality I want, and then ask you whether
it is already there?  Seems like a marvelous way for me to fall
ever farther behind.

What would save me, and Roland, and all future users of the
translator even more trouble would be some documentation.

I realize that documenting what you are doing is a burden.
It's much easier to run ahead with design, trusting those
following you to have an understand of smalltalk, X++, the
translator, their bugs, their dynamic reorganization, and the
rest of Xanadu's programming environment baggage as deep as
you who have implemented it.  The incentive is to minimize
your own workload.

But you should also realize some of the consequences of working
this way.

I'm learning smalltalk as I go, and come from a background of
more classic languages.  I don't have your Parc experience with
non-Xanadu-hacked smalltalk.  I'm trying to learn this sucker on
an image containing a spaghetti-mass of Parc Place code (with
documentation that never kept up) and Xanadu code (with no
documentation at all, bugs, rapid changes, and all background
information squirreled away in the meatware of a few of you, or
traded around in meetings which often occur away from the office,
at times I'm not in, or from which I'm excluded in the interest
of "keeping the meeting small so things get done".)

To top it off, last year I decided to approace the job depth-first
from one edge, rather than breadth-first as the design with being
rehashed, expecting to be able to absorb the rest of the design
a bit at a time, while getting useful work done.  I now realize
this was an error - like trying to keep ahead of a firehose with
a sponge.  There was far too much to learn this way, and it changed
too fast.  I should have been intensively studying what the rest of
you were doing, and I'm now left with no knowlege, little information
path, and collegues annoyed by my ignorance whenever I ask questions
in the hope of correcting it.

This presents me with a task much like maintaining applications
written in APL.  The basic language is simple, does a lot compactly,
and is so opaque that it is easier to throw away code that doesn't
do what I want and write a replacement from scratch.

As I see it, there are several ways to proceed:

I can continue as I am now.  Do my best to understand the code from
the example at hand.  Bull my way into the image and interrupt your
work with questions.  When a capability seems missing or a chunk of
code appears to be a bug or a hack, pester you if you're available,
assume its what it appears to be if you're not.

I can be pleasantly surprised by the appearance (sudden or gradual)
of documentation.  (Alternatively, by the sudden appearance of a
presentation on the translator and programming environment, like
Markm's semantics marathon, or a set of tutorial sessions.  This
approach has the downside that it must be repeated for the next
guy, ad infinitim.)

I can decide my contributions will be of negative net value, and
find something else to do for Xanadu (or update my resume, so Xanadu
can put my salary to better use).

I intend to go ahead with the first approach, and hope my judgement
and programming skills are sufficient to produce a net benefit.
I'll try not to smash too much of the china-shop.  But you've all
hacked whatever didn't match your idea of the right way to do things.
Don't expect me to behave differently on this issue.

	michael