[fa.human-nets] HUMAN-NETS Digest V5 #82

Pleasant@Rutgers (08/19/82)

HUMAN-NETS Digest       Thursday, 19 Aug 1982      Volume 5 : Issue 82

Today's Topics:
             Computers and People - Emotional Responses,
                Tecnology - Fifth Generation Computers,
                   Programming - Command languages,
                       Query - The MIT machines
----------------------------------------------------------------------

Date: Tuesday, 17 August 1982  19:51-PDT
From: Jonathan Alan Solomon <JSol at USC-ECLC>
Subject: Being hurt by netmail, moderator goof on message.
Address: 2817 Orchard Ave. Los Angeles, CA 90007
Phone: (213) 732-3423

Our moderator took the liberty of removing the "Phone:" line in my
header so saying "Look at the header of this message" was probably a
bit confusing to some. Here is the line from the header in case Mel
removes it again:
                Phone: (213) 732-3423

Regarding being hurt by someone in netmail - Once in a while?  Yes
that's normal; but...

I got into a phase recently where every message I read off the net
got me angry at the topic and caused me to flame back at whoever
sent it to me. I'm still holding each message for several days
before replying just because I need to force myself to calm down
from time to time.

I still maintain that if you are flaming regularly and you can look
back on a regular basis and say that you really shouldn't have been
that harsh on the person who sent a message to you, you are
addicted.  Once in a while if someone sends you netmail which hurts
you and you say so, well; that's a learning experience.

Rachel, The main difference between computer mail and handwritten
mail is the handwriting. We have already discussed on HN that there
are mappings from the computer world into the handwritten world
which deal with intonations and emphasis, if I wanted to
*E*M*P*H*A*S*I*Z*E* something, I could do it \several/ ways on
electronic media as well as in the handwritten world. You can't tell
how I am emphasizing words unless you either know the context or
know me personally. You can argue that the same holds true for
handwritten text, but expert handwriting analysts can usually tell a
lot about you from just your signature.

