That is a bunch of bullshit. There were several JVMs and then all the bits that are different on each platform were different on each platform. There were many versions of Java. There were probably more back then, since IBM was bothering to promote their own JVM, among others.

In Python you can do that from another thread. Not that you'd ever want to. But the code has to be prepared for that. In Javascript, you can tell at compile time if the code is doing that to itself.

The optimization killer in Python is that the compiler can never look at a block of code and decide "X can't happen between these two statements". Because in Python, it can. That kills most loop-related optimizations.

Where are the cyber weapons? Already deployed and awaiting activation. Undocumented errata in major CPUs which allow bypassing memory protection. Preset keys in network cards allowing remote administration. Undocumented admin passwords in network firmware. Code signing certs in the hands of intelligence agencies. That's where.

Arguably, it should have been Python, which is a better language. But Python has a problem. Python's little tin god, Guido von Rossum, is in love with his own implementation, CPython. CPython is a naive interpreter. (A "naive interpreter" is one which does the specified operations in the specified order, with little optimization across operations.) In CPython, everything is a dictionary and a lot of time is spent doing lookups. This allows everything to be dynamic. In Python, one thread can patch objects in another thread while both are running. Objects can gain or lose elements on the fly. Even running code can be "monkey-patched".

The price paid for that excessive dynamism is that a Python compiler is hard to write, and an optimizing Python compiler can't optiimize much. Google tried in-house to make Python faster, and their "Unladed Swallow" failed humililatingly. (A different group at Google then developed Go, aimed at the same problem of producing something good for server-side processing.) The PyPy crowd has tried, hard, to make an optimizing Python compiler, and with an incredible amount of complexity under the hood, has made considerable progress, but not enough that PyPy is used much in production.

Pascal went down for a similar reason. Wirth was in love with his elegant recursive-descent compiler. But it didn't optimize, couldn't handle separate compilation, and had no way to handle errors other than aborting. Python seems to be headed for similar irrelevance. It hasn't even been able to replace Perl, which ought to be as marginal as "awk" by now.

The article says "factories are static". In reality, only factories for long production runs are static. Many factories are constantly setting up production lines, running them for weeks or months, then reconfiguring for a different product. This is expensive, slow, and often requires a completely different workforce than the one used during operation.

The ability to set up a production line with robots would be useful. One reason that production lines for smartphones are so manual is that the product life cycle is so short. The production engineering and plant setup time is long for a robotic assembly line. Faster line changeover would be a big win for fast-changing product lines.

One of the better robotics ideas of the 1980s was a pair of small, cooperating forklift-type robots. A pair of these could pick up and move a couch much bigger than the robots. It's time to revive that idea.

That is commonly untrue on items which cost any significant amount of money, which typically have free shipping.

On the flip side I live in bumfuck and the only carrier I've found to be more reliable for delivering to my rural address than OnTrac is California Overnight, which is even more local and even smaller. And shockingly inexpensive, judging by what people have paid to ship things to me via them.

So how much of your time are you going to spend to one-up the Russians, well-educated in maths, by creating convincingly fake data?

yes

They seem to still have pretty free-flowing exhausts. Is there any chart or other evidence which might prove this one way or the other?

Nadella used to run Bing. Bing had a leadership vacuum after he left (and still does), but it didn't do all that great while he was there.

Microsoft's approach to Bing upper management is very strange. Microsoft sends people there, but you never hear about them while they're there. You hear about them after they're promoted to better parts of Microsoft. Mark Penn was brought in to turn around Bing, and accomplished little there. Now he heads Microsoft Advertising. Qi Lu ran Bing for a while, and now he's head of Applications and Services. So failing to turn Bing around doesn't seem to hurt executive careers at Microsoft.

Reading comprehension failure level: maximum. I didn't say it was a problem with Java. What I said is that those phones had shitty Java support. Since I've owned and hacked on the V300, V500, V555, the original RAZR and two of the later RAZRs and run dozens of different Java MIDlets on all of them, I am well-versed.

Yeah, and the other thing those phones did have, again speaking of those crappy Triplets phones and their descendants, was a very slow processor and very little memory. They weren't capable of running a decent web browser even by the mobile standards of the day, for example.

Define "supported" and "Java apps". At the time, Java was even more fragmented than it is now. Java could mean all kinds of things, but the Java you found on a Motorola Triplets phone or its descendants (including the RAZR, which I owned two models of) was pretty mean. Java applets had to be specifically designed to run on specific device families, and the applets for a Siemens or Nokia phone would commonly crash on a Motorola phone, and vice versa.

What some employers want are Stakhanovites. Most don't really want "failure is not an option" types, who want off-site backup systems, fail-soft recovery, a Q/A organzation with the authority to delay deployment, expensive testing tools, automatic code analyzers... Most don't want programmers who polish their code until it's beautiful, like MIT students are taught.

If you save the images then you avoid loss. I used to use scrapbook plus and then extract them from there, now it's gone I just save to a temp dir, and loot the images directory for the largest files. I also use an extension which saves straight to a directory, which still works when the context menu save image item is missing.