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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.99.66.199 with SMTP id p190mr3632063pga.20.1481974600160; Sat, 17 Dec 2016 03:36:40 -0800 (PST) X-Received: by 10.157.11.120 with SMTP id p53mr420696otd.19.1481974600110; Sat, 17 Dec 2016 03:36:40 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!news.redatomik.org!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!newspeer1.nac.net!border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!75no1016422ite.0!news-out.google.com!u18ni2409ita.0!nntp.google.com!75no1016419ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 17 Dec 2016 03:36:39 -0800 (PST) In-Reply-To: <877f6y3lzo.fsf@nightsong.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=78.192.88.225; posting-account=21X1fwoAAABfSGdxRzzAXr3Ux_KE3tHr NNTP-Posting-Host: 78.192.88.225 References: <5f542dff-8dd0-49b8-8228-3ccc8248c57d@googlegroups.com> <276a2153-b81f-4e19-9615-530e798e5798@googlegroups.com> <1533893062.503569684.598007.laguest-archeia.com@nntp.aioe.org> <877f6y3lzo.fsf@nightsong.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: C# new features (v.7) From: Hadrien Grasland Injection-Date: Sat, 17 Dec 2016 11:36:40 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32903 Date: 2016-12-17T03:36:39-08:00 List-Id: Le samedi 17 d=C3=A9cembre 2016 11:09:49 UTC+1, Paul Rubin a =C3=A9crit=C2= =A0: > Luke A. Guest writes: > > Yup. Need to get younger people excited but seems only a few of us > > actually see this. >=20 > Younger programmers (those who didn't grow up dealing with old slow > machines with little memory) generally use lower performance but more > convenient languages rather than C, Ada, etc. They're protected from > integer overflow by bignums, memory errors by bounds checking, > alloc/free errors by garbage collection, etc. Lots of very good > developers shipping successful products have never programmed in > anything but Javascript or Python or Ruby. When I try to "sell" Ada to people used other languages, the main benefit t= hat I usually invoke is that in Ada, you can leave much more of the debuggi= ng work to your toolchain. That the language, by design, makes it harder to= write erronerous code, and easier for a computer program to detect it, Tha= t argument is usually well received, as no one likes manual debugging, whic= h is why there is a clear trend towards more automated static and dynamic a= nalysis tools these days. Javascript, Python and Ruby developers go through a lot of debugging pain b= ecause the interface of libraries written in this program is severely under= specified. For example, there is nothing in the actual code telling you or = the compiler/interpreter that a function is designed to take strings as inp= ut, and will blow up somewhere deep in the implementation if passed an inte= ger. The developer writing the function has no way to know what we will get= as input, and the one calling the function has no way to know what it expe= cts as output. It is all based on fragile conventions between developers, t= hat are at best documented through code comments or external documentation,= which will become out of date on the first refactoring. Every attempt in p= rogramming language history to handle type mismatches automatically without= developer help, as in PHP and Javascript, has been an unmitigated disaster= . C++ templates have exactly the same problem, for exactly the same reason: t= he interface to them is implicit, not explicit, and most importantly the co= rresponding interface requirements are implementation-defined. No C++ compi= ler is able to produce a good template debugging error message simply becau= se the required information to do so wasn't written in the code by the deve= loper. The only point where a C++ compiler knows that template instantiatio= n fails is where the implementation conflicts with the type parameter that = was passed to the interface. Everyone has a dream that one day, someone will devise a programming langua= ge that enforces the use of explicit, well-specified interface, that can be= easily checked by compilers and analyzers in order to detect and report to= ns of developer errors automatically. It just so happens that today, Ada is= the closest aproximation of this dream in existence.