No matter how bad the Greek crisis gets, no matter how much of a haircut people get on their savings from any currency swap, it will still be less risk than bitcoin.
Same principle applies to Adobe and Flash. They make nothing from the Flash player but its all those eyeballs are what make professionals want to buy the dev tools that they do make money from. Cheapen the brand and it goes into decline.
I got so fed up of Adobe loading their updates will crapware like McAfee that I stopped installing it altogether. Likewise I've avoided other products which have started bundling stuff in their installers. I'm sure Oracle are compensated for promoting Yahoo from their installer but the reputational damage will suffer could be immense.
Porting a C++ application from Windows to Linux means writing it with portability in mind from the very outset, sourcing which libraries you use, rebuilding the code from source and screwing around with the vagaries and differences of different compilers and toolchains. Even in the best of circumstances the code is likely to be plastered with #ifdefs and conditionally compiled code to deal with differences. The best bet would be something like QT which is fairly portable and has a large support library but it's still not as simple as Java.
Bzzzt, wrong. Motorola is the one that implemented the modified Ubuntu desktop when docking the Atrix. It was not Canonical that did that.
Bzzt, wrong. Canonical did although Motorola may have licenced what they produced or cooperated.
I should imagine that programming a car is way too complex for IL or STL and the temptation would be to use C++ but clearly that is a fraught issue, particularly in safety control systems. It probably doesn't matter at all if the media player uses C++ as long as it's running on a separate system entirely.
I'm kind of surprised that Microsoft haven't done something like that yet with an Atom powered phone. As for Ubuntu, I hope for their sake they are because I don't see much reason to use a phone running Ubuntu Linux otherwise.
Your solution to the problem is to try to kill the problem of bad developers by hiding it with the language.
It has nothing to do with "bad programmers". A programmer in one language can be expected to make the same number of errors in their code as a programmer in another. And they can be expected to have a similar spread of competence in their chosen language. It's about how many of those errors make it into the final product, the effort required to test / find / fix them, and the dangers (e.g. to safety, security) if they reach the final product.
C++ suffers from a whole class of problems that are minimal or even non existent in others - memory corruption, heap under/overflows, leaks, bad pointers. That's why languages like C# and Java took off - because companies can deliver a higher quality product in a shorter space of time.
It's also why C++ may find itself being sidelined by the likes of rust, swift etc. These languages offer comparable performance to C++ but will catch errors that C++ wouldn't even notice were errors. In particular rust has been explicitly designed to prevent pretty much every segfault that C++ could suffer from which in a safety system (e.g. running in a car) should be regarded as a good thing.
No no no, you wrote a C++ compiler and you don't even understand why C++ is successful? It's because it still compiles all the old code. You DO NOT deprecate types that are in use in working code. I'm not sure "long double" is in fact used in any working code, but "long long" is THE 64-BIT TYPE so you don't fucking deprecate it.
This is a stupid justification. Gcc already has switches for different standards, -std=c++98, -std=c++11 etc. There is absolutely no reason whatsoever to stop certain functions, and language features from being deprecated or removed in new standards. If people still want to compile old code they can throw the switch in there and they get that functionality. If they don't, the compiler defaults to the latest version of the standard.