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 2002:a24:910b:: with SMTP id i11mr15574615ite.76.1558101164301; Fri, 17 May 2019 06:52:44 -0700 (PDT) X-Received: by 2002:aca:51d5:: with SMTP id f204mr104627oib.78.1558101163983; Fri, 17 May 2019 06:52:43 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.dns-netz.com!news.freedyn.net!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!u76no149901ita.0!news-out.google.com!p73ni126itp.0!nntp.google.com!u76no149897ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 17 May 2019 06:52:43 -0700 (PDT) In-Reply-To: <53aecf06-e2f0-48f5-a9f1-1902b6092eb5@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.234.171; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.234.171 References: <3647d776-3024-4b74-9e7e-0798e9b55079@googlegroups.com> <13c2b751-4e0e-4fc7-8a4c-010c86693284@googlegroups.com> <53aecf06-e2f0-48f5-a9f1-1902b6092eb5@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3f5d3e31-f155-45ea-b171-49eda1be281d@googlegroups.com> Subject: Re: can ada do this? From: Optikos Injection-Date: Fri, 17 May 2019 13:52:44 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4486 X-Received-Body-CRC: 3513869027 Xref: reader01.eternal-september.org comp.lang.ada:56315 Date: 2019-05-17T06:52:43-07:00 List-Id: On Friday, May 17, 2019 at 12:40:00 AM UTC-5, Maciej Sobczak wrote: > > 1 can you talk to scylla from ada? >=20 > Most likely the easiest path is to bind to the C client API, if the pure-= Ada API does not exist. Rabican, this is the recurring wise advice to you, if you are interested in= coding something in Ada up regarding Scyla. As I mentioned above, the oth= er (nonC++) languages' bindings to Scyla provide a rich amount of tutorials= that can be borrowed for Ada too. > > 2 could u replace scyla with somethign better coded in ada? >=20 > What do you mean by "better coded"? e.g., A) Coded in, e.g., SPARK/Ada to be (mathematically-)provably correct. B) Coded with resource-pools for embedded systems in mind (=C3=A0 la Multic= s segmented partitioning) instead of One Big Enormous Heap for general-purp= ose computing (=C3=A0 la Unix monolith). > Is this product badly coded, currently? Or, if you think that the product= would benefit from better coding > (presumably in the context of some bug, which is a local problem), would = it be possible to code it better > in the existing language (presumably by fixing the local bug)? Presumably =E2=80=A2not=E2=80=A2 in the context of local bug as you surmise= , but in the context of a systemic widespread architectural flaw or lack th= at C++ (mis)leads designers into, such as A or B above. > And, lastly, why would anybody replace an existing (and apparently very g= ood) product with another > one? It's much better to spend your effort creating something new instead= . Answer: To achieve quite different architectural or design goals than the = Scyla team had in mind. That all being said, even Ada2020 will lack enough breakthrough differences= from C++ at the language level for the language alone to steer an Ada-base= d Scyla-esque different-thingy to be revolutionarily different. Mainstream= Ada culture does differ markedly from mainstream C++ culture, so the diffe= rent architectural or design goals would more likely arise from cultural di= fferences at the human-idiom level than at what the piecemeal language feat= ure-set minutia actually permits or prohibits. Some Adaphiles yearn for a more-pandering-to-popularity AdaNG (Ada next gen= eration) that, say, has braces instead of BEGIN END, and numerous other sha= llow =E2=80=9Cfeatures=E2=80=9D. Other Adaphiles like me yearn for a quite= different AdaNG that, while remaining true to Ada2020, resurrects the prop= ensity toward begetting something analogous to the breakthroughs of PL/1 an= d Algol68 in the 1960s and of Ada in the 1970s by setting the bar far far h= igher regarding what software (and software-engineering and systems enginee= ring) designs, principles, and practices can be achieved easily via expande= d expressivity in more (and/or more-flexible) language constructs (instead = of contortedly jammed through the backdoor in C++ if even possible at all i= n C++'s syntax or culture).