Re: Embeddinator-4000 begetting an Ada-cross-platform future?

["Dan'l Miller" <optikos@verizon.net>]

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 with regards to Embeddinator-4000's C++ code generation on all these OSes/SDKs.  The biggest question is what Microsoft(-owned? Mono's) Embeddinator-4000 is going to generate as the C++ language projection on Windows.  Will Embeddinator-4000 defer to C++/WinRT?  Or will Embeddinator-4000 devise a Mono-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, Mono lacks .winMD rich metadata embellishing a .DLL.)  If they defer to C++/WinRT on Windows, does that jeopardize the entire motivation for a C++ language 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 ‘internal’ competition does Xamarin or Microsoft want to incur from C++ vis a vis Xamarin.iOS, Xamarin.Mac, Xamarin.Android, Xamarin.Tizen, and eventually Xamarin.Forms. The autonomy question is interesting only in the sense of how much C++ support will the Mono team build out in Embeddinator-4000 versus 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 Microsoft and the Xamarin C# momentum that is already in full force.  Of course, these are not questions for this group, but you asked what I was contributing to the topic, and the Ada topic depends on all these other tangents, either directly as dependency/pioneer or indirectly as ‘office politics’ 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.  You'd rather hear fresh news as it is happening in early 2018, rather than hearing for the first time how it all turned out after the fact in, say, 2020.

I think you are indirectly asking, ‘Are you going to pursue any open-source extension of Embeddinator-4000 to add the Ada language projection?’.  Without over-committing and without rejecting the idea, I will give you this big hint:  because of the lack of Ada symbolic debugging on iOS devices, I am forced to do my cross-platform iOS, MacOS, Android, UWP, Tizen development of ‘the same’ app in C++ (including its variants C++/CX or C++/WinRT and Objective-C++) until such an Ada compiler exists.  In my C++ cross-platform development for those platforms using the VIPER 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 VIPER Presenters and the VIPER Views rears its ugly head in hand-crafted app-domain source code (in the VIPER Views), rather than being buried in infrastructure 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 Android's Java SDK.  But to get the Android language projection, if I were to develop the C++ language projection myself (and cease waiting for the ever-forthcoming 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 developing 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 longer 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 Embeddinator-4000).  The effort for hand-crafting the VIPER View quarantining of Android/JVM/Java SDK is approximately the same as developing a Embeddinator-4000 language projection, so hand-crafting it in the app-domain effectively 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.