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