While I fully agree with the losing something in translation. I don't agree that people are trying to skip learning things. It is a do I want to do 100% of my software development 3 times because I need a java version for one platform, Objective-C for the second and C# for the third.
Oddly enough it seems like C++ is the only language all three platforms support natively.
Oddly enough it seems like C++ is the only language all three platforms support natively.
Indeed. But it's also quite harder than those to develop in.
I hate to keep on button-mashing, but it would be a big win to have a PlusPlusScript language - as in same philosophy and approach as CoffeeScript, but targeting C++ [1].
Mono for iOS and Android and MonoMac for OSX all have different API calls for their respective platforms. GTK# is its own thing too. You might avoid a total rewrite from scratch, but the UI is going to need significant tailoring to each platform still. And it's not like Java, ObjC, and C# are radically different from one another.
Does keeping C# as a constant really solve this problem? (I honestly don't know, I've never done a multiplatform product like this)
Well, in most cases the GUI stack will be different anyways. There is no "official" Android or iOS support from Nokia / QT for instance.
I've deployed ASP.NET MVC apps on Linux / Mono and it was a relatively painless experience. The desktop and RIA guys in .NET land are doing their own thing with WPF and Silverlight (google MVVM / Caliburn-Micro), and frankly, it's freaking me out a bit. There's a tendency to overengineer and abstract everything. It might not be as bad as with Java but the tendency is still there.
For instance, the .NET community has been arguing for years about domain driven design and how you should abstract away (or not!) database access. Hundreds of blog posts about which application layer should be concerned with this and that, about generic data access repositories, enhanced query objects and so on. What was "the way to go" one day was suddenly "the new singleton". Some guys eventually came up with the glorious "CQRS" approach (inspired by Betrand Meyer's command query separation) and built entire frameworks such as NCQRS with separate read/write stores, event sourcing and audit trails. The problem is that a lot of people start to use these enterprise models in very simple applications.
I'd also say that the 3 mentioned languages are, in their current incarnations, very different from each other. Java itself looks rather stagnant to me? I don't know, the last time I checked I saw former high school / college friend of mine starting a serious open source effort for easier database querying because he was so fed up with hibernate - it's basically one gigantic DSL / fluent interface that generates sql. Me: "Why don't you use lambda expressions.. oh wait, ...".
Welp, here's an example. My project Flatland[1] is intended to be a 2D games library, providing graphics, audio, input, content loading, and a few other bits. My target platforms are Windows, Mac, Linux, iOS, Android, and WP7.
With a properly architected solution (and I like to think mine comes close) with sufficient abstraction, I literally can write a game once--with allowances for fundamental platform differences, i.e. "is this a touch device? then show on-screen controls, but wire them to the same backend logic"--and deploy it everywhere. I can't do that with a Java engine on Android and an Obj-C (ugh) engine on iOS, because there is no reasonable lingua franca. C#, on the other hand, works fairly well everywhere. The platform-specific bits are small, clearly delineated, and shouldn't take long to do (it's Windows-only for now).
That's true. I don't have to deal with native UI libraries. Instead, I also have to deal with disparate interfaces to graphics, audio, sound, the file system (if it's accessible at all), the content loading paradigm for the platform (relevant esp. for Windows Phone 7), timing differences between the platforms, and a number of other issues. I have to develop and code to lowest-common-denominator interfaces that contain a lot of hidden gotchas and limitations, and make the presented interface work identically on all platforms.
I'd take re-coding my UI layer over having to write near-identical code for XNA and OpenGL, then writing near-identical code for OpenAL, XNA, and Core Audio, then writing widely divergent input code for XNA and whatever not-well-standardized gamepad layers I can repurpose or build for Linux and OS X and the different touch frameworks...
Having to write all of this stuff is arguably on par, if not more complex and difficult, than reimplementing a UI layer. It's not a "luxury" at all.
Knowing that each API is slightly different there are two paths you could take. An MVC like approach where everything platform specific is sectioned off in the view and just have totally different views for each platform. The second is use the dependency inversion principle, and build a layer that abstracts the underlying api away then depend on your abstraction instead of the underlying API. Either way you end up writing 70%-80% of the code once, and 20%-30% of the code three times. Not great but it beats writing 100% of the code 3 times.
Is C# the right language to do that in, maybe, maybe not but it is an option.
Oddly enough it seems like C++ is the only language all three platforms support natively.