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 2002:aed:3327:: with SMTP id u36mr986665qtd.94.1565813523781; Wed, 14 Aug 2019 13:12:03 -0700 (PDT) X-Received: by 2002:a05:6830:1aee:: with SMTP id c14mr813270otd.22.1565813523513; Wed, 14 Aug 2019 13:12:03 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!f14no560531qtq.0!news-out.google.com!d29ni1478qtg.1!nntp.google.com!f14no560530qtq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 14 Aug 2019 13:12:03 -0700 (PDT) Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.223.245; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.223.245 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6bbf496c-6067-4047-ac48-d26f69bbfe4a@googlegroups.com> Subject: What can Ada do to survive Big Tech's war-on-portability? From: Optikos Injection-Date: Wed, 14 Aug 2019 20:12:03 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:57061 Date: 2019-08-14T13:12:03-07:00 List-Id: https://blogs.dropbox.com/tech/2019/08/the-not-so-hidden-cost-of-sharing-co= de-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 te= chnology that intentionally make portability difficult. Although that prio= r sentence is semi-obvious for decades, what could Ada do differently hence= forth 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 fr= om the 100%-verbatim-portable code. https://auth0.com/blog/compare-mvvm-and-viper-architectures 1) Although perhaps some Dropbox-proprietary key technologies were implemen= ted in C++ libraries that were shared verbatim among the disparate OSes, Dr= opbox seemed to be accentuating a software architecture where C++ was intim= ately utilizing Djinni-/etc-generated glue code to invoke native platform f= unctionality. It is not clear at all that Dropbox was staunchly self-disci= plined to keep such glue code at some sort of OS-abstraction =E2=80=A2very-= lowest=E2=80=A2 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 fort= h). 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 princip= les and then they apparently never expressed those principles in writing = =E2=80=A2=E2=80=A2100%-verbatim-portable C++ not-lowest layers=E2=80=A2=E2= =80=A2 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 th= ey apparently never expressed those principles in writing =E2=80=A2=E2=80= =A2100%-verbatim-portable C++ not-lowest layers=E2=80=A2=E2=80=A2 of code e= ither. 1.3) It appears that Dropbox never abstracted what running in a WIMP (windo= ws-icon-mouse) GUI (e.g., Windows; MacOS; Gnome; KDE) is defined to be at i= ts essence via universally-held principles and then they apparently never e= xpressed those principles in writing =E2=80=A2=E2=80=A2100%-verbatim-portab= le C++ not-lowest layers=E2=80=A2=E2=80=A2 of code either. and, most importantly: 1.4) It appears that Dropbox never abstracted 1.1, 1.2, and 1.3 into what r= unning on human-machine interactive technologies in general is defined to b= e at its essence via universally-held principles and then they apparently n= ever expressed those principles in writing =E2=80=A2=E2=80=A2100%-verbatim-= portable C++ not-lowest layers=E2=80=A2=E2=80=A2 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 varian= t of the Big Ball of Mud software architecture where the primary goal was t= o 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 t= he platform's OS piecemeal with (stateless, thin-binding) blinders on, wher= e 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) =E2=80=A6 =E2=88=9E) Other than #1's unwise use of Djinni glue code will= y nilly as a Big Ball of Mud instead of wisely investing in a verbatim-port= able-not-lowest layers of C++ HMI abstraction, what else could comprise an = Ada portable solution to Dropbox's now-abandoned goal of implementing 90-so= me % 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?