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 20

Tuesday, 15 July 1986


o Risks of computer incompetence
Dave Benson
o RE: educating about RISKS
Don Lindsay
o Computer Literacy (RISKS-3.19)
Ron Morgan
o ... and Basic
Martin Minow
Andrew Klossner
o Dial-up computing
Sterling Bjorndahl
o Research programs that pay for themselves
Clayton Cramer
o Info on RISKS (comp.risks)

Risks of computer incompetence

Dave Benson <benson%wsu.csnet@CSNET-RELAY.ARPA>
Fri, 11 Jul 86 12:43:42 pdt
Regarding who is responsible for computer mistakes:  The individual or
organization who sold/licensed the software is (or should be) responsible
in the eyes of the law.

In civil engineering, and a few other engineering disciplines, this
responsiblity is dealt with explicitly by professional licensing by the
state governments.  Unfortunately, there is no professional registration for
software engineers in any state. (If you know of one, please do let me know.)

The registration as a professional engineer has the same sort of effect as
the licensing to practice medicine--a public statement of at least a minimal
competence and a certain small amount of protection in case mistakes are made.

Not much is going to improve until the citizens agree that such a licensing
procedure is necessary and software purchasers are willing to pay the extra
cost this will cause--in essense, that they are willing to pay extra for
lower risk.

JAN Lee and other educators might take the tack that the first course in
computing is the beginning of a professional degree program.  One course
does not establish competence in any other field.

However, just as I need not have a professional registration in civil
engineering to design and build a shed in my backyard, so I need only a
little "computer literacy" to write a large range of truly useful,
small-scale software.  Since the results are not that remote from immediate
experience, there is little risk.  For example, a small program which makes
pie charts can have the output quickly checked for accuracy.

A far greater concern is that most of the B-school BASIC hackers do not
understand the mathematics underlying the calculations made in their small
economic prediction models.  Now there is a far greater risk that the model
will produce wrong results, either from software misdesign or from a failure
to understand the limitations of the mathematical model.

A BA or BS from a modern American university should never be taken as a
license to practice.  It is a minimal certification that the graduate
learned something, but no guarantee of competence.  Indeed, to obtain a
professional registration as an engineer requires several years of practice
as "engineering associate" under the direct guidance of an experienced,
registered engineer.  Surely the same effect holds in Business
Administration, Software Engineering.  It certainly does in Medicine as the
new MD is required to intern before licensure for private practice.

None of this social mechanism applies to the truly large-scale software
systems used in commercial and military practice today.  The means of
establishing low risk for any large project (software, nuclear power
reactor, SDI, etc.) are imperfectly understood.  I believe that it requires
the right sort of organization, a particular commitment to quality which
used to be exemplified by NASA.  But I certainly couldn't tell you just what
the characteristics of such organizations might be beyond high morale and
lots of $$.

RE: educating about RISKS

Thu 10 Jul 86 12:09:30-EDT
Steven H. Gutfreund stated a problem:

    How do I make a person aware that his course of action
    contains risks which he is underplaying or not cognizant of?

Speaking as a parent, I believe in letting the kid touch the hot stove.
(Yes, I really did.)  Speaking as a software engineer, I believe that
humor is the only effective way to communicate anxieties to students.

There are several reasons why storytelling works. For one, it sugar-coats the
lesson. It makes the point more memorable. It creates the (lesser)
anxiety of becoming the butt of peer amusement. And, for some students,
it seems to be the only way to give them any appreciation of why they
they should change their ways.

Don Lindsay

Computer Literacy (RISKS-3.19)

Ron Morgan <osmigo1@ngp.UTEXAS.EDU>
Mon, 14 Jul 86 23:46:14 cdt
As a certified all-level teacher, I'd like to say a word or two about the
current "computer literacy" craze. First of all, there seems to be this
constant desire to equate "computer literacy" with "programming," which
ignores the fact that probably 90% of the people who use computers are *NOT*
programmers. Programming is a profession, just like welding or accounting or
dentistry. Courses in programming are by their very nature pre-vocational
courses, regardless of whether or not they are intended as such.

