The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 3 Issue 21

Tuesday, 15 July 1986

Contents

o Responsibility
Willis Ware
o Programming languages and computer literacy
Bob Estell
o Teaching about risks, BASIC, NASA, etc.
Eugene Miya
o Programming Languages
Matthew Kruk
o BBoard Lingo (Trojan viruses,...)
Hank Burchard via Peter G. Neumann
o Info on RISKS (comp.risks)

Re: Responsibility (RISKS-3.20)

<willis@rand-unix.ARPA>
Wed, 16 Jul 86 09:24:36 PDT
1.  Re Dave Benson's comments on responsibility.  I suspect that
professional licensing has one more attribute that he didn't mention;
namely, it establishes some legal status and legal liability for the
licensee.  And it may therefore give injured parties standing to sue the
licensee for injury and/or damages.

Also: what about the position that software is a consumer product?  If
that were to be established, then all of the consumer protection legal
apparatus and consusmer protection groups would come into play -- and
maybe do something useful.

IDEA:  You know Susan Nycum; ask her to express an opinion on the
issue and the various views.

2.  Re Ron Morgan's views.  I couldn't agree more with his lament that
people equate "computer literacy" with "ability to program", or even worse
with "ability to program properly and produce a well checked-out, tested,
and documented product that will meet specifications." They are NOT
synonymous concepts, but they are related.

When the term [computer literacy] was first used and talked about more
than 20 years in discussions here at Rand and elsewhere (notably by Paul
Armer and Fred Gruenberger, names which I'll wager readers of RISKS don't
even know), it meant simply some awareness and understanding of computery;
e.g., how they work, what a program is all about, possibly some very low
level of being able to use one or at least to stroke a keypunch
successfully.  YES, Virgina, it was keypunches in those days, not
terminals.

Automatically of course, the professional programmer knew all about such
things, and was computer literate.  But the converse was not true: a
computer literate did not automatically have all the qualifications,
skills and experience of the professional -- or even semi-professional --
programmer.

The original intent was primarily to head off the fear that individuals --
and managers and organizations -- then seemed to have of computers.  They
were strange beasts, using strange technology, doing mysterious and
invisible things and seemingly not subject to the usual precepts of
management.

There was also a conviction even more than 20 years ago that computers
would be important in society and in the world and would have a profound
effect.  One can find papers on the subject in the Joint Computer
Conferences of the early 60s.  Thus, it was argued that people should
simply be acquainted with computery and be able to fit computers into
their frames of reference comfortably, and accept them as commonplace
mechanisms.  Remember when you read this:  I'm talking of the period when
it was all mainframes and centralized computing shops, and the programming
fraternity argued persuasively for and held sway in the closed-shop!

By analogy, it was like "automobile literacy" which is a characteristic
that we all have even tho we don't repair our own cars or even know what's
under the hood.  In fact just that sort of argument was used to get the
term established.  Or again, being "language literate" doesn't mean that
one can write Pulitzer material, only that he can read and write the
language.  A literate person may, but need not, be literary, educated and
cultured.

We'd do well in the computer field to mind our definitions and semantics.

     Willis H. Ware, Rand Corporation, Santa Monica, CA, willis @ rand-unix


Programming languages and computer literacy

"143C::ESTELL" <estell%143c.decnet@nwc-143b.ARPA>
16 Jul 86 08:39:00 PST
I'm somewhat repeating some of PGN's words of wisdom here, but I must
share a gem I got years ago from Lawrence Flon, then at CMU; it's
Flon's axiom, and it goes like this:

 "There does not now, nor will there ever, exist a programming language
in which it is the least bit hard to write bad programs."

The entire article is worth digging out and reading; it's in SIGPLAN
Notices, October '75.

Sure, BASIC, FORTRAN, COBOL, et al, and certainly Pascal and the other
structured languages have taken us away from many of the syntactic errors
that bedeviled assembly code; like erasing the (primitive) operating
system, or jumping into a data field and crashing the processor on an
illegal op code.  Cross reference checks, type checking, et al may get
us a bit away from semantic errors as well.

But what's to keep us from writing just plain wrong formulas?
This is parallel to trying to educate surgeons to prevent "bad" operations.

Switching analogies, maybe computer literacy should be the equivalent of
the "driver's license" (my earlier analogy); and programming licenses
should be the equivalent of the auto mechanic's license.

Bob


Teaching about risks, BASIC, NASA, etc. (RISKS-3.20)

Eugene Miya <eugene@AMES-NAS.ARPA>
16 Jul 1986 1008-PDT (Wednesday)
I will keep PGN's comments on Cramer's message about irrelevance in mind,
but I will come close to straying.

