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,78a1af350f4cf4b X-Google-Attributes: gid103376,public From: Gautier Subject: Re: Win2000 has 63,000 'defects' Date: 2000/02/16 Message-ID: <38AA8210.B42E623D@maths.unine.ch>#1/1 X-Deja-AN: 586454980 Content-Transfer-Encoding: 7bit References: <38A989B7.2D4D6B56@maths.unine.ch> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Trace: 16 Feb 2000 10:53:52 +0100, mac13-32.unine.ch MIME-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-02-16T00:00:00+00:00 List-Id: Hyman Rosen: > > Someone to sell or install them poor an Ada compiler ? ;o) G. > Why do you think the defects have anything to do with the language > used to develop Windows 2000? Do you know that the defects are > coding errors, as opposed to being design errors or unimplemented > features? That's not so simple... Some coding errors may be catched at compile time in one language and appear as an bad crash on an user's screen months later when coded in another one. As complexity grows, uncatched (coding or design) bugs tend to combine with other. In some way the "shape" of a bug disappears rapidly with the complexity and the time elapsed after the coding. Some concrete examples. In the code I'm developing (a comparison of finite element methods for multiple partial differential equations) there are *lots* of coding issues that have been catched by the compiler because I'm using Ada's rich typing: simple things like exchanging the equation and node index, and so on. You forget that design features help avoiding other *bigger lots* of coding bugs. Back to the example (a tiny excerpt)... ... procedure FT_elem(gelem: t_element) is nsd: constant positive:= spatial_dimension(gelem); iel: constant positive:= nodes_per_element(gelem); nb_faces: constant positive:= faces_per_element(gelem); subtype sp_vector is vector(1..nsd); -- vecteur spatial subtype sp_matrix is matrix(1..nsd,1..nsd); -- matrice spatiale (codecond) subtype el_array is vector(1..iel); -- tableau sur un element subtype el_iarray is ivector(1..iel); -- idem, composantes entieres subtype el_matrix is matrix(1..iel,1..iel); -- matrice elementaire subtype el_grad is matrix(1..iel,1..nsd); -- gradients sur l'element ... Needless to comment! An extreme but true example: a program (some environmental predictor) had a strange crash recently. There was a line in the 15-year old Fortran code that "almost" never occured, where a variable name had 2 letters exchanged!... 2 things I'm sure of: - every mean is good to track a bug, and I prefer to have a compile-time error than a day of Sherlock-Homesque bug tracking with a debugger, after a week of disfunctionment - the bugfest tends to grow exponentially or factorially or something like that (specialists know that better) with code length (and its ratio of bugs...). BTW you can make a naive probabilistic calculation. Say you have 1000-line modules. Each of them has a probability of 0.00001 of crashing per hour because of an uncatched bug. Now you have a 30,000 module program (say Windows 2000) that uses all of them during an hour. Each module can crash or not during the hour independently of each other (a generous hypothesis since bugs normally help each other). Then, the probability of a crash for the whole program during an hour is 1.0 - (1.0-0.00001) ** 30_000 = 0.259 (26%). 8-| Gautier _____\\________________\_______\_________ http://members.xoom.com/gdemont/gsoft.htm