Don't get me wrong; I'm not against courses in programming. A semester of it
should be required of all secondary students, to give them an idea of what
makes a computer tick, as well as giving them an awareness of what a proper
program (stylewise) is; hopefully, they will become good software critics,
at least. Students that feel an interest in becoming professional
programmers should be all means have access to advanced courses that teach
good style, preferably in a structure-sensitive language like Pascal. It
would be a waste not to do so, in light of some of the young geniuses we are
seeing more and more often these days. I know of more than one "high school
hacker" that has written his or her own "bulletin board" program in
*self-taught* assembly language, on such machines as the TI 99/4A and Atari
800. Recently, I talked with a 16-year-old boy that wrote a program linking
two IIe's for use in running a bulletin board as a *dual-CPU* system. Sure,
give these kids what they want. I'm all for it.

However, for the average Jack and Jill student, the emphasis, in my opinion,
should be on developing a wide range of solid skills in USING computers.
That's basically what "computer literacy" is supposed to be preparing them
for, right?  A society that USES computers, not a "society of programmers."
I say give them courses in *real* word-processing, setting up spreadsheets,
integrated applications, graphics design, telecommunications, music
synthesis, database management, printer codes, statistics programs, and so
on. Such knowledge, for the average student, would be far more useful, both
vocationally and personally, than ten tons of required programming courses.

Ron Morgan

osmigo1, UTexas Computation Center, Austin, Texas 78712
ARPA:  osmigo1@ngp.UTEXAS.EDU
UUCP:  ihnp4!ut-ngp!osmigo1  allegra!ut-ngp!osmigo1  gatech!ut-ngp!osmigo1
       seismo!ut-sally!ut-ngp!osmigo1  harvard!ut-sally!ut-ngp!osmigo1

Basic (a flame)

Martin Minow, DECtalk Engineering ML3-1/U47 223-9922 <minow%pauper.DEC@decwrl.DEC.COM>
11-Jul-1986 2112
I — and a number of my friends and collegues — have written large
numbers of high quality Basic programs.  These programs have been
reliable, suitable to their tasks, maintainable, and efficient.

Thirteen years ago, I published a paper on writing "professional"
programs in Basic (Decus European Symposium, London 1973).  Very little
of what I said there was particularly original: it is the sort of stuff
I was taught when I learned to program way back when.

Basic has the great advantage of being easy to learn.  The concepts
of arithmetic and control flow seem quite natural, in many ways simpler
than "structured" languages such as the descendents of Algol 58.

