From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: Bart Samwel Subject: Re: What is wrong with OO ? Date: 1997/01/13 Message-ID: <32DA59E5.167E@wi.leidenuniv.nl>#1/1 X-Deja-AN: 209534606 references: <32D11FD3.41C6@wi.leidenuniv.nl> <5bba0q$fbr@mulga.cs.mu.OZ.AU> content-type: text/plain; charset=us-ascii organization: Dept. of Math. and Comp.Sci.; Leiden Univ.; Leiden; the Netherlands mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng x-mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP22) Date: 1997-01-13T00:00:00+00:00 List-Id: Fergus Henderson wrote: > Usually, people do manage in the end, but then again most software > produced today is full of bugs. Usually it works well enough only > because it has been carefully tested and debugged, but usually it will > fail when exercised in novel ways. Choice of programming language is > certainly not the only or the most important factor in this, but I do > think that it can make a significant difference. I certainly agree! The reason I like Eiffel so much is that it has language support for pre- and postconditions, class invariants, loop variants and invariants and in-code assertions, which are closely linked to the exception mechanism. In alpha, beta and gamma releases, one can compile with a specific subset of these assertions tested at run time, so that when a program is used in a way it didn't expect and wasn't prepared for, the program generates an exception. With the compilers I've seen so far, this results (when no exception handler is installed) in displaying of the call stack and the precise class and feature name in which the exception occurred, and the name of the assertion that failed. Because of this language support, many of the Eiffel programmers use these assertions throughout all of their code. They do this because they know that when something goes wrong, they will more often know exactly _where_ things went wrong, and _what_ went wrong, without debugging. > Yes, but I think one part of that comprehensive process should be > ensuring that programmers do know the language rules that govern the > behaviour of the language features that they use. (It's not too > important for a programmer to know about the tricky cases if the > compiler will catch them, but it is important to know about possible > pitfalls that would not be caught by the compiler and would instead > result in undefined or implementation-dependent behaviour at runtime.) And indeed, C++ does have many of these pitfalls, IMHO anyway. There are languages available that are able to catch many more of these pitfalls. One of the reasons these languages can catch these pitfalls better than C++ can is that they are a bit more constrained than C++, which is not necessarily a Bad Thing. Bart