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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.125.37 with SMTP id mn5mr15759783obb.49.1406519590066; Sun, 27 Jul 2014 20:53:10 -0700 (PDT) X-Received: by 10.182.56.228 with SMTP id d4mr216636obq.5.1406519589691; Sun, 27 Jul 2014 20:53:09 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h18no9029588igc.0!news-out.google.com!px9ni0igc.0!nntp.google.com!h18no9029555igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 27 Jul 2014 20:53:09 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.57.209.48; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 173.57.209.48 References: <72b1318a-2eb6-4129-af9b-5bcfbb329c5b@googlegroups.com> <3dcb7839-3003-4fcd-afb6-3369f715102b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <15b0a58a-4e62-4e10-9e20-b0a6afd71c6d@googlegroups.com> Subject: Re: Ada's ranking of popularity at IEEE Spectrum From: "Dan'l Miller" Injection-Date: Mon, 28 Jul 2014 03:53:09 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:21305 Date: 2014-07-27T20:53:09-07:00 List-Id: On Sunday, July 27, 2014 3:19:40 PM UTC-5, sbelm...@gmail.com wrote: > My point is that even 'good' APIs (like OpenSSL or OpenGL) inherently sti= nk of untyped C, and it becomes > a delicate balancing act of figuring out at what point you've failed to i= mplement the spec everyone > knows and instead succeeded at inventing a new (better) API that nobody w= ants. Victor Porton's copious > posts seem to suggest similar problems. It does seem that the burning issue to solve in Ada202X is how to facilitat= e making thick bindings easier 1) to bring the Ada semantics to an Ada API that wraps a C (or subset of C+= +) API; then 2) export that Ada API back out to C (and/or subset of C++) via a thin bind= ing that imposes as much type safety as possible. By dividing and conquering the C world (i.e., into 2 camps: type-unsafe C = APIs used by the unwashed masses versus type-safe C APIs used by superior i= ntellects), Ada could prove itself valuable as an intermediate layer and wi= n over converts to just program in Ada all the time.