--JSol (The world isn't ready for more than one of me!)

------------------------------

Date: 18 Aug 1982 0735-PDT
Subject: COMPUTER-INJURED FEELINGS
From: DRCPM-MEP at OFFICE-8

  In response to REM at MIT-MC ( Robert Elton Mass or MASS, Robert
Elton or MASS?ROBERT? ):

  For whatever reason, the one prompt I get occasionally that seems
to cause the feeling that I've just been stabbed is: [Inferior Exec]

  Although I always think I'm doing the same thing, this pops up
sometimes when I log out of our Elite System. (EXECUTIVE LEVEL
INTERACTIVE TERMINAL ENVIRONMENT @ TYMSHARE) perhaps it's because
I'm not sure what it means.  Did I execute something in an inferior
manner, or did the machine just call me an inferior executive?

Jimmy Gale  O O
            \^/
             #

------------------------------

Date: 16 Aug 1982 0251-PDT
From: Jim McGrath <CSD.MCGRATH at SU-SCORE>
Subject: Fifth Generations

I too would like to hear some FACTS about the Japanese effort.  I
get the distinct impression that their goals are totally
unrealistic, and thus that it is either hype or a reflection that
they don't know what they are talking about.  Anyone have any
information about the real state of the world?

Jim

------------------------------

Date: 16 Aug 1982 0939-EDT
From: Jeffrey Shulman <SHULMAN at RUTGERS>
Subject: Fifth-Generation Computers

        You might want to read the "Preliminary Report on Study and
Research on Fifth-Generation Computers 1979-1980" from the Japan
Information Processing Development Center.  It answers all the
questions about who, what, when, why and how.

        At the recent VLSI conference last winter at MIT (which I
attended) there was a presentation about the FGC too (conference
proceedings are available).  It seems to be a fairly well planned
(and *supported*) undertaking that they MAY be able to pull off.
What we have that they don't is the experience in software,
especially Artificial Intelligence, but with a dedicated effort that
may not be a problem to the Japanese.

        I should also mention that over the previous weekend (8/14
to be exact) there was a TV show on NBC called "Japan vs. USA- The
Hi-Tech Shootout" whose major focus was how Japan could dominate the
US *soon* in computer technology unless something is done in the US
*fast*.  The FGC was mentioned as part of the entire Japanese
governments support for R&D in this area.

        What can we (as Americans) do about this?

        Japan has the $$$$:
                Japanese banks FULLY support Japanese industries [at
                only 8% interest no less]

                Japanese companies are partly subsidized by MITI
                (see below)

        Japan has a given focus:
                MITI (I forget what the initials stand for) is a
                "think tank" type organization that has the same
                affect in Japan and E.F. Hutton has in the US ("when
                MITI talks, Japan listens")

                They were responsible for focusing the Japanese
                industries on consumer electronics (stereos, and the
                like) and autos.  There latest "project" is
                computers.

                MITI owns several sports arenas where a fraction of
                all the betting money goes to subsidizing Japanese
                industry!

        Japan has the manpower and quality:

                Japanese don't produce junk.  Japanese workers take
                pride in their products and quality.  When was the
                last time you didn't consider a Japanese radio,
                camera or car?

What can we do?

                                                        Jeff

------------------------------

Date: 17 August 1982 15:38 cdt
From: Stachour.CSCswtec at HI-Multics
Subject: Bandwidth, encodings, abbreviations, and command languages

  One of the "obvious" solutions to the problem of what and how to
name commands is for a command to be called by multiple names.

  For example, the maximal form of a Multics command is
verb_adjective_object , with most commands being verb_object, such
as create_directory.  For the frequent user, the additional name
(addname) cd is provided to ease typing time.

  [There is of course an abbreviator that could be used to
accomplish a similar function, but this would make the addname a
per-user rather than a system-wide function.  I would consider it
unacceptable to force all users to use the abbreviator, whether they
wanted to or not.]

  And if one wants to know what one can do with directories, one types
    list_help directory
and gets a listing on the terminal of the the helps about
directories.  One can then select what one wishes to read.

  It is not perfect, unfortunately.  The delete_segment command
(delete_file to you non-Multicians, in Multics all 'files' are
virtual-memory segments, and can be [and usually are] addressed as
memory) is only called delete.  It probably should have had both
names, since the normal object one deletes is a disk-file.

  P.S.  I have used Vax/VMS extensively for the past 19 months.  I
have used over 20 operating systems in my nearly 20-years of writing
computer programs.  I disagree STRONGLY with those who have
advocated the 'ease-of-use' of Vax/VMS.  I personally find that many
things I do on other operating systems cannot be done at all on
Vax/VMS due to 'bad design' in the command interpreter.  I could
easily FLAME for 10+ pages, but will simply say
  "Those who think that Vax/VMS has a good command-language and
command interpreter probably don't have much experience with other,
better, command-languages and interpreters".
  I work on that project with about 30 people with MS degrees in
computer science, none (except myself) with Honeywell experience,
yet almost all complain about the problems with the command language
compared to the their previous environment.  Note that most of them
came from big-system experiences, where disk-space does not preclude
good interfaces, help-files, etc., as is often the case with micros
and minis and super-minis.

------------------------------

Date: 16 August 1982 23:21-EDT
From: Zigurd R. Mednieks <ZRM at MIT-MC>
Subject: Man machine interface

ALthough the fact that most of us interact through boring,
non-graphic terminals might dull our senses, the clues to what would
make a good man machine interface lie all around us in magazines,
signs, labels on buttons and knobs, etc. What is needed in the
man-machine interface is the same quality of aesthetics as is
brought to bear on appliances, cars, advertisement, and other visual
"interfaces".

A bit map is a very special canvass that can hold pictograms, words
and abstract symbols and bring them to life. It does not seem to
have been appreciated that what a program puts on a screen might be
judged at the same level as the front fender of a Firebird.

A common flaw in the outlook of engineers is to place over much
importance on the internal workings of a device. This is at the
expense of not realizing that a "thing" makes a statement at every
level, not the least of which is its visual manifestation. In a
computer system, this manifestation has behind it the power of the
computer itself, and had a great deal of unrealized potential.

Just today I saw a key fob with a logo on it, instantly recognizable
as "Coca-Cola" -- even though the logo was in Arabic. Now if only
every "foreign" user interface I've had to deal with had the same
clarity of meaning.

Cheers,
Zig

------------------------------

Date: 13-Aug-82 11:15PM-EDT (Fri)
From: John Black <Black at YALE>
Subject: Memorable Command Languages

     There is a body of psychological research concerning how to
make command languages memorable that the human-nets community seems
unaware of.  This research is summarized in

        J.B. Black and M.M. Sebrechts "Facilitating human-computer
        communication"  APPLIED PSYCHOLINGUISTICS, 1981, 2, 149-178.

I would be happy to send a copy of this paper to anyone who sends me
their address.  In case you think you know it all already, let me
give a few tantalizing glimpses:

  1.  Using English words for command names is not always best and
      sometimes can be very harmful (it depends on how
      discriminating the words are)

  2.  English order for arguments is not best (consistent order is
      better)

  3.  Command terms chosen by naive users do not make a good set
      (they tend to choose general, high-frequency words and both
      those characteristics are detrimental) and the probability
      that any two naive users will chose the same name for a
      command is low (typically .04).
                         Etc.

I think the recent proposal on human-nets to always use verbs for
commands is wrong because what is a verb is very slippery in English
-- i.e., nouns have a way of becoming verbs when needed.  For
example, "He Reaganized the budget" or (as I have heard complained)
"Their trivial comments useneted the arpanet bulletin boards."  This
process provides much creativity and generativity that we need to
effectively convey systems to users.

------------------------------

Date: 18 Aug 1982 1238-PDT
Subject: The MIT machines
From: WMartin at Office-8 (Will Martin)

Back when I was first introduced to the ARPANET (1976) and for the
rest of the 70's, the MIT complex of computers seemed to be the
heart of the net, in terms of the mailing lists, the people who
contributed, and the famous "guest" accounts which brought in people
who never could have otherwise participated.  Even if that
particular group of nodes was not really central to the net's
construction and operation, it was very important in human terms.  I
think it is fair to say that the entire network community would be
very different today if the MIT machines, software, and the policies
that controlled them were not there at the time they were.  I
venture to say that the net would be much less interesting, more
strictly work-oriented, and much of the fun would be missing.

Now, we see comments on various lists that they have moved from this
or that MIT machine due to reasons like hardware problems.  I think
there have been policy changes which have affected the ability of
people on the MIT machines to participate as fully as they had in
the past and the composition of that user community, and, of course,
there has been personnel turnover which is expected at any academic
site.

Anyway, this all seems a bit sad.  Something we all owe a lot to
(even if an individual is new to the net and never heard of any MIT
host) has passed away, or at least entered a period of decline.  In
addition to acknowledging our collective debt to the birthplace of
the mailing lists, though, I'd like to know something about the MIT
computer complex, and its history.  Aside from having heard about
the ITS operating system in passing, and rude comments from people
when "ITS-style" mail made it out onto the ARPANET unclothed in
proper ARPA-style headers, and some experience FTPing LOTS of
information from the archives stored there, I really know zilch
about it all.

Could someone who was at MIT back in the 70's contribute a brief
history of the growth of the complex?  What hardware was used and
how did it change over the years (in general terms, of course)?  Why
did the software develop the way it did -- was there some professor
or student who strongly influenced the course of development?  Why
was the mailing software so suitable for mailing lists developed or
resident there, and practically nowhere else?  (As far as I recall,
for a long time ONLY MIT could distribute mailing-lists
automatically.  If any other hosts could, they didn't advertise it!)
Why did the generous "guest" accounts policy evolve the way it did?
(It's pretty clear why it was cancelled, but it's certainly
admirable that it ever existed in the first place!)

I don't mean this to be a eulogy; I expect to get some mail saying,
"Hey!  We're not dead yet!"  Nonetheless, things are different now
than they were then, and I think it will be valuable to capture this
history while it is still fresh.

I feel sure that others on the net who were exposed to the growth
and development of MIT-based mailing lists must feel some
combination of fondness for the resources that made it possible, and
concern over what has happened to it recently.

Will Martin

------------------------------

End of HUMAN-NETS Digest
************************