Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!sci34hub!sci!dc From: dc@sci.UUCP (D. C. Sessions) Newsgroups: comp.lang.misc Subject: Re: Formal definitions (Re: ada-c++ productivity) Summary: Warning alarms going off Message-ID: <969@mgt3.sci.UUCP> Date: 9 Apr 91 19:31:01 GMT References: <4ebGltlf1@cs.psu.edu> <27FB56D8.6176@tct.com> <1991Apr8.080931.23209@netcom.COM> Reply-To: dc@mgt3.sci.com (D. C. Sessions) Organization: SCI Technology, Inc., Huntsville, Al. Lines: 103 The same old arguments are always dragged out to justify bad workmanship, whether in software, hardware, or carpentry. This time around, we're hearing them from Morgan Schweers. Nothing personal, but they set of some major BS alarms. In article <1991Apr8.080931.23209@netcom.COM> mrs@netcom.COM (Morgan Schweers) writes: # In article schwartz@groucho.cs.psu.edu (Scott Schwartz) writes: # >It worries me. It also worries me that you aren't worried. # > # This is because you see everything in terms of 'theory' and not # 'practice'. (Inferred from your various comments.) I'm not a theory person # either, so it doesn't really worry me either. The point is that if I can get # somethine to *WORK* then to hell with all the theory in the world. I routinely get the same argument when I show someone a design violation in a circuit design: "Hey, it works! Who cares about some theoretical problem?" Of course, I can't *prove* that a transient error was due to substrate injection resulting from pin overdrive. Since I can't prove it, let's forget the whole thing, right? # I don't need a language to be formally accepted, or formally tested, to # write code in it. I do the testing on my program. If the compiler breaks it, # I'll worry about it. If the compiler doesn't break my code, whassamatter with # it? Translation: "It worked; ship it!" # I'm a systems programmer, so decide before you respond, if your language # (probably supposedly universal across all implementations, if I know you theory # weenies) will do the job for what I consider real work. Is this one-downmanship? I'm one step down from a systems programmer: I design the stinking HARDWARE your stuff runs on. Why don't you REALLY get down and dink with the *voltages* like I do? Bits are for wimps. The same arguments are used universally to justify spending a lot of time on the easy problems of micro-optimizing the 5% instead of making sure the 95% works reliably. # >| At some point, you have to stop assuring and start doing. # > # >Sure. That's the argument in favor of dynamic typing that has been so # >well received here recently. What I'm suggesting is that providing a # >formal specification of a language is the software engineering analog # >of using things like parser generators and static type checking. Yes, # >no system is perfect, but gee, why make it harder on everyone? # # YOU are the one looking to make things harder. Software Engineering? Get # real. Perhaps it's the bad associations I've had with people calling # themselves Software Engineers (they worked in Ada, Modula-2 and COBOL), but # Software Engineering For Better Programs is nonsense. If you have a language # that makes it possible to 'prove' the program correct, then you have a language # which is probably putting too many restrictions on the programmer. We used to hear this argument from radio hobbyists who would grab the old breadboard, a handful of tubes, and a soldering iron and DISCOVER a circuit. I trust it as much as I trust a bridge which was built by sticking together available beams however the designer thought they fit well. # Also, to me, a formal specification consists of a grammar, and a # description of the basic keywords. Period. At that point, the language is # defined in terms of what I can use it for. What do you mean by a 'formal # specification'? Don't give me math crap. I'm a programmer, not a math # junkie. I'm glad you know from the grammer and keywords what would happen if you executed c = f( c, c = g( c ) ); but frankly, I'd like to know that the results wouldn't change with the compiler version. # *IF* you can make me more productive, I'd look at what you were talking # about. The important point here is that *I KNOW WHAT I'M DOING* That's funny; so did the carpenter who cut before he measured. I'm glad that there are at least two infallible humans in the world. As for the rest of us, we make occaisional mistakes and some even appreciate having those mistakes caught early in the cycle rather than late. # and I don't # want a language that told me I didn't. I could program in Pascal or some other # psuedo-useless language if I wanted that. (I have a friend who is forced to # program in Pascal. You should hear him scream for type-casting!) # The point is that there are tradeoffs involved, and that there is *NO WAY* # you are going to design a language that will be both completely useful and # completely 'safe'. The two are incompatible, in my (admittedly limited) # experience. Prove me wrong. Feel free. # -- Morgan Schweers Sounds like Goedel's Theorem. But I forgot; that's for math weenies. -- | 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 -=-=-+