Re: Ada-Oriented GUI

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

On 23/03/18 13:59, Dmitry A. Kazakov wrote:
> On 23/03/2018 13:31, Alejandro R. Mosteo wrote:
> 
>> I (humbly) think that people not knowing Rx but arguing against it are 
>> barking at the wrong tree.
> 
> Yes, but this is a natural defense reflex against snake oil sellers.

Just like Ada enthusiasts pestering C/C++/Rust/... people are seen? ;-)

>> 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.
> 
> If you mean comparing languages with no tasking support to Ada, that is 
> not like imperative vs. declarative. [Event-controlled is not really 
> declarative]

I mean, e.g., Ada vs Java Thread/Runnable; it was not a technical 
analogy anyway. Just a gut-feeling one.

The primitive tasking facilities of most popular languages, 20+ years 
after Ada, is one of the things that most amazes me (in a bad way).

>> 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.
> 
> If principles are simply and elegant they certainly could be explained 
> in a few words understandable for residents of comp.lang.ada.

Hehe. I'd say: it's simple enough, and there's so much information 
available, that anyone with genuine interest can get its bearings in the 
time spent arguing here, and with better explanations than mine using 
mere ASCII. But since you ask (or not) I will give the bare minimum and 
then some quickly triaged links:

----8<----

Rx Observer contract:

OnNext* (OnCompleted | OnError)?

Events arrive once, thread-safely (OnNext call). End of sequences is 
notified once with success or failure, so cleanup is trivial.

The emitter of events is an Observable. The consumer is an Observer. 
Combinations of both are Operators. There are many predefined Operators 
to make life easy, addressing most needs that would be otherwise complex 
(e.g. tasking ones).

For my own specification package: https://goo.gl/WQfpeV

----END----

Links (in somewhat loose reading order):

1) Original reference: https://go.microsoft.com/fwlink/?LinkID=205219
Sections 4.1 - 4.3 focus on the essentials. They're very short. The rest 
is only useful when you already know the basics and jargon.

2) 2-minute intro to Rx:
https://medium.com/@andrestaltz/2-minute-introduction-to-rx-24c8ca793877

2.5/3.5, can't decide) Marble diagrams:
https://medium.com/@jshvarts/read-marble-diagrams-like-a-pro-3d72934d3ef5

3) The whole http://reactivex.io site. I'd start by:
http://reactivex.io/intro.html
http://reactivex.io/documentation/contract.html
http://reactivex.io/documentation/operators.html

Never) I have a paper on my RxAda implementation. Section 2 attempts to 
be an introduction to Adaists not knowing Rx:
Paper: 
https://www.researchgate.net/publication/318135797_RxAda_An_Ada_implementation_of_the_ReactiveX_API
Slides: 
https://www.auto.tuwien.ac.at/~blieb/AE2017/presentations/RxAdaSlidesShort.pdf

...

Since you asked about TreeViews elsewhere, I see they somehow do it (but 
don't ask me how. It's probably ugly JS):
https://react.rocks/tag/TreeView

> [There is nothing simple or elegant in event-controlled architectures. 
> Doing this for 20+ years (this is state of the art in automation 
> systems), I am pretty sure of.]

The most elegant designs can turn ugly once things get real, that's for 
sure...