duncan@dduck.ctt.bellcore.com (Scott Duncan) (04/07/89)
In article <7800@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: > >On the subject of the usefulness of theory to nonacademic practioners, >I was convinced long ago that a good dose of automata and formal >language theory is important to programmers. Not the latest results, >which too many departments want to focus on, but the fundamental >results of Turing. I certainly agree, in general, about the usefulness of theory to the practi- tioner. I wouldn't want to debate which ones, but an understanding of the underpinnings of the applied part of the "science" certainly seems to me to be information that a person _could_ choose to make use of effectively on the job, if only to expand the range of their thinking about design issues, etc. And, certainly, the fundamental results are what would be important to non- research-bound people. > I remember with fondness the light that came on >in my student's eyes when I was able to convey to them that following >an algorithm can be expressed as yet another algorithm, which is >behind the Universal Turing Machine notion and from which so much of >software stems. These were not theoretical types, but future applica- >tions programmers. To learn to love or be fascinated by the background of one's applied field seems to me to be a responsibility of education (certainly "higher" education). I can't say, but do wonder, if some of that hasn't been lost. >I'd like to teach computer science genetically, starting by having >people write Turing machines, then machine language, then assembler, >then high-level language. The only textbook I've seen which approxim- >ates this approach is COMPUTERS AND PROGRAMMING: A NeoClassical >Approach, which may no longer be in print. It's by Peter Olivieri >and Alan Rubin, I think. It was the last book to use a mythical >machine. The career focus of so many students, coupled with the >idiotic hiring practices of companies, make students loth to learn >mythical machines or even Turing machines, because "nobody uses >that in the real world". I think because the issues of software design are not as clear as, say design of basic electronics components, we don't feel the TV-repair school of prog- ramming is a serious education in computer science. However, they do exist, lots of people in business data processing have come and continue to come through them, and they are not likely to go away. Software design remains a "cottage craft" because the end-product of the design and implementation is instant product, no manufacturing step occurs in between. Programming languages can cause a computer to do just about anything you want. And anything you want to do (figuratively speaking) can be done in many ways. Thus, there are LOTS of choices to be made in design. Bad choices often end up working "good enough" to get the job done because their impact is not felt immediately. It may take years of maintenance and enhancement effort to see the flaws emerge. I would encourage colleges and universities to formalize their efforts to teach software design -- not as in formal theory but as in making it more officially clear that design is being addressed. The "practical" knowledge of programming can be incorporated as part of the "engineering" education which teaches how to work within the constraints of the medium. That is, physical materials only do a few things before they break, rot, etc. Languages, again, can be forced to do almost anything, but the bad design aspects of this need to be pointed out to people. Just getting a programming project to run and produce the "right" output is a goal of early undergraduate training. One would hope that later in one's aca- demic career, good design choices are being taught. To counter industry's demand for programmers who just know the tools and can get down to writing ap- plications, etc., we need to be able to show how superior design practice will lead to superior quality software and to improved productivity. I don't think we have come close to doing that (on either the academic or industry side). Many companies sense this is the better path, but it is clear people can "get by" without as much concern for long-term design. The collapse of a software system rarely occurs with the same dramatic (and, more importantly, publically visible) effect as does that of a bridge or building. Thus, the design flaws of software are often hidden for years (forever?) because software flaws gen- erally make something ELSE appear to have failed or broken down. To borrow from the old "tree in the forest" physics question: If a program crashes at night, and no user sees it, is there a failure? Speaking only for myself, of course, I am... Scott P. Duncan (duncan@ctt.bellcore.com OR ...!bellcore!ctt!duncan) (Bellcore, 444 Hoes Lane RRC 1H-210, Piscataway, NJ 08854) (201-699-3910 (w) 201-463-3683 (h))
reggie@dinsdale.nm.paradyne.com (George W. Leach) (04/11/89)
In article <15192@bellcore.bellcore.com> duncan@ctt.bellcore.com (Scott Duncan) writes: >Many companies sense this is the better path, but it is clear people can "get >by" without as much concern for long-term design. The collapse of a software >system rarely occurs with the same dramatic (and, more importantly, publically >visible) effect as does that of a bridge or building. Thus, the design flaws >of software are often hidden for years (forever?) because software flaws gen- >erally make something ELSE appear to have failed or broken down. To borrow >from the old "tree in the forest" physics question: If a program crashes at >night, and no user sees it, is there a failure? Apparently it has become an acceptable practice in this industry to get something out the door. So what if features must be dropped. So what if there exist some known bugs. Meet the deadlines and get the product out. Is this really any different from the short term thinking that permeates our political system? In large companies, people remain with a project for a relatively short time. By meeting your short term goals you can earn a promotion that takes you away from worrying about the long term implications of short term oriented decisions. The product and the company suffer, but the individual does not. This goes for software developers as well as managers, product planners, etc...... There are certain life critical applications where software is becoming increasing important, eg. medical, defense, etc.... In these areas one could easily see the potential for disaster and law suits someday. George W. Leach AT&T Paradyne .!uunet!pdn!reggie Mail stop LG-129 reggie@pdn.paradyne.com P.O. Box 2826 Phone: (813) 530-2376 Largo, FL USA 34649-2826