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.36.98.138 with SMTP id d132mr6098217itc.27.1519664777994; Mon, 26 Feb 2018 09:06:17 -0800 (PST) X-Received: by 10.157.4.22 with SMTP id 22mr90346otc.2.1519664777862; Mon, 26 Feb 2018 09:06:17 -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!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!w142no1916088ita.0!news-out.google.com!a25ni1897itj.0!nntp.google.com!w142no1916087ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 26 Feb 2018 09:06:17 -0800 (PST) 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 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5a8e17dc-1d52-4393-be58-8881e741c3a4@googlegroups.com> Subject: Embeddinator-4000 begetting an Ada-cross-platform future? From: "Dan'l Miller" Injection-Date: Mon, 26 Feb 2018 17:06:17 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 8514 X-Received-Body-CRC: 489790642 Xref: reader02.eternal-september.org comp.lang.ada:50654 Date: 2018-02-26T09:06:17-08:00 List-Id: Although none of this supports Ada at this time, let's walk along a path of= the present (0) and emerging (1 through 3) and a potential future (4 throu= gh 8) together. 0) Xamarin has accomplished a minor miracle of providing Xamarin.iOS, Xamar= in.Mac, Xamarin.Android, and the forthcoming Xamarin.Tizen for developing s= oftware in the iOS, MacOS, Android, and Tizen OSes, using substantially the= same C# culture of presenting the Objective-C iOS runtime, the Objective-C= MacOS runtime, the Java-JVM Android runtime, and the Tizen C++ development= SDK to C# on top of the Mono stack. https://github.com/Microsoft/cppwinrt https://moderncpp.com/2017/11/15/cppwinrt-exe-in-the-windows-sdk 1) Microsoft (actually the genius Kenny Kerr prior to being hired at Micros= oft) has accomplished a minor miracle of generating ISO 14882:2017 C++ sour= ce code to invoke any WinRT component that has a .DLL and its accompanying = .winMD (Windows metadata, which provides symbolic names among other rich in= formation). WinRT components are not limited to only WinRT (a.k.a. UWP). = Nowadays nearly all of Windows SDK and nearly all of .NET world (other than= Mono) is presented as WinRT components, which are effectively a modernized= version of ATL & COM from the older era of Microsoft. This code generator= is called cppwinrt.exe and the body of work that it generates is called C+= +/WinRT. The generated code has some annoying C++ish peculiarities, such a= s all would-be(-in-C++/CX-or-C#) =E2=80=9Ctypes=E2=80=9D are actually value= -semantics object instances. Of course, such peculiarities would be anathe= ma to Ada culture, but still: consider a world where (all) processor-nativ= e languages need not be extended with C++/CLI-esque or C++/CX-esque grafted= -on C#-esque languages in order to invoke (or be invoked by) UWP and .NET r= untimes. https://github.com/mono/embeddinator-4000 2) Mono's Embeddinator-4000 has been also accomplishing another minor mirac= le of generating Java and Objective-C fa=C3=A7ades to any Mono DLL, especia= lly the Xamarin.iOS, Xamarin.MacOS, Xamarin.Android, and so forth language = projections of the iOS, MacOS, Android, and so forth SDKs. 3) Mono's Embedinnator-4000 could have a C++ language projection relatively= soon for Clang to invoke the Objective-C runtime of iOS, the Objective-C r= untime of MacOS, and (analogous to the way Xamarin.Android works) the JVM-b= ased Java runtime of Android (externally, forcibly) via the JNI, and even p= erhaps a competitor to C++/WinRT for UWP. Imagine Xamarin.iOS's, Xamarin.M= ac's, Xamarin.Android's SDKs' APIs language-projected to ISO-14489-complian= t C++. Embeddinator-4000 generating a non-C++/WinRT C++ language projectio= n of nonMono .NET SDKs for UWP or Windows 10 are conceivable. Embeddinator= -4000 generating a C++ language projection of Xamarin.Tizen SDK's APIs is a= lso conceivable, as Xamarin.Tizen becomes a 1st-class citizen in the Xamari= n/Mono world. Btw, in case some reader is failing to grasp the import of t= his: the miracle of Embeddinator-4000 (and of C++/WinRT for that matter) i= s not to generate the language projection of the API itself (although it do= es that). Rather the key is that Embeddinator-4000 generates the glue code= from that language projection of the SDK to the runtime of the SDK. Some = thin roll-your-own veneer code-generator is not what this is. This is the = real full invokable language projection of the SDK into other languages, re= ally reading the Objective-C-runtime binaries and the JVM binaries to invok= e those binaries from other languages. 4) Imagine an LLVM-backend for GNAT, so that GNAT can be debugged symbolica= lly on iOS devices, instead of the current lack thereof. (I am not talking= about some old musty crusty Dragon Egg either, based on GCC 4.2.) Is ther= e any news on the current state of this? 5) Imagine a future release of Mono's Embeddinator-4000 that also would gen= erate an Ada language projection of Xamarin's C# SDKs' APIs for all those O= Ses, somewhat mimicking the more-Ada-esque portions of Embeddinator-4000's = language projections to the current Java, the current Objective-C, and/or t= he forthcoming C++. 6) Suddenly, shortly after the forthcoming advent of C++ as a processor-nat= ive language that can be utilized to write iOS apps instead of in Objective= -C or in Swift or in Xamarin.iOS's C#, to write MacOS apps instead of in Ob= jective-C or in Swift or in Xamarin.Mac's C#, to write Android apps instead= of in Objective-C or in Swift or in Xamarin.Android's C#, and to write UWP= apps on Microsoft Windows 10 editions of OSes instead of in .NET's C# or F= # or C++/CX or C++/WinRT, then right on the heels of that (!) Ada could the= n be the 2nd processor-native language capable of writing apps for iOS, Mac= OS, Android, UWP, and eventually Tizen. If C++ language projection in Embe= ddinator-4000 continues to fail to be released (as it has throughout 2017),= then Ada could actually pull ahead in the race to be the 1st processor-nat= ive cross-platform language for all those OSes. 7) Suddenly, developers start considering C++ or Ada as a viable alternativ= e to writing their apps as many as 6 times: 7.1) once in Swift or Objective-C for iOS; 7.2) again porting their mobile Swift or Objective-C app to desktop MacOS d= e-emphasizing the mobile UI/UX emphasizing window frames & menus, again; 7.3) again in Java or Kotlin for Android; 7.4) again in C# or F# or C++/CX or C++/WinRT for UWP (store app); 7.5) again porting their mobile UWP app to desktop or non-store Windows 10; 7.6) again in C++ for Tizen. Oh, and Google is developing some sort of successor to Android and ChromeOS= called Fuscia, so perhaps that might be the 7th rewriting/major-porting ef= fort. https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38d= e52 8) With Viper software architecture replacing MVC and MVVM software archite= cture in GUI and mobile apps, the nonportable OS-specific UI code in each V= iew can be divorced from the cross-platform UX code in each Presenter (and = Router for navigation segueing). 8.1) If this quarantining of nonportable UI code in the Viper Views is not = enough, an Ada analogue of (the deeply flawed) Xamarin.Forms could be desig= ned for true portability of commonplace abstractions of UI in each portable= View, leaving only a few nonportable Viper Views that each take advantage = of highly peculiar-to-1-OS UI features. As perhaps the only 3 languages in the future to accomplish this degree of = writing the UI/UX for all these OSes in the same language with the same (e.= g., Reactive Extensions) programming-culture libraries, then C#, C++, and A= da can compete on their respective merits for dominance in the cross-platfo= rm domain, leaving Java, Kotlin, Swift, and Objective-C relegated to their = relatively-walled-garden single-company narrower marketspaces, analogous to= BLISS on DEC minicomputers, to PL/I on IBM and Multics versus PL/P on Prim= OS versus PL/M on CP/M, and Protel on Nortel telephone equipment. I bring = up those historical examples, because the future is ripe for history repeat= ing itself in the next half-decade or so. This is tomorrow's carpe diem. Seize it (or be a victim of natural selecti= on's survival of the fittest).