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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!postnews2.google.com!not-for-mail From: kevin.cline@gmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: ADA Popularity Discussion Request Date: 10 Sep 2004 16:12:54 -0700 Organization: http://groups.google.com Message-ID: References: <49dc98cf.0408110556.18ae7df@posting.google.com> <1092233689.719755@master.nyc.kbcfp.com> <2nutq5F4sdqqU1@uni-berlin.de> <5ksXc.22738$_H5.696424@news20.bellglobal.com> NNTP-Posting-Host: 198.23.26.253 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1094858030 30017 127.0.0.1 (10 Sep 2004 23:13:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 10 Sep 2004 23:13:50 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:3572 Date: 2004-09-10T16:12:54-07:00 List-Id: "Warren W. Gay VE3WWG" wrote in message news:<5ksXc.22738$_H5.696424@news20.bellglobal.com>... > Brian May wrote: > >>>>>>"Marc" == Marc A Criley writes: > > Marc> Ada's enforcement of strong typing and runtime checks points > > Marc> out when a programmer has made a mistake, whether as a > > Marc> result of requirements, design, or coding error. (Of course > > Marc> no one is suggesting that Ada would catch all requirements > > Marc> or design errors--that's a ridiculous > > Marc> mischaracterization--but when errant reqs or design lead to > > Marc> a particular implementation, internal contradictions may > > Marc> result in type conflicts or constraint errors.) > > > > Ada has a lot of rules which you have to comply with when > > programming. I suspect some programmers find these rules obscure, > > weird and limiting[1]. These people prefer the freedom in other > > languages like Perl where there is infinity+1 ways of doing the same > > thing. > > > > Personally, if I make a mistake, I want to find out sooner rather then > > later, and this requires good compiler time checking. Even if the > > program is not a mission critical program. Ada is the language I know > > with the highest level of checks at compile time. > > Agree completely. > > > There is the argument that languages like PHP are best for quick&dirty > > prototypes. The counter argument is that these quick&dirty prototypes > > often evolve into the one complicated mess of code that everyone > > relies on. > > This reminds me of Perl. I have always maintained that Perl > has its place, but not in "production". But there are millions of lines of Perl serving web pages reliably every day. When I was at DSC we used Tcl/Tk to build production GUIs for telecom switch control, and found it about ten times more productive than building Motif GUIs in C++. Customers were very happy because we could redesign the GUI to meet their needs interactively. No compiling or linking -- just make the change and go. Reducing line count by programming at a higher level is an effective way to reduce the bug count. It's possible to find libraries for C++ or Ada that will provide the built-in features of Perl, but relatively few development projects bother to use them. Instead programmers laboriously and incorrectly hand-code things like string manipulations that could be done correctly in Perl in a few seconds. > > I can't understand the trend in the other direction towards languages > > like PHP, if you make a typo in a function name for instance, you > > won't realize until that like of code is executed, and even then you > > might miss the error message (for instance if it is not on screen). If your Ada code raises Constraint_Error, you won't realize that until you execute it. I don't see the big difference between a Constraint_Error and a missing function error. Since the compiler can't catch all the errors, I still have to test. And if I'm going to test anyway, trivial errors like misspelled function names will be discovered pretty quickly. > I have to say that for most applications, I would rather > have as much static analysis done up front as possible. This > substantially reduces the need for testing for non-mission > critical things. I'm skeptical of this argument. Are you saying that you have no problems delivering code that has never been tested? I have learned to write the tests first just to make sure that I know exactly what I'm trying to do before I start doing it. And since every line of code is tested, static analysis doesn't add much. If it slows down the test execution so that I have to wait idle for more than a few secondes, then it breaks the flow and is more of a distraction than it's worth.