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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Fri, 23 Mar 2018 13:31:01 +0100 Organization: A noiseless patient Spider Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 23 Mar 2018 12:31:01 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="8991cf1a2a308bc7d601ad3fd3a09a5e"; logging-data="8434"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+RQWqCqE6+U0lrE7L5q8WB" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 In-Reply-To: Content-Language: en-US Cancel-Lock: sha1:Kx35zBhP3x3JZ73oQXmM0Vq6XzM= Xref: reader02.eternal-september.org comp.lang.ada:51166 Date: 2018-03-23T13:31:01+01:00 List-Id: On 23/03/18 00:47, Randy Brukardt wrote: > (...) > > No, a correct program is one that can be reasoned about. And one cannot > reason about programs that contain race conditions ("unavoidable" or not). > One has to impose some sort of structure to avoid race conditions/dead > locks/live locks, lest the program be unanalyzable. And to have any chance > of believing a program is correct requires analysis. > > (...) > > One has to architect the application so > that there is very limited interaction between tasks, and that interaction > has to be carefully controlled (usually via rendezvous or protected > objects). That's one strong point of Rx precisely. > This has nothing to do with the UI or IO or any other "events". > It's probably easiest for most to just manage the UI in the single task, > because that gets the mess of "events" away from the bulk of the processing. > (Ada is wildly inappropriate for applications that are mostly GUI - use some > web-based langauge for that and use Ada for the heavy-duty processing.) > > (...) > > For sequential programs, Ada is pretty much there. I've been working on > Janus/Ada infrastructure improvements without even trying to find the code > that needs to be modified -- the compiler/run-time tells me where changes > are needed far quicker than trying to look for them by hand. (One has to > design their code to enable this sort of thing in the first place, but that > pays off many times if the program has any sort of lifetime.) > > One of the goals of Ada 2020 is to bring that level of reliability to > parallel programming. That means the compiler has to (conservatively) > diagnose and reject data races between separately executed code. Matlab has some of what is planned and I'm counting the time until Ada will too. It's fantastic. > A system that decides to just ignore race conditions as "unavoidable" is > going in the wrong direction. Most likely, it will kill us all when it's > running self-driving cars and autopilots. I think the argument about race conditions has derailed. Rx does not embrace the idea that race conditions (in the sense of real bugs) are unavoidable. If correct execution is guaranteed independently of the particular interleaving of events I'd say that's not a real race condition, and that's what Rx abstracts away (or helps you to, safely). I (humbly) think that people not knowing Rx but arguing against it are barking at the wrong tree. It's not something that can do everything better. It's just a tool (paradigm if you wish) that precisely simplifies handling a certain kind of systems that with traditional techniques are prone to difficult to diagnose bugs and uncomfortable code (as the discussion on GUI libraries show). It goes in the direction of "this can't cause a race condition", not the contrary. To me, Rx vs imperative [for suitable problems] it's like tasking in Ada vs other languages. Ada is in entirely another league wrt simplicity and safety. Still, you can misdesign spaguetti code that deadlocks, livelocks, that calls blocking operations from blocking operations, raises Tasking_Error... but Ada makes things easy if you know the Ada way, and enables some kinds of analysis, sure, if you adhere to some practices. I'm really not an Rx expert, so I'm not sure what kind of research is being done on it that could be relevant for safety-minded people. What I know is that the principles are simple and elegant, and my instinct says that it would interact very well with Ada protected objects, so I would be surprised if nothing good could be deducted starting from there.