Re: Ada-Oriented GUI

["Randy Brukardt" <randy@rrsoftware.com>]

"Dan'l Miller" <optikos@verizon.net> wrote in message 
news:656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com...
On Wednesday, March 21, 2018 at 5:33:43 PM UTC-5, Randy Brukardt wrote:
>> "Dan'l Miller"  wrote in message
>> news:26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com...
>> On Wednesday, March 21, 2018 at 12:43:04 PM UTC-5, Dmitry A. Kazakov 
>> wrote:
>> >> So it is inconsistent unless packed into single thread. No difference,
>> >> exiting GUI do just same.
>>
>> >Well, more power to you then, because you can show all those Rx folks
>> >where their entire worldview is horribly wrong from the git-go.
>>
>> Obviously. :-) Their worldview appears to be that writing software that 
>> is
>> actually correct is impossible, so let's not even try.
>
>Here you seem to considering the only correct program to be one that 
>cavalierly
>mandates a designer-prescribed order to the arrival of UX-affecting events,
>from all of the UI, the OS, the network, and the completion of long-running
>backend processing.

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.

> Why is such an engineering-time whim the only definition of correctness.
> Why is an engineering-time a-priori prescriptive order of event-arrival 
> more
> correct than Rx's a-posteriori meticulous categorization & marshaling of a
> descriptive order of event-arrival so that all the outcome orderings can 
> be
> overtly handled properly?

I have no idea what this even means. 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). 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.)

>> The dustbin of
>> history is full of ideas spawned by intelligent, well-meaning people (I 
>> can
>> give plenty of examples even with Ada).
>
>Some people have been trying to throw Ada into the dustbin of history
>several times over the decades.  And their efforts have partially
>succeeded:  the pro-Ada fervor on university campuses from the
>late-1970s through around 1990-ish* seems to have faded in North
>America, supplanted by Java Java Everywhere as the new mantra.

For my purposes, the possibility of Ada ever being commercially successful 
were done by 1990, even though it took me until about 1998 to admit it. 
Since I stopped caring about that, I sleep a lot better. Most people are 
idiots after all, and there is a point at which one should admit defeat on 
appealing to them...

Why have I stuck with Ada since? Mainly because everything else out there is 
far worse, and there's little chance of success with them, either. If I'm 
going to be a failure, at least I will have failed with the best possible 
programming language.

>> If I'm wrong, then kill me. Please! A world where no program can be 
>> correct
>> is not a world that I can contribute to nor have any interest in living 
>> in.
>
>A circle of friends devise a way of disciplining & marshaling & scheduling 
>the
>arrival of an otherwise disparate cacophony of event flows occurring as a
>nature-of-the-beast in the real world,

Sorry, I don't buy the notion that a "cacophony of event flows" is a 
requirement in the real world. One can reasonably impose order without 
harming the modelling of the "real world". And one has to do that if they 
want any reliability in the resulting program.

>...where that circle of friends has relatively little overlap with your 
>circle of
>friends-and that is why you want to end it all?  Sheesh.  I don't know if I
>can talk you down from the ledge, Randy.  :-)

Don't try, my mother has never been able to do it...

>I suppose you could try to suppress the release of any RxAda library from
>now until the end of time to keep humanity safe from the reactive scourge
>of introducing a form of data-flow processing to Ada.  That would be one
>strategy to make life worth living, I suppose.

The presence of one more library that no one much uses isn't going to bother 
me much. :-)

But I've spent my entire life attempting to bring correctness to 
programming, with the ultimate (unachievable) goal of a compiler/language 
system that detects/prevents all possible bugs from ever going undetected in 
a fielded system. (Let's temper "possible" here with the idea that a system 
that does precisely what the programmer intended -- but that intent is 
wrong -- is not considered a bug in this model.)

I came to Ada in large part because it promised to be a great platform for 
such a system (well, that and the fact that it had by far the most sensible 
syntax of the contenders in 1980).

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.

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.

                                       Randy.