Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!pacbell.com!tandem!netcom!mrs From: mrs@netcom.COM (Morgan Schweers) Newsgroups: comp.lang.misc Subject: Re: Formal definitions (Re: ada-c++ productivity) Message-ID: <1991Apr12.073314.9415@netcom.COM> Date: 12 Apr 91 07:33:14 GMT References: <1991Apr8.080931.23209@netcom.COM> <969@mgt3.sci.UUCP> Organization: McAfee Associates Lines: 142 Some time ago dc@mgt3.sci.com (D. C. Sessions) happily mumbled: > > 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. > Acceptable. I don't consider low-level work to be bad workmanship, while you clearly do. The major difference between what you are talking about and what I am talking about is levels of ABSOLUTEs. If I have an implementation of a compiler that won't allow me to use a feature of a system, then that compiler is (by my definition) broke. If there is a language which has features to 'prove' that the program does what it's supposed to do, then the odds are that that language can't allow system- dependant features. Am I wrong? Tell me why. >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? > Can you reproduce it? Can you demonstrate it? If you can, then you can trace it. This is true in software, but I don't know about hardware, having never worked on the low-hardware level. ># I don't need a language to be formally accepted, or formally tested, to ># > > Translation: "It worked; ship it!" > Interesting translation. I'd like to know what language you were translating. It's my opinion that a product should work in ALL cases before you ship it. It's also my opinion that this cannot be proven on a systems programming level, since the variables are far too complex. (As an example, we have one program which can't be used in a certain mode with certain other programs, because they use memory in an odd way. Could this have been proven to happen? Heck no. Could a 'formal' language prove that we can successfully use the disk to swap in portions of our code during runtime? Heck no. Am I wrong about this? Someone feel free to tell me of a method that will tell me (just from looking at my source) that if I'm running in memory, and another program swaps in to do some system checking that there will be a memory conflict between the two. Assume, as is the normal case, that I don't have the sourcecode to program X. Do you even think that there is a language in which this *IS* possible? IMO, hell no.) ># > > 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. I respect hardware people as much as I disrespect theory weenies. (I really did use that word, didn't I... Oh well.) Theory is, IMHO, for people who want to be paid for not doing real work. If you theorize for weeks, and come up with a new language for a problem (but not an implementation of it, oh no!) that could be solved in ten minutes with an existing language, then you are (by my, admittedly small-minded definition) not getting any useful work done. IF, on the other hand, you design and IMPLEMENT a new language that has applications beyond one problem, is useful, allows low level access across a multidude of platforms, can be optimized reasonably at the executable level, and doesn't impose heavy burdens on the user, *THEN* you're getting some use out of your theory. The theory-folk (I'll try to avoid 'weenies', okay?) I've met in the past (and the 'software engineers') tend to REALLY hate getting their fingers dirty. That's why I don't have much respect for them, I'm afraid. It's also why I have a lot of respect for hardware engineers, especially on the bit-level. They get their hands dirty constantly. They *WORK*. > 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. What arguments of mine supported this? A formal language won't allow either. (An optimization of the time-consuming 5%, *OR* a real-world test of reliability.) So what's your point? ># ># # explanation of the keywords> ># > > 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. > Really? Pick any language that allows you to do system level work, and I'll show you a language that returns different values on different systems. It's up to the programmer to know what's different between a language on a bitty-box and a language on a large system. *UNLESS* the programmer is working in a field where the system-level information isn't important. ># *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. > Never claimed to be perfect, never will. Just don't be stupid, and claim that formally defined languages are perfect. You'll be wrong. There *ARE* tradeoffs. > > Sounds like Goedel's Theorem. But I forgot; that's for math weenies. Yeah, it does doesn't it. Well it is similar, in fact. Attempts to 'formalize' a math system which is powerful, have yielded Godel's theorem. That is that the system cannot be fully powerful, yet completely formalized. To flame for a second, "Get a clue from Godel's Theorem, theory-people! You cannot completely formalize a language without having holes!" Thanks, I hadn't though t about Godel's theorem the first time through. -- Morgan Schweers +-- One other person where I work would understand this. I'll recommend him to this group, and see what he thinks. Everyone else is Non-Computer People. -- mrs@netcom.com --+