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

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

Dan'l Miller wrote: 
> > 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 through 8) together. 
Ivan Levashev wrote:
> Before reading about minor miracles, I would recommend reading 
> Release-to-Release Binary Compatibility in SOM. It has a nice table, and 
> most noted are still behind. Those who crafted this table probably did 
> not want to make a map being valid for 20 years, but we are still there, 
> like in 1408 movie. 
>
> If you take a closer look at WinRT in C++, you'll see that it is not 
evolved much compared to COM, ... [snip] ...

Because this is along the threads of a posting about bringing •compile•-time ••source-code projections•• of OSes' SDKs to Ada (and to C++, as another processor-native compiled language, for that matter), the gist of Ivan's reply is apparently something to the effect of:  because of lack of much progress on ABI-based extensibility without additional (re)compilation of the app's original source-code (or the API declarations on which the app's original source code relies), interest in permitting Ada (and C++, for that matter) to compile source code successfully to target iOS, Android, and Tizen is ______<insert something (tacitly?) negative here that Ivan doesn't quite directly mention_____.

Yes, in the most absolutely perfect world over the past 20+ years, yes, OS/2-era SOM-esque technologies would have been embraced on Microsoft OSes, Apple OSes, Google OSes, and Samsung OSes (and Linux and BSD Unix and all the RTOSes) and it wouldn't have faded away as OS/2 and Silicon Graphics faded away into history with only a few echoes of themselves still (barely) existing in a few nooks & crannies of the industry (e.g., MIPS ISA in a few network processors and in PRChina's Loonson/Godson processor research; OS/2 still available for purchase at an IBM partner).

But such ABI-based extensibility without (re)compilation is effectively a luxury that even the most-multi-billion-dollar corporations nowadays are unwilling to fund.  Apple gives some occasional statements regarding a desire to stabilize Swift's (and perhaps Objective-C's as prerequisite?) ABI, but such perennial statements in recent years are eclipsed by a rather significant •increase• in churn in the APIs at the source-code-of-SDKs level.  Hence Apple's OSes have not yet even achieved API/source-code stability, let alone ABI discipline.  Microsoft is in an even weirder situation with ever-present presumption (and release of SDK previews) for a Windows 10 Mobile OS without any new phones or non-Surface-with-less-than-full-fledged-Windows-10-or-10S-OS for several years.  There are continued rumors of a Surface Phone or a return of a 2-LCD-screen Courier-esque phone on which Windows 10 Mobile would run.  Google appears to be de-emphasizing their prior goal of having all Android apps run on all ChromeOS devices, but rather Google is apparently pursuing a replacement Fuscia OS for both Android and ChromeOS that would serve both marketspaces.  Samsung's Tizen is apparently seeking an eventual de-emphasis (or divorce) from Android (perhaps at the same time as Google's rollout of Fuscia OS).  So clearly Apple, Microsoft, Google, and Samsung have their OS/SDK hands quite (over-)full just getting pre-SOM-era source-code-centric SDK house in order, without considering SOM-esque luxuries at the ABI no-recompilation-needed level.  It is hard enough to build out all this new OS technology for SDK source-code compilation that they are apparently too busy to language-project the source-code-API for the SDK to any languages other than their golden-child walled-garden languages (i.e., Swift & Objective-C on Apple OSes, Java on Android & ChromeOS, C# & F# & C++/CX on Microsoft OSes).  They apparently have no time or funding for SOM-esque luxuries at the ABI level.

Taking all that as the inventory of (even the bleeding edge of) the state-of-the-art for 22+ years since that that article was written, these threads of this original posting merely beg for Ada (and ISO-standard not-divided-by-CX C++ for that matter) to achieve at least 2nd-class-citizen residency on the UI/UX code of Apple's, Microsoft's, and Google's OSes, instead of being forever relegated to the dungeon of backend libraries without UI/UX responsibilities.  Via Xamarin/Mono, C# achieved 2nd-class-citizen residency on the UI/UX code of Apple's, Microsoft', and Google's OSes via source-code-based language-projection of SDK API plus Xamarin-provided glue code between app & OS's (fluid) ABI for each release.  (Tizen already has embraced standard C++, as I understand it, so interworking with Ada has somewhat more hope for less barrier to entry sooner.)  Language-projecting at the source-code level of an SDK and then compiling is so much more practical at this inventorying of the state of the art of the industry than wishing for (and worse, waiting for) some sort of grand & glorious SOM-esque knight to ride in on his (or her) horse to save the day at the ABI level.