More importantly, Basic (Dec's RSTS/E Basic-Plus) was the first language
I worked with to offer immediate feedback for syntax errors and easy
incremental development.  I dearly wish the people who demean Basic
would invent a tool which suits their tastes, but retains the
simplicity and user-friendliness of Basic.

[...] Come to think of it, it might be interesting for the Risks subscribers
to compare the relative risks-to-society of a simple, intuitive langauge
such as Basic against the more elegant, but harder to use, language such as
ADA (or even Pascal).

Martin Minow.

Re: RISKS-3.19

Andrew Klossner <andrew%lemming.gwd.tek.csnet@CSNET-RELAY.ARPA>
Fri, 11 Jul 86 08:00:00 PDT
    "Writing hundreds of BASIC programs won't teach you very much
    about good programming style.  In fact, if you did write
    hundreds of BASIC programs, one might suspect you hadn't
    learned the most important things at all — which might even
    include the lesson of learning to look for a better programming

This sort of chauvinism has no place in the RISKS forum.  BASIC, like
any tool, has excellent utility in its domain.  For example, a
complicated graphics display can be programmed easily in ANSI BASIC-86,
which has a standardized statement level binding to an appropriate
subset of the GKS Graphical Kernel Standard.

By now we should be beyond the point where we laugh at any language
other than our favorite as being unsuitable for any serious programming

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (tekecs!andrew.tektronix@csnet-relay)  [ARPA]

Re: RISKS-3.19

Andrew Klossner <andrew%lemming.gwd.tek.CSNET@CSNET-RELAY.ARPA>
Tue, 15 Jul 86 07:33:18 PDT
   [PGN responsed to AK:
   However, the intrinsic pitfalls of BASIC are such that you might be very
   foolish to use it in a critical application.  I have used several popular
   BASIC programs that can't even give reproducible results!]

You'd be hard put to come up with a commonly-used language for which
this isn't true.                              [Nonreproducible?  Yuk.  PGN]

But your original statement didn't concern itself with critical
applications.  You spoke of any situation in which someone had written
hundreds of programs.[*]  In a RSTS DP shop, popular a few years ago on
PDP-11s, BASIC was the only reasonable language available, and it was quite
suited to the task.  In educational software development, where target
systems are characterized by inexpensiveness and availability of BASIC, that
language must be used if code is to be portable.
                        [* from the RISKS point of view, of course...  PGN]

The point is that a knee jerk reaction that BASIC, or any single language,
is inherently unsuited for any field of application smacks of elitism.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (tekecs!andrew.tektronix@csnet-relay)  [ARPA]

Basic and critical systems

Peter G. Neumann <Neumann@CSL.SRI.COM>
Tue 15 Jul 86 21:34:28-PDT
This topic generated quite a few replies.  The intent of my original comment
was of course RISKS related.  Certainly, a skilled and careful programmer
can write excellent Basic programs, and a sloppy programmer can write bad
programs in any language.  But Basic has many intrinsic pitfalls that could
make it harder to use in developing critical systems — lack of modularity,
abstraction and type safety, the presence of GOTOs (PLEASE let us not start
that controversy again — GOTOs are not impossible to use safely, just
easier to misuse), etc.  PGN

Dial-up computing

15 JUL 86 12:53-PST
Saturday night I dialed up to our academic computing center's VAX,  as
usual.  Later, as I sometimes do, I absent-mindedly hit the disconnect
button on my modem before logging off.  "Bad form," I said, "I really
shouldn't do that."  But I didn't worry, because I *knew* that the
network computer would log me off.  It always had in the past.
(I am a student at Claremont Graduate School.)

Sunday morning I dialed up again and found myself in the middle of the
process I had left the night before.  No login.  No password.  Just a
'$' prompt on my screen.  I had been "connected" for 13 hours.
Luckily for me, no one else had tried to dial in during that time.
Not even some youthful hacker with a machine to try out all the phone
numbers in sequence....

Checking it out on Monday with our consultants, I found that new
changes to the networking software had introduced this bug.  What
happened to me had also happened to several people with privileged
accounts a few days earlier.

Risks to the public?  My risk was basically personal.  But if someone
had gotten into high security accounts this way, the whole
installation might have been at risk.  The results of important
academic research might have been lost as well.  Or would that have
been a benefit to the public? :-)

Sterling Bjorndahl

   [We have noted previously the long-standing TENEX flaw with the similar
    effect — TENEX fails to detect line loss or hangup without logout, and
    leaves your job logged in with its port waiting for the next person to
    stumble upon it.  PGN]

Research programs that pay for themselves

Clayton Cramer <voder!kontron!cramer@ucbvax.Berkeley.EDU>
Wed, 9 Jul 86 17:30:54 pdt
> RISKS-LIST: RISKS-FORUM Digest,  Thursday, 26 June 1986  Volume 3 : Issue 13
> Date: Thu 26 Jun 86 00:08:21-EDT
> From: Richard A. Cowan <COWAN@XX.LCS.MIT.EDU>
> Subject: Research programs that pay for themselves

  [I have deleted the quote of Cowan's original message.  The response from
   Clayton Cramer is probably not relevant, but if have erred by including
   something that subsequently deserves a rebuttal, then it seems that I
   should let the flavor of the rebuttal through.  PGN]

It would be awfully good if people didn't feel they could throw any old
nonsense (or even off-topic sense) into a moderated group.  Mr. Cowan
assertions are at least arguable, and many people would even consider

  Assumption One: Crime is a result of unemployment, poor housing, and
  lack of facilities to keep young people entertained.

  Assumption Two: Unemployment can be reduced by reducing the work week.

  Assumption Three: Unemployment is a major problem.

[...]  Clayton E. Cramer

    [Clayton's message went on to counter each assertion, at some length.
     However, that seemed wholly inappropriate for RISKS readers, and thus I
     have deviated from my usual policy and truncated.  PGN]

Please report problems with the web pages to the maintainer