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 10.107.150.82 with SMTP id y79mr9369045iod.107.1519681399751; Mon, 26 Feb 2018 13:43:19 -0800 (PST) X-Received: by 10.157.46.5 with SMTP id q5mr536080otb.10.1519681399545; Mon, 26 Feb 2018 13:43:19 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!o66no1996823ita.0!news-out.google.com!a2ni427ite.0!nntp.google.com!w142no2002860ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 26 Feb 2018 13:43:19 -0800 (PST) In-Reply-To: <1190543753.541369961.154390.laguest-archeia.com@nntp.aioe.org> 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: <5a8e17dc-1d52-4393-be58-8881e741c3a4@googlegroups.com> <1190543753.541369961.154390.laguest-archeia.com@nntp.aioe.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6700ecea-cdfe-4c73-88ec-d98bafd9151b@googlegroups.com> Subject: Re: Embeddinator-4000 begetting an Ada-cross-platform future? From: "Dan'l Miller" Injection-Date: Mon, 26 Feb 2018 21:43:19 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 3721838137 X-Received-Bytes: 5913 Xref: reader02.eternal-september.org comp.lang.ada:50663 Date: 2018-02-26T13:43:19-08:00 List-Id: Speaking conservatively and not over-committing, I am inventorying the gaps= in the various segments of the C++ community to see where they are going w= ith regards to Embeddinator-4000's C++ code generation on all these OSes/SD= Ks. The biggest question is what Microsoft(-owned? Mono's) Embeddinator-40= 00 is going to generate as the C++ language projection on Windows. Will Em= beddinator-4000 defer to C++/WinRT? Or will Embeddinator-4000 devise a Mon= o-centric competitor to C++/WinRT's .winMD approach? (Mono is effectively = a clone of .NET for all the non-Microsoft OSes, and, due to its history, Mo= no lacks .winMD rich metadata embellishing a .DLL.) If they defer to C++/W= inRT on Windows, does that jeopardize the entire motivation for a C++ langu= age projection in Embeddinator as diluting either the C++/WinRT or Xamarin = momentum at Microsoft. The question is: how much autonomy does Mono have = in this new Xamarin-owned Microsoft era? And how much =E2=80=98internal=E2= =80=99 competition does Xamarin or Microsoft want to incur from C++ vis a v= is Xamarin.iOS, Xamarin.Mac, Xamarin.Android, Xamarin.Tizen, and eventually= Xamarin.Forms. The autonomy question is interesting only in the sense of h= ow much C++ support will the Mono team build out in Embeddinator-4000 versu= s how much will they be steered by interdepartmental pressures to do or not= do certain things regarding the C++/WinRT momentum that is building in Mic= rosoft and the Xamarin C# momentum that is already in full force. Of cours= e, these are not questions for this group, but you asked what I was contrib= uting to the topic, and the Ada topic depends on all these other tangents, = either directly as dependency/pioneer or indirectly as =E2=80=98office poli= tics=E2=80=99 as this all plays out. Plus, I am acting as breaking-news journalist here in this group, reporting= news of sorts from afar of which the Ada community might not be aware. Yo= u'd rather hear fresh news as it is happening in early 2018, rather than he= aring for the first time how it all turned out after the fact in, say, 2020= . I think you are indirectly asking, =E2=80=98Are you going to pursue any ope= n-source extension of Embeddinator-4000 to add the Ada language projection?= =E2=80=99. Without over-committing and without rejecting the idea, I will = give you this big hint: because of the lack of Ada symbolic debugging on i= OS devices, I am forced to do my cross-platform iOS, MacOS, Android, UWP, T= izen development of =E2=80=98the same=E2=80=99 app in C++ (including its va= riants C++/CX or C++/WinRT and Objective-C++) until such an Ada compiler ex= ists. In my C++ cross-platform development for those platforms using the V= IPER architecture to quarantine per-OS/per-SDK oddities into VIPER Views, I= currently completely lack a nonJava/nonKotlin solution for writing the UI = in any variant of C++. Due to this lack, the JNI boundary between the VIPE= R Presenters and the VIPER Views rears its ugly head in hand-crafted app-do= main source code (in the VIPER Views), rather than being buried in infrastr= ucture as auto-generated forget-about-it it-just-works nicety. So the one = missing language projection from Embeddinator-4000 that I most need is the = C++ language projection for Xamarin.Android's JNI-based invocation of Andro= id's Java SDK. But to get the Android language projection, if I were to de= velop the C++ language projection myself (and cease waiting for the ever-fo= rthcoming one to finally arrive), it would be approximately the same amount= of work as developing the Ada one. The main thing that stops me from deve= loping the Ada one is the lack of symbolic debugging on iOS, due in turn to= the lack of LLVM-backend toolchain that Apple demands, since GCC is no lon= ger permitted by Apple. To keep score in my world, I have 2 gaps for Ada (= lack of LLVM and lack of Embeddinator-4000) versus 1 gap for C++ (lack of E= mbeddinator-4000). The effort for hand-crafting the VIPER View quarantinin= g of Android/JVM/Java SDK is approximately the same as developing a Embeddi= nator-4000 language projection, so hand-crafting it in the app-domain effec= tively score a gap of 1 as well. If this thread would happen to reveal how= soon the LLVM backend for GNAT is coming, then that could adjust Ada's gap= -analysis scoring to be effectively 1 instead of 2, causing all options to = be effectively tied in foreseeable effort.