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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c406e0c4a6eb74ed X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!proxad.net!newsfeed.stueberl.de!news-mue1.dfn.de!news-ham1.dfn.de!news.uni-hamburg.de!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: Fri, 10 Sep 2004 09:28:03 +0000 (UTC) Organization: GMUGHDU Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> <87eklg62x8.fsf@news.bourguet.org> NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1094808483 20056 134.91.1.34 (10 Sep 2004 09:28:03 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Fri, 10 Sep 2004 09:28:03 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: g2news1.google.com comp.lang.ada:3559 Date: 2004-09-10T09:28:03+00:00 List-Id: jayessay wrote: : Georg Bauhaus writes: : :> jayessay wrote: :> :> : Yes, and they don't happen at runtime if pre and post are checked :> : during incremental development. If you don't do this, then you will :> : likely have problems - just like if you don't get the types right in :> : static languages. :> :> Is it really much more time efficient, if pre and post checking is done :> by an incrementing human? If so, how much? : : Generally, yes. For two general reasons: 1. you are always sure of : the logic as well as the type consistency Yes, within the limiting conditions of parameter values of a suitable type. : 2. You don't have global : "system integration" issues as each incremental step subsumes an : integration aspect. OK. Similarly. :> : Your explanation above does not cover the logic error. I don't see :> : right off how modular types catch that. :> :> See below, there isn't a logic error, only a typo. : : No, I'm not talking about the typo in the advance function. I'm : talking about the logic error in the Hext function itself! That's your interpretation of the "hext" function as given in the Lisp example. :> In the Lisp example there was a "typo context". "next" should have :> been where "hext" was actually typed in the Lisp example : : That's not the logic error. The logic error is that Hext is broken : due to the incorrect expression at the line noted above. It is broken WRT your interpretation of its undocumented purpose. It is not a broken Lisp function at all and might reflect a specification precisely. It could as well have been (defun hext (n) (+ offset (mod n 16))) (What has made you think otherwise? :-) or even ;; hext: string -> string (defun hext (n) (extract-h-from-oldstyle-german-th-word n)) ;; make Thor from Tor etc. With the same typo leading to the discovery of the error only a run time or test time. :> Therefore, an integer number was actually wanted ("next"), not :> a hex number ("hext"). (In fact at the point of definition of "advance", the programmer will likely have been aware of the "next" function, but not of a "hext" function. The test might have revealed the existence of the "hext" function in the first place. (I do like surprises sometimes, as they also make you see things that you might have missed before :-) Now consider a situation where there are no two similarly named functions in the environment, with similar results, both producing values of the same Lisp number type, and both consuming arguments of the same number types. I think that a static type system like Ada's, if used, will likely catch a logic error at compile time, that is when by mistake one function is used where the other should have been used. This is because a value of a type being in 1 .. 10 will not be compatible with a value of another type's 1 .. 10. The program will not have to be run to find out, at least there is a chance for this to to be found out prior to surprises at run time, even if not every case can be handled by compile time type checking. ; old Rome (defun 1-to-10 (n) (random-even 1 10)) ; ... (defun 1-out-of-10 (n) (test-status parts-of-town n)) (set-on-fire (1-to-10 3)) ; should have been 1-out-of-10 -- Georg