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 X-Received: by 2002:a24:44c4:: with SMTP id o187-v6mr4990266ita.41.1521425019411; Sun, 18 Mar 2018 19:03:39 -0700 (PDT) X-Received: by 2002:a9d:ba5:: with SMTP id 34-v6mr626443oth.7.1521425019228; Sun, 18 Mar 2018 19:03:39 -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!r195-v6no2151691itc.0!news-out.google.com!h73-v6ni4343itb.0!nntp.google.com!r195-v6no2151686itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 18 Mar 2018 19:03:38 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <7789c58e-ca36-44a2-8818-009eface4a3e@googlegroups.com> Subject: Re: Ada-Oriented GUI From: "Dan'l Miller" Injection-Date: Mon, 19 Mar 2018 02:03:39 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51063 Date: 2018-03-18T19:03:38-07:00 List-Id: On Sunday, March 18, 2018 at 8:33:26 AM UTC-5, Jeffrey R. Carter wrote: > I've written on here before that I think the traditional=20 > register-callbacks-and-call-a-procedure GUI interface is a hack only suit= able=20 > for sequential languages, and attempted to describe my idea of how a GUI = for a=20 > concurrent language like Ada should work. Some have expressed the opinion= that=20 > such an interface is not possible. Jeffrey, you are very insightful & wise (and correct). Apparently independ= ent of your efforts, Microsoft Research (of all organizations on the planet= !) effectively concurs with you. Over the past decade, Microsoft Research = has been spreading their Reactive Extensions (and Interactive Extensions, L= INQ) presentation of a very similar idea as to the one that you have: GUIs= could focus on a linear river of dataflows, not on callbacks. The Rx comm= unity smears the current tangled callback set of competing concerns (that a= re extraordinarily difficult to get right at scale) as =E2=80=9Ccallback he= ll=E2=80=9D. Microsoft Research is the progenitor of the Rx and Ix librari= es for C#, F#, and C++. Allied but competing efforts are porting variants = of Microsoft Research's Rx and Ix libraries to Java, Kotlin, Swift, Lua, Ja= vaScript, Scala, Clojure, Ruby, Python, Go, Groovy, Elixir, and Dart=E2=80= =94just about every general-purpose language except Ada (and Fortran, but h= ardly anyone has considered Fortran a nonnumerical/general-purpose language= since Prime Computer switch from writing compilers & OSes in Fortran to PL= /P). But more to you point, Jeffrey, are the RxNetty for .NET, RxAndroid, = and RxCocoa for GUIs/OSes with numerous competing information flows (e.g., = interactive GUI events, app lifecycle events, network events, realtime even= ts). At some level, Rx conforms to your vision. http://reactivex.io/languages.html Although there are numerous hackerish books out there for Rx, I would recom= mend Microsoft Research's seminal reference: _Introduction to Rx: A step-b= y-step guide to the Reactive Extensions to .NET_ by Ian Campbell. This boo= k is less about .NET & C# than using .NET & C# as concrete examples of more= theoretical/abstract concepts. Then, the best book by far that I have rea= d for RxAndroid is _Reactive Android Programming_ by Tadas Subonis, which i= s actually mediocre but all the others for Android and Cocoa are truly abys= mal! Nearly all of these books expend far far far too much effort giving p= laybaby playtoy examples with sequences of integers and not nearly enough t= ruly teaching how to wire up rivers of data flows for all the interesting R= x-rivers-of-dataflows scenarios is GUIs & OSes. (I say rivers here merely = to paint an instant understandable motivational picture in the mind's eye; = the normative term is sequence, but the RxJava-influenced subculture of Rx = also uses streams instead of sequences.) I encourage you to meld your work with Rx, plus also you should seriously c= onsider being the primary developer of RxAda, which is not yet extant to my= knowledge. Indeed, the Rx world is still quite bleeding-edge and in flux;= all of Rx in all languages could still be shaped by your work in the ways = that it differs. (Of course in Ada, tasks are part of the language, wherea= s, in other languages, those languages must rely on the OS framework for th= reads and schedulers=E2=80=94but the moral of the story of your vision for = an RxAda using the vision that you describe can be ported to some degree to= the other Rx-capable languages as well.)