You're of course correct.
But if you look at the development of phone radios.. you'll see that the handsets are getting so over the top ridiculously complex, with like 30 different frequency bands, MIMO and at least 5 topologically different radio technologies. They need those 4 core CPUs in "smart" phones just to handle radio comms.
Just try fitting all those antennas and other crap inside a watch.

I'd say 6 months is the minimum battery time for a device to be called a watch and not a wristband-PC.

It is feasible, (1-3yrs) just depends how smart your watch really is.
These full blown PC-operating systems running on "watches" with full colour displays are obviously never going to have more than a few days battery time.

Because it's not the right solution for every problem, and if you make languages that *force* this kind of behaviour, the shitty programmer will just put their bugs elsewhere.
The solution is to simply write better code.

That's not how it works, old solutions are still being used because they work incredibly well, and if not, they are improved.
The younger engineer may not know that and sometimes gravitate towards advertised solutions.

When talking about development, in most cases there's nothing new under the sun. Programming languages and tools haven't really improved for the last 40 years.
Most of the new stuff is simply hot air, has been tried before and failed, and the experienced developers know this. They also have the ability to more readily recognise when something truly is novel and an improvement.
Development is one of those areas where age is clearly a massive factor in the quality/productivity of a worker since younger engineers have had less time to learn their job.

In terms of features and overall syntax.
Details are unimportant when most new languages arguably are doing the same things as languages from 20-30 years ago.

I'm actually vehemently against using multiple languages, especially languages with large runtime requirements.
We already have too much fragmentation of incompatible code libraries getting written in 300 different scripting languages.
It's especially pointless when you realize there really is nothing new under the sun.

A language isn't just a tool. The situation is the equivalent of people writing down technical literature in Esperanto and everyone else picking their own language.

I think you like recursive solutions.

I'm sure everyone was thinking, we don't have enough languages that are basically a badly implemented subset of C++. We need to make another one.
Let's see if Android will respond by creating an even less compatible C++ clone than Java.

I'm of the same opinion, I like cars that are easy to muck around with, like jeeps etc. when something fails.
And what's one of the most common modes of failure in modern cars?
You guessed it, broken computer.

And no, I don't want to pay for redundant systems, I'd prefer a compromise where you might have steering separated to simplistic joystick control for when your "big" mcu inevitably fries.

I'm appalled by the polarity and extremism on this topic, even from a /. standpoint.
Different vaccines are not created equal. Many have been so successful in eradicating disease, that there's no question about their effectiveness.
But lately, the medical industry has grown accustomed to hiding large parts of unfavourable test results, as we are now starting to find out.
There's ample evidence (or lack thereof) to be worried about and avoiding some vaccines.
As with anything, extreme measures require extreme amounts of evidence.

Case in point, that's why they're freezing the water around the reactor.
Radioactive slushies is the next big thing.

Ever heard of ground water?

Did they produce cars in Detroit?

The car horn will be used for wireless communication between cars because radio and light are just not cool enough anymore.

PR stunts cannot erase the bloodstained governance that plagues this military-apartheid state.