No doubt JAN Lee's colleagues in other departments think that the literacy course is simply propaganda to improve the image of computer science and programming as serious (and difficult) work. It's a pity that it can be so easy to get a program to APPEAR to work and that most people are satisfied with apparent success. After all, a screwdriver almost looks like a chisel, and it does almost as good of a job, at least for a while. I think Weinberg had an anecdote in "Psychology of Computer Programming" about how some DP types tried to show their managers how hard programming was by making them do some trivial BASIC programs. The managers had little trouble with their programs and went away convinced that programming was even easier than they thought. There's a story that circulates around here about a BASIC program written several years ago. The program simulates household heating plants as part of a model of resource usage. It started as a Fortran program written at the research center of a large, local computer company. The company hires students for part-time work, one of which helped write the original Fortran program. Another student was hired later to re-code the program in BASIC. Since then the program has been sold to one of the gas industry associations and a copy was eventually sold to the Department of Energy. The students who worked on the program describe the style as a form of 'advanced spaghetti' and don't know whether to laugh or cry at the thought of it being used to plan national energy policy. Rick Smith. U. Minnesota
Who should bear the responsibility for damage done by programming errors? Everyone involved; e.g. Colleges screen students for admission, give exams and require term projects for course credits, and charge tuition and fees for all that; thus colleges ultimately bear some responsibility for the credentials of their graduates. Those who over a period of time produce shoddy workers should lose their reputation, if not their accreditation. Employers hire workers, give them tasks to do, and pay them for the work; and then make profits from the sale of those products or services; thus employers ultimately bear some responsibility for the products and services of their employees. Those who over a period of time produce shoddy products or services should lose money, or even go bankrupt. Buyers seek products and services, and pay for them, so they ultimately bear some responsibility for their choices. Let the buyer beware. Last but certainly not least, individuals who study, produce, and sell must certainly bear some responsibility for the products & services they offer. Recently, Nader has lobbied through laws making individual corporate exec- utives criminally liable for obviously defective products; e.g., when it can be proved that an auto maker produced and sold cars known to contain safety faults that led to accidental failures, injury, etc., then the man who gave the order to proceed can not hide behind a corporate mask ; a corporate fine is not enough; the man may end up in jail. I would suggest then that when John Doe, a graduate of College of Somewhere, working for the Acme Corp., writes code that causes damage, his Alma Mater, the Acme Corp, John himself, and the "buyer" are jointly responsible. Because buyers can't know enough to intellengly "beware" it will be often necessary to "buy insurance" in some form; that's why most of us go to MD's that are licensed by the state, and colleges that are accredited by peer groups; and why so many computing consultants "recommend IBM." When unschooled folks set themselves up as private consultants, and hard- sell their products or services, they bear 99% of the total responsibility for the results. That might have the effect of reducing the number of freelance consultants, who charge lots of money for buzz-wordy reports. I would view that as a step forward in our industry. The good ones would not only survive, they would prosper - and be easier to find. Finally, how can a professor convince the dean that one programming course is not enough? We can start by telling folks that since "IBM can teach you to program in FORTRAN in three days" it does NOT follow that one so trained can DO real problems in any language. By analogy, the Acme Driving School may teach one to drive in three days; that does not entitle him to a special license as a chauffeur, or to drive a 5-axle rig; and certainly does not qualify him to race a Le Mans, or Indy. Maybe if we [computer folks] turn the problem around, the others can see it better; e.g., we might suggest that our computer graduates need to appreicate physics or economics, so that they can write code that will darn near dominate the future work of physicists and economists; thus we suggest that those other departments devise one 3-hour [4-hour?] course to teach them all they need to know. After the initial [angry] retort, maybe we can enter a dialogue. Bob P.s. The foregoing are personal opinions, not those of my employer.
> NOW FOR MY QUESTION: How little can we get away with in preparing students > to use the computer for problem solving and not put their eventual clients > at risk? JAN Lee's concern is misplaced. The "top-down" approach to teaching _about_ computers is overemphasized, perhaps because the phrase "computer literacy" sounds meaningful to educators. But the one absolute requisite for becoming a good programmer is to write programs, programs, and more programs--in any language, on any equipment available, in any environment. I've taught hundreds of C.S. students here. By the time we graduate them, I know which students are likely to succeed: it's those who are self- motivated. The students who are just "getting an education" write no more programs than they need to, develop very slowly, and go on to write some very bad code for their employers. The students who _like_ to program write plenty of programs, learn from experience what the others try to learn by attending lectures, find alternative computers to work on or buy P.C.s if the school computer is unusable, and tend to excel in all kinds of C.S. courses. In short, while BASIC is obviously "riskier" than Pascal, I regard the language issue as a minor one. The earlier a student starts turning problems into programs, the safer her eventual clients will be. It's futile and counterproductive to refuse to teach "just programming" on the grounds that computers are dangerous when they go wrong. Cars are dangerous, but we don't require auto mechanics to know about the thermo- dynamics of combustion engines or the social consequences of motor travel. We ask only that they be competent mechanics.
With regard to the previous message, I am in Washington this week for a conference on ensuring that a system really does what it is supposed to (COMPASS 86) and a workshop on testing, formal verification, and software engineering. This prompts me to make all sorts of comments on this issue, although they may have to wait until later. THERE IS AN ENORMOUS DIFFERENCE BETWEEN WRITING CODE AND WRITING GOOD SOFTWARE. Any damned fool can write code. It takes a particularly perverse damn fool to write software that can be trusted to live up to rigorous requirements (which might include rugged and forgiving interfaces, reliability, maintainability, understandability, reusability, security, human safety, and so on). It also takes a lot of discipline, good taste, an instinct for elegance, training, and experience. An appropriate programming language might also help (but does not substitute for the above), as might a software development methodology — if large and complex software is to be developed. The grave danger of computer literacy courses is indeed that they tend to endow BASIC or LISP or FORTRAN or C (or even Ada!) with magic properties. BEWARE OF SIMPLISTIC SOLUTIONS. 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! Allegedly "competent mechanics" have cost me hours of anguish, many dollars, and a few grave personal risks. I prefer really good, experienced mechanics who work well because they know what they are doing. If you give one an engine he has never seen before, he has to go through a learning curve -- although he will undoubtably learn much faster than the mere competent. But, the analogy is awkward — you are asking your mechanic to keep your car working safely, not to design it from scratch in the first place. PGN
Please report problems with the web pages to the maintainer