What can Ada do to survive Big Tech's war-on-portability?

What can Ada do to survive Big Tech's war-on-portability?

[Optikos]

https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android

Dropbox has learned the hard way that the titans of Big Tech (e.g., Google, Apple, Microsoft) have erected semi-impermeable walls around their core technology that intentionally make portability difficult.  Although that prior sentence is semi-obvious for decades, what could Ada do differently henceforth to not suffer the above-linked article's same fate as C++ at Dropbox?

I would offer the 1st strong criticism of Dropbox's approach:  the lack of VIPER (or better) software architecture to quarantine the target OS away from the 100%-verbatim-portable code.

https://auth0.com/blog/compare-mvvm-and-viper-architectures

1) Although perhaps some Dropbox-proprietary key technologies were implemented in C++ libraries that were shared verbatim among the disparate OSes, Dropbox seemed to be accentuating a software architecture where C++ was intimately utilizing Djinni-/etc-generated glue code to invoke native platform functionality.  It is not clear at all that Dropbox was staunchly self-disciplined to keep such glue code at some sort of OS-abstraction •very-lowest• layer on which all 100%-verbatim-portable C++ code at upper layers of dependency depended. (e.g., switching out at the lowest layer of abstraction a) an iOS child package in Ada for b) an Android child package for c) a Windows 10 child package for d) a MacOS child package and so forth).
1.1) It appears that Dropbox never abstracted what running on a touchscreen mobile device is defined to be at its essence via universally-held principles and then they apparently never expressed those principles in writing ••100%-verbatim-portable C++ not-lowest layers•• of code.
1.2) It appears that Dropbox never abstracted what running in a WWWbrowser is defined to be at its essence via universally-held principles and then they apparently never expressed those principles in writing ••100%-verbatim-portable C++ not-lowest layers•• of code either.
1.3) It appears that Dropbox never abstracted what running in a WIMP (windows-icon-mouse) GUI (e.g., Windows; MacOS; Gnome; KDE) is defined to be at its essence via universally-held principles and then they apparently never expressed those principles in writing ••100%-verbatim-portable C++ not-lowest layers•• of code either.
and, most importantly:
1.4) It appears that Dropbox never abstracted 1.1, 1.2, and 1.3 into what running on human-machine interactive technologies in general is defined to be at its essence via universally-held principles and then they apparently never expressed those principles in writing ••100%-verbatim-portable C++ not-lowest layers•• of code either.

https://en.wikipedia.org/wiki/Big_ball_of_mud

Without 1.4, it appears from the outside as though Dropbox enacted a variant of the Big Ball of Mud software architecture where the primary goal was to haul everything back to C++ (for no particularly good reason, other than that-is-just-what-we-do-here-at-this-shop), so that C++ can interact with the platform's OS piecemeal with (stateless, thin-binding) blinders on, where the underlying OS is almost perceived as an opaque remote system without any (stateful, thick-binding) big-picture awareness/coordination throughout C++ world of what the platform's OS was doing as its nonportable lack of 1.4.

2) … ∞) Other than #1's unwise use of Djinni glue code willy nilly as a Big Ball of Mud instead of wisely investing in a verbatim-portable-not-lowest layers of C++ HMI abstraction, what else could comprise an Ada portable solution to Dropbox's now-abandoned goal of implementing 90-some % of their codebase in a portable native-machine-code-compiled language, such as Ada (or C++)?

It seems that Ada suffers from Big-Tech titans' war-on-portability as much as C++.  What can be done to preserve the mantra of write-once portability as a laudable goal in this war-on-portability era?

Re: What can Ada do to survive Big Tech's war-on-portability?

[Dmitry A. Kazakov]

On 2019-08-14 22:12, Optikos wrote:

> It seems that Ada suffers from Big-Tech titans' war-on-portability as much as C++.

No, Ada code is perfectly portable.

> What can be done to preserve the mantra of write-once portability as a laudable goal in this war-on-portability era?

Nothing. The key problem lies in the third party libraries which are 
intentionally or due to honest incompetence suffer from incompatible 
changes and dropping support. Changing language to Ada helps a lot, e.g. 
there is no problem with tasking, but other libraries, lots of, are 
still there.

Using a "native" language for each target will do things only worse. The 
big tech will keep on playing its dirty games, changing APIs, inventing 
other "native" languages etc.

Commercial vendors can do nothing. Big tech's policy is to keep them 
under the thumb. If they cannot they buy and then kill them anyway. 
Non-commercial authors should simply ignore worst of big tech until they 
come to senses. Eventually some of them do.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What can Ada do to survive Big Tech's war-on-portability?

[Lucretia]

On Wednesday, 14 August 2019 21:12:04 UTC+1, Optikos  wrote:
> https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-code-between-ios-and-android
> 
> Dropbox has learned the hard way that the titans of Big Tech (e.g., Google, Apple, Microsoft) have erected semi-impermeable walls around their core technology that intentionally make portability difficult.  Although that prior sentence is semi-obvious for decades, what could Ada do differently henceforth to not suffer the above-linked article's same fate as C++ at Dropbox?


1) Have Ada->JVM and Java bindings without GPLv3 generated code or RTS.

2) Have Swift bindings without GPLv3 generated code or RTS.

Good luck with that.