In his most recent RISK posting, Dr. Benson alluded to "Certification" a
time honored topic of the 1960s (certainly predating me).  While I am
familiar with the so call Certified Data Processing certificate, I have met
very few CDPors.  Is what these people inadequate for RISKy systems?  Should
we update the CDP to include more than business type DP or should we have a
more professional (i.e., doctors and lawyers) bonding?  I don't know, but it
seem a weak basis already exists and is not used, or is used weakly.

Several writers alluded to BASIC.  Several more said it was irrelevant, I
agree.  Real-time BASIC is (or was) used by the Navy in ship-board air
defense (I was told), and I know it is used in the Deep Space Network for
communications with unmmanned planetary probes. Those pictures you see of
controllers at the Manned Space Center are NOT programmers, they are
physicists, EEs, and other types of engineers.  It was recently emphasized
in one computer ad that most did not know how to program and that some were
learning another Real-time BASIC.  For them, the interaction is important;
if anything, someone needs to develop a better interactive language to
combat the problems mentioned in earlier postings.  The "compiled batch"
oriented nature of most programming languages are not always conducive to
complex control systems.  I am not, BTW, and have not worked in complex
real-time flight systems.  I do not want to worry about those RISKs, and we
have all heard the stories about people with broken homes, etc. (few)
because they could not handle the stress associated.  Most of these flight
system programmers are everyday programmers (except they work with flight
qualified hardware: slower, smaller memory, etc.).  Think what you will of
them, they don't all program in Ada yet.  If you are interested in this type
of work, you should be ready for Congressional investigations (I worked on a
project which had one.), and people staring you in the face and asking you
tough questions about schedules (isn't hindsight wonderful).

This all finally focuses on our attitudes on how we teach risks and
computing.  Attitude is very important.  In private correspondence
to our editor, I noted am example of attitude shift in my avocation.
Prior to 1946, rock climbers had a saying "The Leader (guy going first)
must NOT fall."  After the publication of a book entitled Belaying
the Leader, climbers took a new implicit approach to belay: "The Leader
will fall, what are you going to do about?"  The training emphasis
shifted to practicing for worse case situations.  Climbing in the world
went to greater levels of difficulty, fewer trained climbers were killed,
and American climbing became a new standard in the world.  I think
we in computers are in the earliest stages of this.  We don't have all
the tools for a transition of ideas.  But, I hope this qualitative analogy
helps.

Hope I didn't stray too far.

--eugene miya
  NASA Ames Research Center


Programming Languages

<Matthew_Kruk%UBC.MAILNET@MIT-MULTICS.ARPA>
Wed, 16 Jul 86 10:11:50 PDT
You have my vote: the less intrinsic pitfalls in a programming
language, the better. The "Roman Language Empire" is still young and
we should strive for progressive language development or fall.

I do not deny that many "good" programs, programmers and languages
exist but the day we become complacent and cease laughing is the day
we become prey to our own pitfalls. We should come to expect better
and not merely be satisfied.

(I do not want to start or see a "which programming language is
best" debate. In some cases, the simple answer is "that which an
individual is most competent at". This can be resolved in your own
mind; typically, and sadly, it is resolved by your employer.)


BBoard Lingo

Peter G. Neumann <Neumann@CSL.SRI.COM>
Wed 16 Jul 86 21:18:22-PDT
From the Weekend section of the Washington Post, Friday, 11 July 1986,
on a page by Hank Burchard (Weekend at Home) devoted to home computing:

           Blitz Course in Bulletin Board Lingo [Excerpts]

  ARCHIVE -- Archiving is a method of compressing programs to have their
  original size, which makes them much faster to transmit on a modem.  Since
  nearly everything in BBS program files is archived, an ARC(hive) coding/
  decoding program is one of the first things ou should look for when
  cruising bulletin boards; "download" a copy for your own use.  Don't use
  any AC program with a number higher than 5.12.  AC5.13 and AC5.14 have
  been reported to be system-sabotaging Virus and Trojan programs.

  SOFTWARE SUCKER -- The bane of sysops [SYStem OPerators].  Suckers are
  people who sign on to a board for one reason: to copy programs.  They will
  download any program they find, whether or not they have any use for it,
  meanwhile tying up the line.

  TROJAN HORSE -- One way to crash a BBS.  A Trojan Horse is an innocuous-
  looking origran that when run reformats your harddrive, destroying all your
  files.  To protect yourself against this, ask the store where you bought
  your computer, or an experienced computing friend, for a Trojan detector
  program.  One very good one is called "Check4Bomb".  Put every program you
  download through this before you run it.  This won't catch every bad
  program (the inventors tend to be ingenious) but it will stop most of them.

  VIRUS -- A virus program is a relative of a Trojan horse, but is usually
  inserted in a proven program.  Users are often less suspicious of well-known
  programs.

    [I toss this one in for good measure.  The RISKS OF BBOARDS are rampant,
     but so are the RISKS OF OVERSIMPLIFICATION.  PGN]

Please report problems with the web pages to the maintainer

Top