dc@sci.UUCP (D. C. Sessions) (05/03/91)
In article <1259@grapevine.EBay.Sun.COM> chrisp@regenmeister.EBay.Sun.COM (Chris Prael) writes: [Prefatory discussion deleted] # One of the grossest conceptual errors of well intended designers is the # idea that it is useful to constrain a programmer to do the right thing. # While it is demonstrably useful to harness, bridle, and blinder a draft # animal, it is just as obviously disfunctional to try to do this with ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # programmers/engineers/designers. Tools that control the programmer can ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # only do so by disabling. The result is not a technician forced to # behave like an engineer but a hobbled technician. # # Chris Prael This may be obvious to some, but if so I'm just not with it. I've been designing electronic hardware for the last 20 years, and one of the great improvements in the trade has been the advance in tool intelligence. By that, I mean that the design tools we're starting to use now catch human errors at the design-entry stage rather than the design-checking stage -- a *vast* improvement in productivity. I've used the free-for-all kind of tools (schematic capture, PWB layout, C, etc.) only to have to rewind as much as a day's work when I caught an error. (And yes, I *do* make errors. I'm even learning to admit it.) I don't *want* tools which blithely assume that if I connect two outputs, or route a trace too close to a pad, I must have had a good reason. The same applies in software; I would much rather the compiler do all of the picky consistency checks it possibly can, because: 1) compilers don't get fried on caffiene and exhaustion at 0300 when the crunch is on; 2) compilers are *never* too busy to attend to details; 3) compilers are *never* so sure they got it right that they don't need to check it again; 4) compilers are *never* so familiar with what they *intend* to do that they can't see the flaws in what they *do*. I sure do. Go home, look in a mirror, and try to say that you don't. I understand where you're coming from. I'm lucky I haven't gone bald from the hair I've torn out in fights with inflexible tools. No doubt about it, Pascal could drive you crazy trying to work around its limitations. The solution is *not* to go back to coding in absolute binary! (Does anybody remember Doug Lee?) The solution isn't even to throw caution to the wind ala K&R C. The solution *is* to fix the tools to make it easy to do things right without hacks and *possible* (but not easy) to do the occasional really weird stuff. I repeat, *occasional*. Sometimes (analogy again) we really *do* need to connect two outputs -- for instance, when there are mutually-exclusive population options. This had ****ing well better be rarely enough that the extra hassle is acceptable, or chances are you're a long way down a seriously wrong track. Take a hint. Face up to the (not always comforting) fact of human limitations. Sure, it's *possible* to do good software engineering in C. It's *possible* to do good S/E in assembler, too. It's also *possible* to design aircraft using nothing more sophisticated than a pencil and paper. (The P51 only took 120 *days* from go to prototype.) You think maybe that this justifies doing the YF22 airframe the same way? How about the YF22 software? It took the radio electronics community something like forty years to realize that they weren't so different from bridge builders that they couldn't learn a few lessons. Large portions of the digital hardware world still haven't caught on to the fact that engineering is a process that has precious little to do with the technology in use. As far as I can tell from (mostly) the outside, most of the software subculture still hasn't got a clue -- they're still busy making excuses based on how the lessons of history really don't apply to something as new and wonderful as <what they do>. -- | The above opinions may not be original, but they are mine and mine alone. | | "While it may not be for you to complete the task, | | neither are you free to refrain from it." | +-=-=- (I wish this _was_ original!) D. C. Sessions -=-=-+