Re: Ada-Oriented GUI

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

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.