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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada-Oriented GUI Date: Fri, 23 Mar 2018 17:42:26 -0500 Organization: JSA Research & Innovation Message-ID: References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com> Injection-Date: Fri, 23 Mar 2018 22:42:26 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="14443"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51184 Date: 2018-03-23T17:42:26-05:00 List-Id: "Dan'l Miller" wrote in message news:a913d10c-7799-4ec3-9357-d94e9da2deb7@googlegroups.com... On Thursday, March 22, 2018 at 6:47:28 PM UTC-5, Randy Brukardt wrote: > "Dan'l Miller" wrote in message > news:656fb1d7-48a4-40fd-bc80-10ba9c4ad0a4@googlegroups.com... ... >> > 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. > >Then you should study up on Rx, especially from the more-academic research >origins. Rx is trying to teach something regarding completely >inventorying, >categorizing, and mapping/folding/conflating the otherwise combinatorial >explosion of different event-arrival orderings to instead be of linear or >sublinear complexity that is manageable in a design (and verifiable at >compile-time if Rx were moved to compile-time declarations to an >Rx-equipped compiler). A complete waste of time to stidy the jargon de-jour. Most of these things fade away without a trace in a couple of years. And the "problem" is self-inflicted - if you model anything as "events", you are already lost, regardless of how one implements that. Microsoft in particular invents and releases some totally new technology every year or two. Most ends up with no traction whatsoever. I learned to stop caring because otherwise trying to keep up would drive one insane (and also prevent actually accomplishing anyway -- I've always figured that was one of Microsoft's main goals with developers, as it explains most of the things that they do from Solitare to changing the GUI every year.) Moreover, I am not much interested in purely academic ideas. Particularly about programming, since the majority of it will be gone in a decade or so anyway. (Luckily, that corresponds with my official retirement date...). I'm mostly interested in the part that requires correctness, and that part has little to do with "events". >> One has to architect the application so >> that there is very limited interaction between tasks, > >Not everything in the world is an Ada task of calculable maximum realtime >execution time. ??? I've never once used an Ada task with "maximum realtime execution time". That's part of the problem using any parallel execution, IMHO >> ... >> >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. :-) > >By the 2020s (the target marketstpace for Ada2020), Rx won't be in mere >libraries. ... Most likely, it will have completely disappeared. ;-) >Rx will have been moved to compile-time declarations of the dataflows so >that they can be checked for completeness to assure that no categorization >is incomplete. Ada is not the language for that, regardless of whether it works in some scheme, just like Ada is not the language for functional programming, even if you sort of can fake it for some purposes. Use a language better targetted to those weird special cases. Better yet, don't use any language at all, since most programming will be gone by then anyway. (I'm becoming convinced that Ada as it stands is not going to be able to appropriately support safe parallel programming, so we may very well be at the end of the lifespan of Ada anyway.) >> 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. > > Then move Rx to compile-time declarations instead. Just as in omitting a > case >can be detected for enumerations at compile-time, omitted categorization of >an >unhandled order of arrival can conceivably be detected at compile-time if >the >declarations were known to an Rx-equipped compiler at compile-time. >Today's >Rx is merely a prototype of what is to come in future languages at >compile-time. I'm not talking about "omitting cases", something Ada has always been able to do very well at compile-time. Just use an appropriate enumeration. Most of the stuff that has come later really does not help for that (like OOP). The academics made such a complaint about needing to update case statements, but turning the declarations 90 degrees fixes nothing -- now you need to implement interminable overridings instead. It obviously depends on the problem as to whether the case statements or the overridings are bigger -- in my programs, the overridings were much worse to deal with than updating the case statements. Correctness is about verifying (preferably at compile-time) constraints and invariants -- on data, code, and anything else around. That is, finding bugs before they happen. Flow is part of that, but only a relatively small part. And of course, making all of those checks statically is the holy grail. >> 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. > >How will the ARG assure itself that it is not on a fool's errand? We can't; that's a topic of discussion. For me personally, if we can't do this, then Ada is dead and I will want to be dead - there is no future in such a world. >There is always at least one more origin of events outside not only your >control, but >outside your visibility. Arrival of a packet over a network. Completion >of >long-running batch operation. The requested async filesystem read just >arrived. >Ooops, your virtual machine was migrated between data-centers in the cloud, >and >while you were dormant all sorts of once-pending events arrived & finished >all >higgly piggly as no longer pending, including some rare timeouts that need >to be >retried only in this bizarre data-center-migration situation. If such events (that you're not interested in) aren't isolated from your application by the kernel, then you have a very bad architecture. And a massive security problem. Such an architecture has no real future unless ATT etc convince the public that there is no value to security and privacy. (See "I'd rather be dead", above.) If they are isolated, who cares what they do? If the application depends upon them, then of course the compiler knows about them in the sense that they are handled. >The compiler's omniscience can never be omniscient enough to see all event >dependencies outside a program. Why would we care about anything that happens outside of a program? One assumes that the virtualization and isolation of the kernel actually work. :-) >Hence, the Ada2020-compliant compiler will be provably correct for a >minority subset of events contained only in the small world of Ada source >code and completely blind to a majority of the real-world events arriving >from outside Ada source code. The majority of irrelevant events. And if those events have any effect whatsoever on the running program (other than timing), there's a major archtectual problem. Besides, if you really care, you'll write the entire system in Ada -- Ada itself makes a fine kernel -- and then there are no other events even possible. > 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. An entirely a-priori system that fails to a-posteriori-ly overtly inventory, categorize, and map/fold (i.e., prune/conflate the branches of) the combinatorial explosion of this-before-that and that-before-this uncontrollable arrival times of real-world events to conflate it to, say, linear or sublinear growth instead of the natural exponential-growth combinatorial explosion is a system whose excessively myopic compile-time mathematical proofs are based on the wrong axiom system and the wrong possible-world in modal logic.