I live in Norway. Most people here drive stick-shifts. I can guarantee you that the vast majority of people driving stick-shifts have no idea what synchro rings are, nor would they be able to point them out if you cracked a gearbox open and told them to point them out. So yes, the simile is flawed.
As for the usefulness of learning C or C++, I do think it is useful as a learning exercise. As would assembly programming be.
I have met developers who considered themselves "experienced" who are unable to estimate memory requirements for simple data structures. I've had people tell me that pointers are "about one byte" and people who insist that the most compact way to store a boolean value is as an int value.
Note that he said well. Yes, you can drive a stick to work and the grocery store without learning anything significant about it at all, just like you can write "Hello World" programs in C++ without really knowing anything about pointers, dynamic mem allocation, etc. But in both cases, to be able to do anything significant, you'd need to learn more than the absolute basics.
More often than not it is not the language that decides the performance of a system, but the ability of the programmer to come up with sensible designs.
This becomes even more important as parallel and computing becomes more important. Designing and implementing systems that run on a single CPU isn't all that hard given all the tools, libraries and abundance of literature developers have access to at little or no cost. Writing software that spans CPUs and even computers is a different matter.
Writing an application like Twitter isn't hard. Making it scale shouldn't be, but apparently still is. Doing twitter in C++ might offset the problems they experience somewhat, but not meaningfully so.
"More often than not it is not the language that decides the performance of a system, but the ability of the programmer to come up with sensible designs."
A lot of people forget that. Most of the software I've encountered that displayed performance problems did so because of endemic architectural flaws and bad code. Pointless complexity usually leads to slow software.
In most well-written applications, you wouldn't be able to tell the difference between a version on C++ or a version in Java, because the software is rarely the bottleneck. Obvious exceptions are applications like games and 3D animation systems, where there's a lot of computation going on all the time.
A well-written word processor in Ruby might well feel MORE responsive than a poorly written one in C++, for example.
By today's standards, your surveillance solution would qualify as an embedded solution and a fairly resource constrained one at that. It would make sense to use C or C++ in that situation: you can afford to spent a lot of effort on a fairly minimal set of features.
The same may not apply for other projects. I for one spend most of my time worrying about IO, availability and how to best take advantage of multiple CPUs and cores. In this, C++ isn't exactly giving developers anything for free (concurrency still not even being part of the language).
As for Java on mobile: there are projects that are going that route. I'd wait and see before I postulated whether this is a good idea or not.
I don't really understand how Vista fits into this discussion at all. In my opinion, Vista is the result of developers being paralyzed by the sheer weight of their legacy code and interoperability with legacy code. Completely different issue.
As for Java on mobile: there are projects that are going that route. I'd wait and see before I postulated whether this is a good idea or not.
I'm sure you've seen "Java: Please Wait..." on tiny mobile screens with famous Java logo (cup of coffee). I am yet to run into "Please Wait: Objective-C..." screen on the iPhone.
The main difference being that finding the memory leaks in Java, or rather: unintentional object retention, is far simpler than in most C++ environments.
As for the usefulness of learning C or C++, I do think it is useful as a learning exercise. As would assembly programming be. I have met developers who considered themselves "experienced" who are unable to estimate memory requirements for simple data structures. I've had people tell me that pointers are "about one byte" and people who insist that the most compact way to store a boolean value is as an int value.