Is very interesting how people on Microsoft got to the same conclusions that we got: get rid of Java and any other exotic language in the sharing code and use only c++.
Use other languages in the interface for different platforms,or in the testbench code.
We got to this conclusion after years of painful practical problems, but it is hard because it goes against the common philosophy of theoretical people that write best practice books(but not code too much) and natural inclinations of programmers(to use the new shiny thing).
We started like this, sort of a gamble, and until now it never gave us major problems. So it's indeed a sort of relief to see other companies use this road as well.
The core of our software is grabbing data from an external device and signal processing. On top of that we've built a plain C API, an plain C RPC lib over TCP with the same interface as the main C API, and a C++/CLI dll for interfacing with .Net.
On top of that we've built the main C# ui and a lot of custom applications in C/C++/Labview/Matlab/Python. And it all just works which makes me wonder wether there even were other choices than C++ for this particular job.
It's kind of hard to be "Write Once, Run Anywhere" when someone with control over the platform only allows specific runtimes. Of course there are tools that would allow you to write Java for an iOS app and transpile to Obj-C, but you can't directly run Java bytecode for an iOS app.
And for good reasons. Reminds me of the initial complaint about "no flash in iPhone", then someone managed to put it in an Android tablet and then they realised what a bad idea it is.
I want to know why the EU hasn't come down on Apple over this. They're shutting out Flash and Java and yet Google get nailed to the floor despite supporting a pretty liberal, almost completely open source mobile OS.
>I want to know why the EU hasn't come down on Apple over this.
Because it's their platform, and they are not a monopoly in the mobile market (more like 20-30% in EU).
>* They're shutting out Flash and Java*
Yes, amen to that (though it's: Flash and Java applets).
>and yet Google get nailed to the floor despite supporting a pretty liberal, almost completely open source mobile OS.
Well, "almost" is the key word. The main value proposition behind Android is in the Google apps integration, and Google is very adamant about who and how gets that in a MS circa 1995 way.
Besides, the reasons they "nail" Google to the floor has nothing to do with Android, but about it's monopoly on search and the abuses of it.
You are conflating 2 different issues. Apple is a walled garden platform, but while initially it seemed they had a monopoly, google has a much more popular platform in terms of users. However, Google does have a search monopoly, which is why the EU is taking an interest.
And now Android looks just like the return of J2ME fragmentation hell. With each version and device having its own set of device specific APIs, bugs and quirks.
Why keep people mixing languages with implementations?!!
The mobile VM you speak about, were the J2ME VMs, usually done by the device manufacturers themselves, not by Sun.
Java, The Programming Language Specification does not require the Java Virtual Machine Specification to run. Any implementer is free to take any approach to turn Java code into executable code.
We do this as well, targeting Mac, Windows, Linux, iOS and Android with the same C++ core libs. It seemed to be the only way to target multiple platforms without a huge team. It's not all easy though, the work of maintaining the JNI bridge is large, even with most of the code being generated automatically, With the woeful state of native debugging on Android it may have been almost as easy to recode in Java, but maintaining two code bases would have been a real hassle, its hard enough keeping all the UI's in sync.
Same here, C++ for the business logic, maths, engine, etc., OpenGL for the graphics, and then a relatively thin platform-specific layer of Obj-C,Java/JNI,Qt just for the UI. Saved a lot in terms of not having to have multiple teams basically writing the same stuff in different languages.
One of the weirdest things we had to overcome was actually the cultural aspect. For the Linux client, nobody had any problem with the architecture: Get the Qt client working and hook it up to the plumbing. Done. For the iOS guys, still no problem, but let's make sure we separate the C++ cleanly from the Objective-C through a solid, well-understood interface so our food doesn't mix. The Java guys basically threw a hissy fit, objecting to all of this C++ nonsense infecting the purity of their Java. Every time the app crashed: they blamed the C++ code. Every performance problem was because C++. Grandma got sick? C++. When tracking down a bug, they'd step through their Java layer, and as soon as it hit the JNI, they'd just stop and file a bug to the core team rather than dirty themselves stepping through C++. They culturally wouldn't accept C++, and wanted to instead have a separate parallel tree with Java business logic, Java math, Java graphics, etc. The hard reality, however, was that the Android client wasn't bringing in enough revenue to justify a full parallel team and code base. Despite all the grumbling, going the C++ route was a huge success, letting us support multiple platforms with mostly the same code base.
I'm curious as to whether this borderline religious anti-C++ attitude is common in the Java/Android ecosystem, or an outlier? I found it really bizarre.
> I'm curious as to whether this borderline religious anti-C++ attitude is common in the Java/Android ecosystem, or an outlier? I found it really bizarre.
It's a well known result of theory and practice among people who start delving into more provably safe languages.
It's a common article of faith among Java guys, who will tell you that there is no way you can write a safe program in a native language, although they can't really say why (it's effectively hearsay) other than pointers are involved. If Gosling said to use Java, who are they to question it?
For fun, mention that OpenJDK has over a million lines of native code (C and C++: https://gist.github.com/shipilev/2fddb1d2943a4cbb6080 ). Looking at the numbers for the hotspot directory, more than 2/3 of the code in the JVM itself is native code. I realize that this is caused by bootstrapping issues. But if someone believes it is truly impossible to write safe and secure native code, ask how they can trust the JVM to correctly run their safe program, given that it has so much native code.
I know the old argument was that it was easier to audit the (small) amount of native code in the JVM than the code in your specific project. But half a million lines isn't small by any definition I'm aware of. It's larger than any native projects I've worked on.
It's quite likely that the skill and experience level of the average OpenJDK Hotspot committer is a couple notches above the average... and to them things like the manual resource management you have to put up with in C/C++ are not a pointless distraction from their business problem, they are a core part of it.
Besides there are JVMs implemented in Java too, just not with as high performance as Hotspot... search for Maxine or Jikes RVM.
So is it possible to write safe software in a native/unsafe/unmanaged language if you know what you're doing? Wow, that's exactly what I tell people, but it isn't what you read on the first page of any number of Java programming books (of course, those books tell you that you must do manual resource management in C or C++ which is not, in fact, true ( e.g., http://www.apachetutor.org/dev/pools and http://www.artima.com/intv/modern3.html )).
And, really, who wants to use a language designed for people who don't know what they're doing?
I'm not saying that it's impossible to write a JVM in a managed language. Just that it's funny to hear people talk about native languages with a hint of fear, and then run their "safe" programs on a VM that is implemented with a half million lines of C and C++.
SDL was ok for games, but now with a real app, I tried the Qt way, only to discover there are still lots of issues.
So I figured out, better use JNI and C++/CX directly and save the pain of figuring out bugs in Qt.
In the end, the JNI pain is bigger than figuring out Qt bugs and helping those guys.
For small devshops there is a lot of time to be saved by letting third parties like Digia and Xamarin have to go through the pain of writing platform specific wrappers.
If I was doing mobile OSs for work, I would gladly pay for them.
There is another area where this approach is common - games programming. I work on a project which is written entirely in C++, and compiles from the same codebase(and from within the same IDE - VS2012) on Wii/WiiU/X360/XOne/PS3/PS4. It's interesting because every one of them uses a different compiler and builds for entirely different architectures and yet the same code builds on all.
Have you considered writting about your experiences? It would be very interesting to learn more about the good, bad and ugly of developing code for such a range of platforms.
At the moment I can definitely share an Ugly part - the code has thousands of #defines everywhere, and you will find parts with C++11 code(for PS4/X1) and parts which use some hardcore custom methods for everything since they don't have access to STL(for WII....which is a horrible console to write for). So within one file you can see code which uses autos and for each(C++11 parts) and then bits which can't even use Vectors. It's bizarre. And then you have gigabytes of ram on next gen console, but everything you do also needs to fit in the tiny, 128MB ram of WII. It makes you really aware how you write code - which I think is good.
The biggest takeaway for me is that investing in c/c++ paid off immensely for Microsoft. For a massive codebase that's 30+ years old this is a huge win. No other programming language could have and still give that level of ubiquity.
It also highlights how important it was for C++ to have stayed backwards compatible with C, despite the pain.
Yes, absolutely. C++ is the silent workhorse that is used almost everywhere. It's especially huge in embedded and systems programming. There'll be a significant number of programmers paid to maintain and enhance C++ programs for at least the next 50 to 100 years, probably longer.
tl;dr they use a client-server model, then use the ui frameworks that are provided by the vendor.
Really excellent talk, highly recommend it if you're interested in this sort of stuff.
Android is almost Linux. I believe it has been done, although I am not sure about the user experience or the compatibility with native applications, you are still running an x86 computer...
There is a huge difference between your run of the mill desktop distribution and Android - all they have in common is a Linux kernel and that's about it, Android replaces pretty much all user space.
(Also kernel is patched and GPU drivers don't use X compatible interface for acceleration.)
Seriously? If I build my Gentoo differently it won't be Linux, because I used a different userland? Take a look at the link, there is the store running native.
> Seriously? If I build my Gentoo differently it won't be Linux, because I used a different userland?
You're misunderstanding. It's not criticism, but a statement of facts that the only thing Android has in common with most desktop Linux-distros is the kernel. Apart from that they share literally nothing.
Tweaking your Gentoo installation still makes is a Gentoo-installation, and thus a normal GNU/Linux environment.
But if you change the init-system, remove all userspace tools, lock it down so users can't have root, ditch X for something else and only run apps designed for your non-X graphical environment, with each user-facing app running as their own Linux user-account...
Would you call that a "normal" Linux desktop? Probably not. And that's the point. Android isn't conventional Linux. (Which is probably why it's so successful, but that's flamebait for another discussion)
It is also sold off the shelf in big stores where Joe Averages congregate. Get a desktop distro preinstalled on hardware with all the drivers in place and working, and lets see how well it does over the long term (5+ years).
If you replace glibc, coreutils, bash, Xorg, and just about any other part that you as either a developer or user interact with, then no, it's not recognizably linux, any more than the BSDs are Linux. In fact, as far as I know, the BSDs will be easier to port to, because Bionic libc is really a stub, with lots of Posix bits left out.
>>If you replace glibc, coreutils, bash, Xorg, and just about any other part that you as either a developer or user interact with, then no, it's not recognizably linux, any more than the BSDs are Linux
I had to add a driver for a USB device and it was Linux to me. I could not have done the same for BSD (never used it) or Windows using code from Kernel.org . I have personally used an Android kernel to boot one of those arm `mini-netbooks` into xfce.
Indeed you would find that glibc has iterated through different ABIs but we don't call these different operating systems, and we can fix them by simply installing the appropriate binaries.
If I go and get a book on "Linux Programming", it'll tell me a whole lot about file descriptors, mmap, signals, forking processes, threading and so on. Pretty much none of that is available to someone writing applications for Android.
There is hardly anything from a traditional GNU/Linux on Android.
You have a 100% Java based userland, and only a very limited set of C and C++ libraries available to native applications. There isn't even a full POSIX support.
Google could change Linux kernel with e.g. QNX, and hardly anyone would notice.
No, it really isn't. One of the stated goals of the GNU project is to develop an entirely free (as in libre) operating system. Calling Linux "GNU/Linux" allows them to say they've completed that goal, despite little details like their continual failure to deliver a finished Hurd kernel. Linux's userland isn't even primarily GNU software, and I think GNU may not even be the single-largest contributor to the core userland anymore.
AIUI the primary reason why the HURD kernel is not finished is that when GNU/Linux became generally usable, it was de-prioritized and essentially turned into a research project.
Use other languages in the interface for different platforms,or in the testbench code.
We got to this conclusion after years of painful practical problems, but it is hard because it goes against the common philosophy of theoretical people that write best practice books(but not code too much) and natural inclinations of programmers(to use the new shiny thing).