I might not be paying them money directly but I'm certainly making them money. Developers and companies pay Oracle for tools, support, certification, training for Java and they do it because there is a demand for the language. If the brand is cheapened then ultimately it will hurt them in the wallet.

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.

The first contact many have with a new product is the installer. So what are companies doing to make a good first impression? Conning them into installing adware / crapware or changing their browser settings. It's insulting, it undermines trust and it cheapens the product by association.

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 Java application from Windows to Linux is normally as simple as copying the compiled .jar / .war / .ear over and just running it. The only reason it might not be is it contained JNA or if someone had hardcoded an assumption about the OS into it. Ordinarily neither would be the case and it is not unusual for people to be developing software which ultimately runs on big iron Unix from PCs at their desk.

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.

Yes and Canonical worked on it too.

Bzzt, wrong. Canonical did although Motorola may have licenced what they produced or cooperated.

The Atrix had a dock which turned the Android phone into an Android tablet. Ubuntu hacked it so when you docked the phone it became a proper Linux desktop. How they did it I don't know, but I assume there was some virtualization going on.

PLCs would typically be programmed via IL or STL these days which are designed to be safe (no memory allocation, pointers etc.). Some PLCs even have multi channel execution where the same program is loaded and run on two or more different implementations and if the outputs don't match for the same inputs the PLC goes into error.

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.

A segfault in this instance caused by a programming error, not a hacker. And no, they're not good things, particularly if we're comparing two languages, one which will blissfully compile that error straight into your production code and another which tells you about it at compile time.

Ubuntu hacked a Motorola Atrix so it ran Android when you used it like a phone, but plug it into a dock and suddenly it became a full blown Linux desktop. That's a concept ripe with potential. Doesn't have to be Android of course, but just the idea that it's a phone when you carry it around but you can use it as a computer too with a dock with some ports on it.

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.

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.

So you intend to drive around in a shit heap all your life to avoid the very slight possibility that your car will be hacked?

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.

The English language isn't defined by a committee which has the opportunity to fix longstanding issues with the language or deprecate redundant, arcane or dangerous functions and code. C++ does have this opportunity but never takes it. Instead it just heaps another layer of features on top of the old, we all sit around for years waiting for the compilers to implement this mess properly and by then another standard has come out.

Personally I wouldn't choose C++ or C unless there was very a strong justification. If your code spends more time waiting for something to happen than actually doing something, then you shouldn't be using a low level language. If reliability is more important than raw performance then you shouldn't be using a low level language. If portability is important then you shouldn't be using a low level language. Conversely if you need to do lots of IO and / or control the file format, or interact with system / kernel services, then perhaps a low level language is suitable.

Boost is a very powerful addition to C++ but that doesn't mean it's as easy to write code as it is in a high level language. e.g. boost's asio is extremely complex and even doing something simple with it like setting a timer is far more pain than other languages. Boost doesn't implement stuff like web sockets or other things either so it's no good on its own without other libraries. If I had to write something in C++ which was performing in a role that would more naturally fall to something like C# or Java, I'd probably use the QT library instead but only after being certain that I needed C++ to begin with.

And that in a nutshell is what's wrong with C++. It has bloated and bloated over the years, never deprecated anything of note and now its this behemoth that few compilers implement in its entirety and few programmers now how to use including all the gotchas, weird semantics and vast complexity.

It's unsurprising that most application development jumped ship to something higher level. It will be interesting to see if languages like rust eat into the systems programming aspect.