Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
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 $$.
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
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
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.
"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
language!"
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
endeavor.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(tekecs!andrew.tektronix@csnet-relay) [ARPA]
[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]
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
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]
> 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
false.
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