Portable software is more complex than you think • Hacker News Board

Re: Portable software is more complex than you think

#21

Post by pjmlp » Wed, Dec 08, 2021, 11:17 AM UTC

rectang wrote: post #13

omnicognate wrote: post #11

Earlier quoted context omitted.

I wrote an iOS app. I ported it to Android. The only part that didn't need to be rewritten from the ground up (and it worked completely unmodified) was the part written in C. If you have the same APIs available (OpenGL in this case) C is the most portable language there is. Which proves it's not a language issue, it's a platform issue. In fact the owners of the platforms care so little about (indeed actively oppose)…

> the one language that works everywhere and which they have no choice but to support: C I've been tinkering with Rust bindings for Apple Core Audio. AUGraph, which has a C interface, was deprecated a few years ago. Its replacement, AVAudioEngine, has an Objective-C/Swift API. :( There are a lot of generalized cross-platform libraries for guis, audio engines, etc, which attempt to abstract over the differences betwee…

Here is another one for you, the modern networking stack is also Objective-C/Swift.

Re: Portable software is more complex than you think

#22

Post by ansgri » Wed, Dec 08, 2021, 3:12 PM UTC

api wrote: post #17

A good pattern is to separate the core logic from the code that interacts with the platform. If these are tangled up porting becomes a nightmare. Our approach to portability in ZeroTier is to make the core, our "network hypervisor," a completely OS-neutral chunk of code that interacts only via an API. It contains literally no system calls, I/O, etc. Then there's a service harness for desktops, servers, phones, etc.

The problem is, for this to work the API itself must be cross-platform, which means it's either an incomplete abstraction (exposes many options, only some of which are implemented on a given platform), overly restricting (lowest common denominator leading to suboptimal performance and restricted development agility on advanced platforms), or not really cross-platform (supports one platform well but others are inefficient -- might as well use a virtual appliance).

In reality the API is part of the core logic except for purely computational services and therefore all core logic can rarely be fully encapsulated.

Re: Portable software is more complex than you think

#23

Post by weq » Thu, Dec 09, 2021, 6:51 AM UTC

omnicognate wrote: post #11

nynx wrote: post #5

Portability of software is a language problem. Some languages make it extremely easy. Others, like C and Go, make it difficult to be correct across all platforms.

I wrote an iOS app. I ported it to Android. The only part that didn't need to be rewritten from the ground up (and it worked completely unmodified) was the part written in C. If you have the same APIs available (OpenGL in this case) C is the most portable language there is. Which proves it's not a language issue, it's a platform issue. In fact the owners of the platforms care so little about (indeed actively oppose)…

Id argue C# is THE portable version of C

if you wrote your iOS app in Xamarin, u could today run it on .NET6 pretty much unchanged. I maintain multiple store apps where i share 90% of the code across all platforms (iOS/Android/Win/macOS) that have extensive integrations with the OS. I can even drop down to native obj-c, java, win32, macos apis as required using the same syntax as any other library thanks to the code-gen MS does. I use powershell for scripting. Dont need a full app? I can have native islands as well or be an island in another native App.

https://www.youtube.com/watch?v=kesUNeBZ1Os

Re: Portable software is more complex than you think

#24

Post by weq » Thu, Dec 09, 2021, 6:52 AM UTC

rectang wrote: post #13

omnicognate wrote: post #11

Earlier quoted context omitted.

I wrote an iOS app. I ported it to Android. The only part that didn't need to be rewritten from the ground up (and it worked completely unmodified) was the part written in C. If you have the same APIs available (OpenGL in this case) C is the most portable language there is. Which proves it's not a language issue, it's a platform issue. In fact the owners of the platforms care so little about (indeed actively oppose)…

> the one language that works everywhere and which they have no choice but to support: C I've been tinkering with Rust bindings for Apple Core Audio. AUGraph, which has a C interface, was deprecated a few years ago. Its replacement, AVAudioEngine, has an Objective-C/Swift API. :( There are a lot of generalized cross-platform libraries for guis, audio engines, etc, which attempt to abstract over the differences betwee…

Exactly what Microsoft does with Xamarin, has extensive tooling to generate platform bindings on every update. I can interop with RUST with no-low overhead as needed.

Re: Portable software is more complex than you think

#25

Post by weq » Thu, Dec 09, 2021, 7:12 AM UTC

ansgri wrote: post #22

api wrote: post #17

A good pattern is to separate the core logic from the code that interacts with the platform. If these are tangled up porting becomes a nightmare. Our approach to portability in ZeroTier is to make the core, our "network hypervisor," a completely OS-neutral chunk of code that interacts only via an API. It contains literally no system calls, I/O, etc. Then there's a service harness for desktops, servers, phones, etc.

The problem is, for this to work the API itself must be cross-platform, which means it's either an incomplete abstraction (exposes many options, only some of which are implemented on a given platform), overly restricting (lowest common denominator leading to suboptimal performance and restricted development agility on advanced platforms), or not really cross-platform (supports one platform well but others are ineffic…

You need to design your system with appropriote trade-offs. If you want to be everything to everyone you will end up in mess you describe. Cross-platform game, coreutils or LOB are all different beasts. Unity shows how API surface level will get polluted as you strive for speed in your cross-platform game, but on the flip side you run on all platforms without overhead.

I tend to use DDD and the egg-shell pattern, building a domain / service model in portable code, and leaving the platform specific code to the outer shell behind a refined abstraction. I dont have any APIs with overloads, but sometimes the backing API is a no-op.