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,FREEMAIL_FROM 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!proxad.net!npeer.de.kpn-eurorings.net!news.tele.dk!news.tele.dk!small.news.tele.dk!not-for-mail Sender: malo@0x5358ceb2.boanxx18.adsl-dhcp.tele.dk Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request References: <49dc98cf.0408110556.18ae7df@posting.google.com> <6F2Yc.848$8d1.621@newsread2.news.pas.earthlink.net> <1094529422.982635@yasure> <_xl%c.431$xA1.301@newsread3.news.pas.earthlink.net> From: Mark Lorenzen Date: 08 Sep 2004 00:21:16 +0200 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: TDC Totalloesninger NNTP-Posting-Host: 83.88.206.178 X-Trace: 1094595676 dtext02.news.tele.dk 183 83.88.206.178:20022 X-Complaints-To: abuse@post.tele.dk Xref: g2news1.google.com comp.lang.ada:3453 Date: 2004-09-08T00:21:16+02:00 List-Id: jayessay writes: > "Richard Riehle" writes: > > > One of the benefits of assertions (DbC) is that one can simply > > declare a range of unacceptable conditions as part of the design > > and be assured that those conditions will not be permitted to > > occur. > > There is nothing about this that is incompatible with dynamic typing. > If you wanted you could implement the whole Eiffel Dbc thing (and then > some) as a set of macros using CLOS within Common Lisp. As I recall > now, someone actually did this (I will try to find it). > > > > Moreover, a well-designed program must be about more than simple > > correctness, even as hard as that is. > > Agreed (if for no other reason than what "correctness" means is > typically vague - even in very well designed and specified systems.) > > > > In particular, as the deployed design is required to deal with the > > real world, it must be able to adapt itself to the unexpected. > > This is a particularly apropos aspect of systems built with dynamic > systems. Evolvable and adaptable are key descriptors. > > > > Let me give you an example. In am system I know something about, > > one with a large number of components, a programmer included a > > routine that had a built-in constraint (not a type constraint), in > > the form of an if ... end if statement. The constraint was cleverly > > written and the language in use was not strongly typed, so the > > Just to be clear "not strongly typed" and "not type safe" have nothing > to do with dynamically typed. > > > > but the test scripts (well-designed) did not catch the error. When > > it occurred, the system failed, and no one knew why until a > > considerable amount of analysis was performed. > > Also, just for clarity, are you saying you believe static typing would > have made a difference here? You can dream up plausible scenarios > where it might have but equally plausible scenarios it wouldn't have. > I actually think dynamic typing would be significantly more > efficacious here (if not any more than static typing in prevention, > then certainly in immediately pinpointing the problem). > > > > Finally, I truly hope that no Lisp programmer, Smalltalk enthusiast, > > or their ilk will persuade the designers of flight avionics to begin > > using those languages. > > I'm not advocating this - mostly because I don't think this domain > needs the kind of flexibility and expressiveness that comes from Lisp. > This stuff belongs to a very well bounded and concretely defined > domain. > > > > It is bad enough that some of them have chosen to use C and C++. We > > need to, as always, select the right tool for the job at hand. > > This, OTOH is just implicitly cast FUD, presumably intended to imply > that something like Common Lisp would not "work well" here. I will > absolutely make the claim that such an offering would be every bit as > robust and "correct" as anything fielded. It is likely it would also > be rather more maintainable. More maintainable? The pieces of LISP code you have shown so far are even less readable than French. It does not communicate any information about the problem domain to the reader, it is just a clever hack used to save some keystrokes. Why oh why do they continue to teach LISP in the US? They should teach ML instead. > > Maybe you are simply saying that the resources available here are > still just too small to make this a viable option. I'm sure there are > still a lot of things out there with just a few kilobytes available. > Then again, Garmine has some pretty impressive boxes and last I looked > Avidyne was still using WindozeNT/2000(!!!) as its base. > > > /Jon > > -- > 'j' - a n t h o n y at romeo/charley/november com Regards, - Mark Lorenzen