Live data from Hacker News

The not so hidden cost of sharing code between iOS and Android

blogs.dropbox.com

331–335 of 335 posts

Re: The not so hidden cost of sharing code between iOS and Android

#331
post #325
post #324

Earlier quoted context omitted.

Ah, still being creative with names, I should offer you a name calling dictionary. I don't need to dismiss anything, the industry giants haven spoken, multiple times since the early 80's on graphics API adoption. Nice way to avoid talking about lock-in in OpenGL, WebGL and Vulkan OEM private extensions. As for Dan Baker, you put words on his mouth, while I show him actually speaking....

> I don't need to dismiss anything As for Dan Baker, you put words on his mouth Sure, keep pretending it didn't happen. Totally not a shill thing to do ;)

Still waiting for the proof he actually said that.

Then again, I expect you to just keep on doing the name calling thing.

Re: The not so hidden cost of sharing code between iOS and Android

#332
post #330

Earlier quoted context omitted.

I don't know what point you're trying to make. MSL doesn't link with the rest of your program. No matter what language you use for your program, the shaders are written in MSL. For my program if I use Rust or C++ or Obj-C or Swift or a microscopic magnet and a very careful hand, I write my Metal shaders in MSL.

1 - MSL is a set of extensions on top of C++14 2 - Metal requires MSL 3 - IO Kit is a C++ framework for macOS, iOS, iPadOS and watchOS drivers 4 - Metal GPGPU drivers are written in IO Kit 5 - Metal is useless without MSL and GPGPU drivers 6 - Ergo, Metal requires C++

The fact that Metal itself requires the existence of C++ really has nothing to do with this topic though, which is whether there's any downside to writing your app in a language that Apple doesn't ship a compiler for. The fact that Metal shaders are written in a language based on C++ is irrelevant to this question, because it doesn't matter what language you pick for the rest of your app as Metal shaders don't link with your app. Swift has zero integration with C++ and yet I can write a Metal app using Swift, because the fact that the shaders are written in MSL has no impact on the fact that the app uses Swift.

And the language for writing drivers in is even more irrelevant because we're not talking about writing drivers. You can't write drivers in Swift either.

Re: The not so hidden cost of sharing code between iOS and Android

#333
post #192

Earlier quoted context omitted.

I really despise Electron apps. They always seem bloated and antagonistic toward the native user experience on my platform (eg. inferior keyboard support, hard to integrate with custom tooling like AutoHotkey, etc.). Have I just not used the right ones?

Visual Studio Code is probably one of the best received Electron applications. Tried it?

I'm not him, but yes. It's certainly nowhere near a native Mac app, and apparently that's the absolute best Electron has to offer.

Re: The not so hidden cost of sharing code between iOS and Android

#334

The best way I've seen this work (inside Google Apps) is to write shared business-logic in a common layer (here it (often) gets written in Java, then transpiled to Obj->C and Javascript, other teams go from C++ -> Java & JS, and other other teams embed JS inside of everything.. and other other other teams write everything in a native language (there is no one single way at Google)) then use a data-definition-language…

Oooor, you could just use Kotlin and Swift and be done with it.

Re: The not so hidden cost of sharing code between iOS and Android

#335
post #176
post #15

I have come to this same conclusion after many years. It's not cost-effective to have any bespoke business logic (models, controllers, etc.) shared between the two mobile platforms (don't get me started on sharing UI code). If you have some incredibly tricky low-level algorithm/library and/or need for speed, think database, crypto, intense graphics, etc., then fine, you may be able to swing a shared module in C++ or…

Years ago I wrote a programming language a bit like Haxe, except that it let you 'inject' snippets of your target language wherever you wanted. So you could keep your major architecture in one common language and still implement specific cases on the spot (ie you don't have to go to other files, and the various implementations for different target languages were right next to each other, making it easier to keep them…

> a bit like Haxe, except that it let you 'inject' snippets of your target language wherever you wanted.

If I understand you correctly, this feature is available in Haxe : https://haxe.org/manual/target-syntax.html

It targets js, php, C++, has a proper team and good tooling.. so you might be interested in giving it a try.

Post reply on HN