gudeman@arizona.edu (David Gudeman) (08/22/89)
In article <9015@june.cs.washington.edu> kolding@june.cs.washington.edu (Eric Koldinger) writes: >... >Why? Just because someone doesn't want to be a CS major doesn't mean that >he/she doesn't want to learn to program, or have need to program. What about, >for instance, engineering majors who often have to design large programs, but >aren't CS people, per se? You know a few years ago, I wouldn't have even noticed that last sentence. Since then I've had occasion to read a lot of code that wasn't written by Kernighan and Richie or other high-quality professionals, and have been appalled at how bad programming is out there. I have also had occasion to teach programming, and was surprised to find out how hard it seems to be for a lot of people. They just can't seem to grasp the concepts of modularity, reusability, maintainability, internal documentation, or simple elegance. I guess it's been so long since I went through that stuff, that I don't remember what a trial it was to learn. Perhaps more important is the idea of using efficient data structures and algorithms. I've seen functions consisting of nothing but a huge switch statement: switch (i) { case 0: return "0"; case 1: return "1"; case 2: return "2"; ... where the constraints on i clearly allowed the use of an array instead. I've had a discussion where I pointed out to someone how to turn a O(n^2) algorithm into a O(n) algorithm with the same constant factor, and he said it was a clever hack, but not worth implementing because "computers are getting faster all the time." He had been complaining about the speed of the O(n^2) algorithm, but he didn't seem to believe there would be much difference. I've seen a set of functions for handling linked lists, that all use the same global variable for list traversals. This has brought me to the conclusion that the era of non-professional programmers has past. The programming discipline has advanced to the point where it really does take four (or more) years of in-depth study to become competitive in the field. Would you expect an electrical engineer to design a car? A mechanical engineer to design a microchip? If not, then don't expect either one to design software either. -- David Gudeman Department of Computer Science The University of Arizona gudeman@arizona.edu Tucson, AZ 85721 {allegra,cmcl2,ihnp4,noao}!arizona!gudeman
tneff@bfmny0.UUCP (Tom Neff) (08/22/89)
Koldinger's point is correct, Gudeman's is actually arrogant. Every good engineer understands elegance of design. (Programmers as a class not only don't have a corner on that market, we're not even big players.) What a good engineer may not necessarily share with a programming whiz is that peculiar aptitude for solving the little symbolic mind puzzles which 20th century orthodoxy has decided epitomize "elegance" in programming. A few do share it, of course. However to the extent one is a good and useful engineer, time spent being an "elegant" programmer is time misused. It's not what they train and pay engineers to do -- however often they end up having to do it anyway these days. I know this, if I go halves with my draftsman's night school tuition so he can move up to steam boiler design, he had damn well better spend those nights learning his steam tables and not trading clever "C" functions with CS kids! The really complicated stuff (from a software design standpoint) which nonetheless does basic things from an engineering point of view (like CAD/CAM or project documentation systems) should be written by professional programmers -- and in fact already is. Engineers just consult in the design, since they are supposed to know what they want. (Do they? Separate issue :-) ) But the simple stuff (from a CS standpoint) that does complicated engineering things (like beam stress, structural analysis, fluid dynamics etc) should be programmed by engineers, with whatever CS professional support is required to keep from wasting the engineers' time worrying about peripheral stuff. And "elegance" is peripheral. The easiest-to-write program that gets the right answers (now AND later) is central. I am not saying that FORTRAN is the best of possible languages for engineers to use, in fact it wastes their time on just some of those peripheral things we don't pay them for, like worrying about how an EQUIVALENCE statement's going to work. But some language should exist, FOR engineering, such that its basic structure isn't offensive to modern understanding of how programs work (as BASIC and FORTRAN often are), yet it is directly usable in the engineering workplace once you know the whole language. Maybe Ada is it, I don't know. I get the sense that if so, it's not quite ready. When micros beef up to the point where any engineering student can afford a PC that runs Ada, you might see it. Even then FORTRAN would have to be learned because there is decades' worth of backlog to support (and believe me, some of these FORTRAN number bangers have been running the same program for 20 years or more! If it ain't broke...). But it would be an advanced elective for those who anticipate working (or find they need to work) with old code. Surely if you taught the right language to begin with, FORTRAN would be easy to pick up as a sideline later. Guess I ran on - they got me started. :-) -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
cik@l.cc.purdue.edu (Herman Rubin) (08/22/89)
In article <13380@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: > In article <9015@june.cs.washington.edu> kolding@june.cs.washington.edu (Eric Koldinger) writes: > >... > >Why? Just because someone doesn't want to be a CS major doesn't mean that > >he/she doesn't want to learn to program, or have need to program. What about, > >for instance, engineering majors who often have to design large programs, but > >aren't CS people, per se? ...................... [Several examples of bad algorithm design are given] > > This has brought me to the conclusion that the era of non-professional > programmers has past. The programming discipline has advanced to the > point where it really does take four (or more) years of in-depth study > to become competitive in the field. Would you expect an electrical > engineer to design a car? A mechanical engineer to design a microchip? > If not, then don't expect either one to design software either. I agree that bad algorithm design is a major problem. But the current teaching of professional programmers, and even programming consultants, is worse. I do not see that the gurus do that well. If the designers of the languages were not that arrogant, and asked those who do understand what they want to compute and how hardware affects it, we would not have the atrocious languages of today. I know of a professional programmer who told a former colleague of mine that to compute the numerical value of an integral it was necessary to use a numerical integration procedure. Now in this case, the quick and dirty formula I gave him was of comparable speed to using a highly optimized method to compute ONE function value. Recently, a language guru's comment on an algorithm to compute a specific function, not writable in C or any other HLL to my ken, that I should profile the behavior and find the places most used instead of using a program based on machine instructions. There is one conditional branch in the program, based on an "overflow" bit, which involves a quick adjustment. Every other instruction is executed a fixed number of times. Profiling, indeed! I keep hearing that computers are getting so fast, etc. I keep telling my students that they must do analysis before numerical analysis. Yet the push is to develop packages which an ignoramus can use, but which provides little more for the skilled artist. The so-called good programmers cited by David Gudeman really have not done all that well. In programming something well, it is necessary to take into account what is being attempted. A professional programmer may do a good job at producing an editor, or possibly an assembler. But a programming language which is good for people doing mathematics, no. This effectively means that the mathematician must be the programmer. The engineer who programs is being an applied mathematician, not an engineer at programming time. As such, he knows what the program is supposed to do. If he understands the machine, he will have a very good idea of how to do it well. But will the language let him wihtout working hard? -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)
gudeman@arizona.edu (David Gudeman) (08/23/89)
In article <14577@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes: >Koldinger's point is correct, Gudeman's is actually arrogant. Several responses suggest themselves: (1) I can't be arrogant since I don't have any faults. (2) Gee, I didn't know expressing an opinion was a sign of arrogance. (3) It's been so long since I was active on the net, that I forgot about the recreational flamers. You know, the people who lie in wait for an incautious wording so they can assume the worst possible reading and insult you for it. >Every good engineer understands elegance of design. I wasn't talking about engineers when I mentioned people who couldn't understand elegance, I was talking about students in classes I taught. If you had read the article with the assumption that I was a reasonable person, I believe you would have understood this. Why don't you try an expirement? Next time you read an article that you think is arrogant, stupid, or insulting; take a step back back and try reading as though it was written by a respected friend of yours. You might be surprised at how the meaning changes. For example, take response (1) above. Did you read it as a joke? If not, you should really rethink your attitude of people in general. Sure, I _could_ really be so obnoxiously arrogant as to have meant it, but why would you want to think that about me? Wouldn't life be more pleasant if you gave people the benifit of the doubt and always assume they are reasonable whenever there is no compelling evidence otherwise? -- David Gudeman Department of Computer Science The University of Arizona gudeman@arizona.edu Tucson, AZ 85721 {allegra,cmcl2,ihnp4,noao}!arizona!gudeman
tneff@bfmny0.UUCP (Tom Neff) (08/24/89)
In article <13433@megaron.arizona.edu> gudeman@arizona.edu (David Gudeman) writes: >In article <14577@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >>Koldinger's point is correct, Gudeman's is actually arrogant. >(1) I can't be arrogant since I don't have any faults. The point was arrogant, not the person. I'm sure Gudeman in person is a prince of a fellow; I know the rest of us are. Assertions, not authors, are properly addressed in this newsgroup. I am not sure how clear this distinction would have had to be made in order to avoid Gudeman's above quoted misinterpretation, but I apologize for omitting the needed overkill. ;-) >(2) (3) [ditto] > >I wasn't talking about engineers but Koldinger was - I address both points of view. [ remaining silly flamage omitted - back to the point of the discussion ] The arrogance of the point was its implication that programmers know what elegance is and (e.g.) engineers don't. This ain't so. -- "We walked on the moon -- (( Tom Neff you be polite" )) tneff@bfmny0.UU.NET
peter@ficc.uu.net (Peter da Silva) (08/25/89)
In article <13380@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: > Would you expect an electrical > engineer to design a car? A mechanical engineer to design a microchip? > If not, then don't expect either one to design software either. What about problems that are well understood by the mechanical engineer and poorly understood by the software engineer? While the mechanical engineer's program is likely to be less efficient, it's more likely to actually produce the correct result. Which is, after all, the bottom line. Even if you have the Mech E working with a CS guy to develop the program, the Mech E guy is still going to have to know enough about programming to provide realistic specifications and guidance. Either he's going to have to have some formal training in CS or he's going to have to learn on the job. You seem to have a preference for formal training... -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'" -- Tom Neff 'U` "I didn't know that ksh had a built-in APL interpreter!" -- Steve J. Friedl
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (08/25/89)
From article <5868@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva): %> Would you expect an electrical %> engineer to design a car? A mechanical engineer to design a microchip? %> If not, then don't expect either one to design software either. > > What about problems that are well understood by the mechanical engineer > and poorly understood by the software engineer? [...] Even if you have > the Mech E working with a CS guy to develop the program, the Mech E guy > is still going to have to know enough about programming to provide > realistic specifications and guidance. The software engineer has to carefully identify all assumptions and check them out with the domain expert, but there is no need for a domain expert to have to learn programming or CS. By the time the software is written, the software engineer will HAVE to understand the "problems" to be solved, with every bit of that knowledge stated precisely to and verified explicitly by the domain expert. Requirements analysis and specification is part of the software engineer's job, and the subject is covered extensively in software engineering texts. Bill Wolfe, wtwolfe@hubcap.clemson.edu
barmar@think.COM (Barry Margolin) (08/25/89)
In article <5868@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >What about problems that are well understood by the mechanical engineer >and poorly understood by the software engineer? While the mechanical >engineer's program is likely to be less efficient, it's more likely to >actually produce the correct result. Which is, after all, the bottom line. I'm somewhat doubtful. Non-professional programmers are likely to write simplistic programs. They will probably work properly in common situations, but many non-pros don't have experience in incorporating features such as robustness. They'll make assumptions about library routines (e.g. they'll use gets() of scanf() in C when reading input from the user, and be surprised when they don't perform as expected). On the other hand, a programmer alone won't understand the problem domain well enough to write the program well. What's needed is a partnership. The mech-e should write a spec, or perhaps make an initial stab at the program if he has some programming experience. Then the programmer takes over, refining the spec or program, getting clarifications from the mech-e, etc. I tend to think of the programmer as working for the mech-e, turning the latter's ideas into a fully-featured and robust program. Had Voyager been programmed by astronomers, it wouldn't have made it to Neptune. Had it been programmed by programmers, it might have made it but wouldn't have sent back as much useful information. But I'm sure it was programmed by a team that included experts in both areas, and now we're seeing the benefits. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
gudeman@arizona.edu (David Gudeman) (08/30/89)
In article <5868@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >In article <13380@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: >> Would you expect an electrical >> engineer to design a car? A mechanical engineer to design a microchip? >> If not, then don't expect either one to design software either. > >What about problems that are well understood by the mechanical engineer >and poorly understood by the software engineer? While the mechanical >engineer's program is likely to be less efficient, it's more likely to >actually produce the correct result. Which is, after all, the bottom line. It seems that I didn't express myself very well in the original article. I was refering to the practice many groups have of hiring non-software engineers to do software engineering. They seem to think that anyone who "knows how to program" is a competent software engineer. I only meant to say that _that_ assumption is no longer true, as it probably was twenty years ago. I "know how to design an I.C.", but anyone who hired me to do it would be foolish. On the other hand, it would be completely reasonable to hire me to consult in the design of a new architecture aimed at specific software. As far as formal education, I hate to sound "arrogant", but I've seen the work of some people who had lots of experience in programming with little formal education. It wasn't pretty. My reaction cannot be professional bigotry because in most of the cases I learned the programmer's background _after_ I had formed a rather low opinion of their programming ability. My experience is rather limited and may not be typical, but it stands to reason that there is a lot of information about software engineering that will not be "picked up" on the job (except by geniuses and people who do a lot of professional reading). But to be honest -- I've not always been impressed with the quality of work done by "trained professionals". And I never meant to imply that non-professionals should not be taught to program. That would be as silly as saying they should not be taught mathematics. I _do_ think their programming education should center around very high-level languages that do most of the grunt work for them. Just as engineers are not required to learn (much) meta-mathematics, they should not be required to learn about memory organization, registers, and machine instructions. If a program is so time critical that it has to be written in a low-level language like FORTRAN, C, or Ada, then it should probably be written by a professional. -- David Gudeman Department of Computer Science The University of Arizona gudeman@arizona.edu Tucson, AZ 85721 {allegra,cmcl2,noao}!arizona!gudeman
peter@ficc.uu.net (Peter da Silva) (09/01/89)
The following is a straw man. I'll get back to that later. In article <13573@megaron.arizona.edu>, gudeman@arizona.edu (David Gudeman) writes: > As far as formal education, I hate to sound "arrogant", but I've seen > the work of some people who had lots of experience in programming with > little formal education. It wasn't pretty. Turnabout is fair play. I've had the project I was working on killed because it was put at the mercy of a "software engineer" with more degrees than a circle. This gentleman was so sure he was better equipped to do the job that he dumped two months of my work and spent the next six months trying to reproduce it using his formal tools. We ended up missing a real deadline. The project dropped dead. > But to be honest -- I've not always been impressed with the > quality of work done by "trained professionals". Precisely. Back to my first comment. This is a straw man because I'm not suggesting that we abandon formal training. I'm making the claim that it is appropriate for a non-CS major to take CS courses. Real CS courses, not just 4GLs and Hypercard. > Just as engineers are not required to learn (much) > meta-mathematics, they should not be required to learn about memory > organization, registers, and machine instructions. I disagree with both sides of this statement. Software engineers should have some good fundamental mathematics, and anyone who writes any kind of software should spend some time working close to the silicon. > If a program is so > time critical that it has to be written in a low-level language like > FORTRAN, C, or Ada, then it should probably be written by a > professional. There are other reasons for coding in a low level language. Sometimes that's all you've got. -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' 'U` "How many humans does it take to change a light bulb?"