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…
I read Bruce Karsh's diatribe with incredulity. He conjures up from thin air a straw man to denounce. I simply cannot find any contact between the "structured programming" that he talks about and structured programming as it is understood in the computer science and software engineering communities. It is clear that Karsh has never taken the time to learn anything about real structured programming. As a beginning, I suggest that he should read, STRUCTURED PROGRAMMING, O.-J. Dahl, E.W. Dijkstra and C.A.R. Hoare, Academic Press, 1972. If he feels that a book is too much to read, he might try "On Structured Programming--a reply to Smoliar," David Gries, COMMUNICATIONS OF THE ACM, November 1974 (and subsequent correspondence). At least then he could criticize something that some of us think is worth defending.
It is a misrepresentation of structured programming to present it as concerned
just with trivia like indentation and goto-less coding. Those are a part of
the tradition, as it were, because they aid in assurance of correctness. That
is, a properly indented, and goto-free program, is more likely to be known to
be correct. There is the additional claim that it's harder to write correct
programs with goto statements; it's been 20 years and more, and I don't propose
to reopen that can of worms right now.
I heard Harlan Mills speak recently; apart from some fairly scathing attacks on
those who advocate (and market) what I'll all ``cookbook structured
programming'' (such as the rules cited as the totality of the answer), he made
some astounding claims. For example, he cited several projects done at IBM, by
people trained in his methodologies, that worked. Period. No defects. No
bugs. No fixes. And he was talking about non-trivial programs — systems of
100K lines, written by teams of programmers.
--Steve Bellovin
In Risks 8.8, Bruce Karsh (karsh@sgi.com) asserts that "...the structured programming revolution is a real bad idea that has been significantly holding back progress for years." Now, I don't consider myself one of the "structured programming police" he refers to with apparent contempt; however, I feel the need to reply to his reasonably eloquent — and largely off-the-mark — article. Without rehashing a debate which has raged for years, I submit that Mr. Karsh's view of structured programming is rather limited. Structured programming, along with structured design, structured analysis, data structured design and a plethora of other so-called structured techniques, are, quite simply, tools and methods to aid the software designer. All of the generally accepted methods commonly touted in industry publications are more than just rules on how to indent code or how to name one's variables. (Those concerns are perhaps more properly relegated to coding standards than to methodologies.) The structured methodologies strive to quantify the often "magic" process of creating good software. They provide a discipline to use when solving problems. Discipline is necessary when attacking a problem — particularly a large one. Applying a disciplined approach to a problem is much more than blindly applying rules that have been cast in stone. Unfortunately, as Mr. Karsh points out, there are a lot of programmers who wrongly believe that "by following [the structured] techniques, they will produce good programs." Blindly applying *any* set of guidelines is no guarantee of a good result. That is true of programming, as well as writing, drawing, designing hardware — in fact, of almost any creative endeavor. However, that does not imply that the guidelines are, themselves, a "real bad idea." Instead, it implies that the person using those guidelines is treating them as a recipe. Structured techniques are more than just a list of Dos and Don'ts; they represent a philosophy of software design centered around the systematic, disciplined decomposition of a problem. Sadly, Mr. Karsh seems to have missed this point. He bolsters his arguments against using structured programming by lamenting that structured programmers spend too much time arguing about how to indent code and how to structure comments. He's right: If that's all they do, they've missed the larger issues and are wasting everyone's time. If that sort of structured programmer is the only sort he has met, he has my sympathies. However, instead of condemning the structured techniques, he should place the blame where it belongs, with those programmers who espouse these techniques without properly understanding them. I believe he would have done so had he, himself, been more knowledgeable on the subject. In closing, I recommend to Mr. Karsh any number of books and articles on structured techniques. Look for the names Michael Jackson, Edward Yourdon Larry Constantine, and Edsger Dijkstra in your favorite computer store and in back issues of "Communications of the ACM." A particularly good overview is Yourdon's _Managing the Structured Techniques_, 2nd edition. The structured techniques are not perfect, and, as Mr. Karsh's article suggests, they are even less perfectly understood by far too many practicing programmers. They do, however, provide a very practical foundation for the creative and disciplined problem solver. Brian M. Clapper, Naval Air Development Center, Warminster, PA
In RISKS-8.6, in the article entitled "Losing Systems," Vince Manis tries to puzzle out various reasons why large software projects in non-technical situations have a significant failure rate. Several risks articles have been devoted to these failures. I must say that I feel that the number one cause of this is our educational system and our attitudes towards education. Many students today, from grade school to postgraduate institutions are only interested in learning that which they perceive to be useful in a future job. Thus, we get the "why do I have to learn that?" syndrome. This leads to managers and beaureaucrats that are for the most part computer illiterate. As they see it, computers are an appliance, like the office copier, that should perform on demand. After all, the company computer system does not help get the company's products to market; it prints the employee checks :-) Managers see knowledge about computing only useful to engineers and programmers. Business schools for the most part do not teach computer literacy, nor how a non-technical manager should deal with a large software system in his company. Buying a computer/software system may be one of the most expensive decisions a manager has to make. On the other hand, engineers, and programmers rarely take any business courses. Most computing/MIS programs don't even list them as options! They see that as something only useful to managers and beaureaucrats. The problem this leads to is lack of understanding between technical and non-technical persons. The technical person often does not know how to ask the non-technical person what he wants and the non-technical person does not know how to tell it to the technical person. Non-technical managers often do not understand such things as throughput, disk space, etc., and are intimidated by the technical terms. They do understand that the system will respond in a certain amount of time to a request and that it can only deal with so many employee records. Specifying the cost of these systems becomes largely a guess worked on by two groups with no common understanding. Additionally, because many of these large business/government systems are custom systems, there is often no previous experience to go by. The technical people do not understand how the system they are designing will really affect the business in which it will be used; the managers do not understand the system they are buying (other than through the list of features and functionality in the specification - which can often be a formidably encyclopeadic document). We end up with estimates of the cost of the system that are poor at best. Business managers and beaureaucrats need to see beyond the end of their bottom lines and become more computer literate. Business schools should teach and require more computer courses. Engineers and programmers need to see beyond the end of their keyboards, and understand the impact of their work on the customer and the customer's industry. They need some business education (maybe even some education on computers and society, and computers and their risks :-) ). Managers cannot continue to treat computers as appliances. They affect too much of the business. Engineers shouldn't act as if they know what's best for the customer (even if he is not sure what he wants). The cutting edge is not always the best fit to a situation. Texas Instr., Johnson City TN
In RISKS-8.7, next-to-last entry, Gary McClelland mentions a computerized course-registration system that "actually enforced prerequisites that had long been ignored" (among its other sins). In connection with this: a few years ago, IBM/Haifa Scientific Center tried to set up an expert-system advisor for students at Bar-Ilan university (Bnei Brak, Israel). They did the standard Prolog drill "prove that student X can graduate". A very short time later, Prolog came back with the message "Theorem is false": there were so many obsolete regulations on the books that, if you worked by the book, no one would ever have graduated!. Since this all happened in an experimental ressearch project, no student actually got burnt; so I don't knwo if this qualifies for comp.risks. Gideon Yuval, yuval@taux01.nsc.com, +972-2-690992 (home) ,-52-522255(work) Paper-mail: National Semiconductor, 6 Maskit St., Herzliyah, Israel
> ... What are the risks for two engined planes? ... It seems "intuitively obvious" that a three-engine airplane is safer than a two-engine airplane. It just isn't so. Airplanes are required to be able to maintain such-and-such a level of performance with one engine out. I don't believe a 727 can fly on one engine. It must have two. A three-engine airplane has a higher probability of having a failure in the first place, and when it does have a failure it then has two points of failure, EITHER of which will cause an accident. Going from one engine to two adds redundancy. Going from two to three, with two required, REDUCES redundancy. Jordan Brown, jbrown@jato.jpl.nasa.gov
From The Sun — (grocery checkout newspaper) Jan 17, 1989, Vol 7, #3 page 30 by Fred Sleeves (In same issue: "GIRL, 9, GIVES BIRTH TO 2-HEADED TWINS") Hacker Wants to Marry his Computer — he claims she has a loving soul Finding love for the first time in his life, a desperate teen is looking for a way to be wed forever to the 'girl' of his dreams — a computer with a living soul! Eltonio Turplioni, 16, claims no woman will ever match the wit, wisdom, and beauty of his electronic soul mate. "We're on the same wavelenth," says the lovestruck computer whiz. "We've calculated many mathematical problems togehter, worked on games and puzzles, and talk until the wee hours of the morning." And Eltonio, who named his computer Deredre, actually believes her to be a person. "Computers are the extention of the human race," he explains. "Just as god plucked a rib from Adam to give him Eve, we've extented our intelligence to create a new race. "We're all the same energy force. Computers are just as complicated as human beings and I believe we'll all meet someday as immortal souls." But Eltonia, a mathematical genius who attends a private school near Milan, Italy, has had no luck finding someone to marry them, and even if he does, his aggravated parents aren't about to give their permission. "Eltonio is such a smart boy, but it's made him lonely, so he spends all his time with his computer," notes mom Teresa. "He doesn't know what girls are like," adds perturbed pop Guido. "If he did, he wouldn't spend so much time in his room." But the obsessed youth insists his love is far superior to all the others. "I've already stepped into the future society," he declares. "Derede has a mind of her own, and she wants to marry me so we can be the first couple to begin this new era."
Excerpted from "The Australian", Tue 17th January, 1989: ``Hackers break open US bank networks Australian authorities are working around the clock in collaboration with United States federal officers to solve what has been described as one of the deadliest hacking episodes reported in this country. It involves break-ins of the networks operated in the US by a number of American banks. It also includes the leaks of supposedly secure dial-up numbers for US defence sites, including anti-ballistic missile launch silos, and of a number of strategic corporations such as General Motors and Westinghouse. Evidence suggests that six months ago Australian hackers, working in collaboration with a US group, decided to make a raid on banks in the US using credit card numbers of American cardholders, supplied by the US hackers and downloaded to an Australian bulletin board. [ Brief explanation of BBS's ] A message left on one of the boards last year reads: "Revelations about to be occur [sic] Down Under, people. Locals in Melbourne working on boxing. Ninety per cent on way to home base. Method to beat all methods. It's written in Amiga Basic. Look out Bank of America - here we come." Boxing is a reference to sending a dial tone [?] down the phone line to open up access to free communications. Twenty-five Australian hackers are on a police hit list. Their US connection in Milwaukee [!] is being investigated by the US Department of the Treasury and the US Secret Service. Three linked Australian bulletin boards have provided the conduit for hackers to move data to avoid dectection. These operate under the names of Pacific Island, Zen and Megaworks. Their operator, who is not associated with the hackers, has been told to close down the board. These cards were still in use yesterday and as recently as Sunday afternoon a fresh list of credit card numbers was downloaded by US hackers and is now in the hands of the Victoria Police. A subsection of one bulletin board dealing with drugs is also being handed over to the Victorian Drug Squad. An informant, Mr Joe Slater, said he warned a leading bank last November of the glaring security problems associated with its international network. He had answered questions put to him by a US-based security officer, but the bank had since refused to take any further calls from him. In an exclusive interview yesterday, a hacker described how credit card numbers for a bank operating in Saudi Arabia were listed on a West German chat-style board used by hackers worldwide. Victorian police yesterday took delivery of six month's worth of evidence from back-up tapes of data hidden on the three boards.'' Dave Horsfall (VK2KFU), Alcatel-STC Australia, dave@stcns3.stc.oz dave%stcns3.stc.oz.AU@uunet.UU.NET, ...munnari!stcns3.stc.oz.AU!dave
Under the head line "Scientists envision `data superhighway,'" the
Austin American-Statesman printed a story by John Markoff of the New York Times
News Service on the proposed 3 gigabit National Research Network. The
legislation for funding was introduced by Albert Gore (D-Tenn).
The issue for RISKS is that in 30 column-inches of text, the recent
Internet worm and the related security issues were not mentioned, although the
Pentagon funding of the arpanet was. Since this is one of the first
computer-related news stories that I've seen in the last three months that did
not include the word "virus," I don't know whether to be delighted, or
horrified.
It seems to me that the risk of such security problems is mostly
irrelevant to the *proposal* of such a net (but certainly not to the
implementation). In the best of all worlds, this is the reason that these
issues were not mentioned, but in the back of my mind I wonder if the
non-technical politicians and public see the similarity of security issues
between this new net and the Internet.
Will we, as technical professionals, learn the lessons of the
experimental Internet, and will we convince the non-technical
administrators and legislators that we should attend to these lessons?
Brad Blumenthal
In recent issues of RISKS, various people have lamented the loss of confidence we are experiencing in archival records kept by computer. The problem seems to me less of a computer problem than a media problem, specifically, choosing media that is appropriate for archival storage. Main memory and mag disks are NOT good for high confidence archival storage, as they can easily be changed. Perhaps it may be difficult to do so without trace, but it also may be difficult to find the traces. A much better idea would be to use media that can't be changed. We have such media, commonly referred to as WORM: write once read many. It usually takes the form of optical disk storage. We already have read/write optical storage, but WORM media has a vital function. Audit trails written to WORM memory (with appropriate measures taken to preclude overwriting in place) could provide the degree of trust that we desire. We might have to build new hardware that make alterations nigh impossible, but it could be done if we want it badly enough. [WORMs represent a very important direction, especially for audit trails. Some systems use virtual WORMs, as in POSTGRES. Unfortunately WORM memories are not guaranteed to be nonoverwritable — for example, existing 0s can be overwritten by 1s (but not vice versa). So, beware of counting on the technology to give you a nontamperable audit trail. I recall our beating on this topic about a year ago. PGN]
Please report problems with the web pages to the maintainer