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 2002:a24:a089:: with SMTP id o131-v6mr3345075ite.10.1521716290708; Thu, 22 Mar 2018 03:58:10 -0700 (PDT) X-Received: by 2002:a9d:3464:: with SMTP id v91-v6mr422609otb.4.1521716290221; Thu, 22 Mar 2018 03:58:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u184-v6no666696ita.0!news-out.google.com!d3-v6ni854itf.0!nntp.google.com!199-v6no663062itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 22 Mar 2018 03:58:10 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=87.116.177.118; posting-account=z-xFXQkAAABpEOAnT3LViyFXc8dmoW_p NNTP-Posting-Host: 87.116.177.118 References: <0a1e0664-f657-4596-9672-5440ebe4caf2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada-Oriented GUI From: Bojan Bozovic Injection-Date: Thu, 22 Mar 2018 10:58:10 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51127 Date: 2018-03-22T03:58:10-07:00 List-Id: On Wednesday, March 21, 2018 at 10:51:01 PM UTC+1, Randy Brukardt wrote: > "Dan'l Miller" wrote in message=20 > news:0a1e0664-f657-4596-9672-5440ebe4caf2@googlegroups.com... > ... > >I never said that it wouldn't be. I was saying that rarely is a design > >tied to absolutely running nontrivial amounts of non-UI code on the Main= =20 > >thread. >=20 > Conventional sequential programs ran all of their code (UI and otherwise)= on=20 > a single thread. >=20 > Requiring the program to be executed around the GUI forces anything=20 > substantial into tasks (threads), with all of the problems that entails= =20 > (deadlock/livelock/data races/nondeterminism/required synchronization).= =20 > Since Ada already defines the purpose and definition of the environment t= ask=20 > (what you're calling the main thread), requiring using it for the GUI for= ced=20 > the entire program to be used by the GUI. And the GUI is necessarily a ti= ny=20 > part of any program that Ada is very appropriate for (that is, programs t= hat=20 > need to be close to the metal and/or verifiable - a GUI itself being neit= her=20 > of these). >=20 > The problem with Claw was that it implicitly dragged those tasking issues= =20 > into even sequential programs. Insisting on the GUI being primary makes= =20 > those problems even worse. I'd like to see a design where the GUI was tru= ly=20 > secondary (I couldn't figure it out, and I'm done caring personally). >=20 > Randy. But I can imagine cases where gui would need to be verified, together with = the OS itself, banking applications and applications used in hospitals to q= ueue patient records come to mind. You're absolutely correct that applicati= ons shouldn't be designed around gui, but gui agnostic, but its all in vain= if the OS itself isn't verified and nobody will bother (here's an idea, ma= ke one verified - as much as possible - posix/unix system for general use, = market real time version to embedded developers which traditionally use Ada= commercially, verified to DO-178C, ISO 26262 and other standards for autom= ation, transportation and industrial use, use drivers that aren't verified = from Linux or some *BSD for general use and have verified drivers for board= s used in safety critical domains. There is also a problem with formal meth= ods not being integrated in the language itself, so it's programming in Z o= r B with tools that generate Ada or C source, where, ideally, such intermed= iate steps needn't be taken. Whether programmer would use formal methods in= a language or not it would depend on actual needs of a project. I havent (= yet) read the book on Alphard by Shaw, Wulf and London, but they had that i= dea to have code verification in a language itself which could be paired wi= th modern theorem provers. In my ideal world there wouldn't be any bugs in = code, as the damage done by buggy code and hackers exploiting is enormous a= lready. Verification would make hacking obsolete.