Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!news!nujoizey!gwu From: gwu@nujoizey.tcs.com (George Wu) Newsgroups: comp.lang.c++ Subject: Re: Static typing, OOP efficiency, and programmer error Message-ID: <1881@news.tcs.com> Date: 15 Mar 91 02:22:32 GMT References: <27CE9C05.4F64@tct.uucp> <1860@news.tcs.com> <47199@nigel.ee.udel.edu> Sender: root@tcs.com Reply-To: gwu@nujoizey.tcs.com (George Wu) Organization: Teknekron Communications Systems Lines: 75 In article <47199@nigel.ee.udel.edu>, carroll@cis.udel.edu (Mark Carroll) writes: |> In article <1860@news.tcs.com> gwu@nujoizey.tcs.com (George Wu) writes: |> ] I would consider this sort of run-time error checking inadvisable for |> ]commercial products, to say nothing of mission critical applications, |> ]although I'm sure there are people out there using Objective C and Smalltalk |> ]for commercial systems. It simply isn't a good idea for a sold product in |> ]customer hands to crash with an error. (Yeah, I've seen commercial systems |> ]core dump, too. :-) It's just easier to have high confidence in software |> ]which does as much error checking as possible at compile time. Of course, |> ]if one just performed exhaustive testing before releasing a product . . . . |> ] |> |> I think that you're missing something fairly important here. |> |> The fact that Objective-C is primarily dynamically bound does not mean |> that it is any less safe than a fully statically bound language in the |> general case. |> |> Most of the time, Objective-C is used in a way which could be trivially |> translated into a fully static language like C++. In those cases, Objective-C |> COULD catch any of the errors which C++ could catch. (I don't know if the |> Stepstone compiler actually does, but by using dataflow analysis to bind |> statically whenever possible, any of the errors that could be caught statically |> in C++ could be caught statically in Objective-C. Objective-C just transfers |> the burden to the compiler, rather than the programmer.) |> |> In other cases, when you are expressing something as a message pass that |> could not be expressed as a member function call in C++ (i.e., using the |> perform: method), you are doing something "less safe" than you would in |> C++. You understand the crux of my concerns, but you fail to address them. It is the fact that there *are* (exist) "less safe" capabilities is what makes dynamic binding objectionable. |> But those cases are easy to identify in the code, and by scaffolding |> them inside of a safety test (low budget assertion testing...), you can |> insure that they will indeed execute safely. This too only skirts the real issue. It is my contention the user of a commercial product should never encounter an "assertion failed at . . ." or "internal error" message. So the product doesn't dump a core file, great, but if this code had been statically bound and checked, the entire situation would never have arisen! |> Basically, I think this whole mess comes down to this: |> Static versus dynamic binding is a matter of personal taste. It is, at that. |> I personally very much prefer to work with a more dynamic language. I think |> that my programs are much more elegant written in a dynamic style, and I |> think that my code written in a dynamic language is much better than my |> code written in a static language. So, when I need to use a C-family language, |> I'll stick with Objective-C. If you like static programming, you'll think |> that I'm out of my gourd, that I'm a fool, or whatever, and you'll stick |> with your static language. I think your priorities are different. One's mental state is rarely indicated by choice of programming language . . . usually. :-) George PS: This line of argument does not contend that C++ applications never encounter run-time errors. If only . . . . :-) ---- George J Wu, Software Engineer | gwu@tcs.com or uunet!tcs!gwu Teknekron Communications Systems, Inc.| (415) 649-3752 2121 Allston Way, Berkeley, CA, 94704 | Quit reading news. Get back to work.