Another industry we can outsource to China! Look at all the money we'll save!

Times have changed. Languages are essentially irrelevant; if you have a reasonable background, you can pick up whatever languages (note plural) you need.

The question a couple of years ago was "what libraries?" There's probably a library that does what you want; use whatever language it's written in. Yeah, I know, everything eventually reduces to C, but like most things, it ain't that simple.

The question now is "what frameworks?" Nowadays, you don't develop programs from scratch; you start with a framework and build on it. Using Ruby on Rails? Write in Ruby. Using Django? Write in Python. Node? Write in JavaScript. Hadoop? Write in Java.

That said, the only two languages that it's really necessary to be fluent in are C and JavaScript. C is, of course, the language that most of the rock-bottom stuff is written in. A lot of systems produce C as intermediate code, and, as a result, a lot of C-isms tend to sneak into places you wouldn't expect. Learn your pointers. JavaScript is the only language that will run inside a Web browser *; if your code touches a browser, it will use JavaScript.

* Yeah, I know; Java applets. I don't know which is more painful -- writing them or using them.

IIRC, the last actual one-on-one dogfight an American fighter was involved in was in Vietnam. Everything since then has been long-range missiles and control from AWACS planes. And air-to-air missiles can be carried by drones as easily as air-to-ground.

In pure dogfighting capability, the latest from MiG and Sukhoi would eat the lunch of anything we have, or are likely to have in the near future. We could buy them from the Russians for a lot less than we could build our own.

Another issue is that the US doesn't build "fighters". The planes we call "fighters" are actually light attack bombers. Very fast and maneuverable attack bombers, true. But that dual role is one reason why they're so bloody expensive. The Russian planes are real "fighters" -- short range and no particular capability for lugging JDAMs around.

So let the ion engine guys have some fun designing a "space tug". Pick up junk and tow it to a nice stable orbit somewhere, probably just outside geostationary orbit. Later, when we need a counterweight for a space elevator, we have a nice big hunk of mass that's already just sitting there.

For smaller stuff (paint chips and so on) I like the idea of a big sponge (open-cell foam) in an eccentric orbit. It'd make a few dozen orbits, pick up junk on the way, and then re-enter naturally (big == air resistance in LEO). It'd probably be really pretty, too.

In WWII, somebody had the bright idea of putting calibration marks on contact lenses for aircraft spotters. The markings might as well have not been there. Turns out, if something isn't moving relative to the retina, the brain tunes it out, and it disappears. (That's why your eyes are always making little jiggling motions -- keeps the image moving on the retina.)

Now, if they have something that will project an image directly onto the retina, *that* would be something ...

As others have pointed out, the main Java GUI (SWING) is a real pig. This is a result of Java's "compile once, run anywhere" philosophy colliding with different OS GUIs.

The other problem is that Java's startup time is ridiculous. Load the VM, load the code, load the libraries (*lots* of libraries!), verify the libraries and the code, initialize the libraries (lots of .properties files!) and the code, and then run.

Once the startup hooplah is over, Java code is quite reasonably fast. Benchmarks either minimize the startup time by, say, running 10,000 iterations of a loop, or eliminating it entirely by using "flying start" techniques.

Everyone know that if that war ever happened there would be a worldwide nuclear holocaust.

Nope. Worldwide economic collapse, yes. Nuclear war, no.

Those who stay behind get automatic nominations for a Darwin Award.

... Outsource support and system management to Mumbai. What could possibly go wrong?

The first linked article above is gibberish. The second one is a minor rewrite of the first. The website of LaserPowerSystems (ahem!) does not inspire confidence.

Trying to squeeze some sense out of the article, I'd guess that they claim that, by using a laser to heat up a hunk of metallic thorium, they can get it dense enough to fission by itself. Perhaps the laser is related to a neutron generator? I'd also guess that "250MW" is a typo for "250KW".

Or maybe it's just a bunch of buzzwords strung together in hopes of attracting some scientifically illiterate venture capital.

How about a shooter where, when your character dies, it reformats your hard disk?

The problem is not with the C language. NULL terminated strings are just fine for printing status messages and suchlike, which is all they were intended for. The problem is using C to write text-bashing programs. In C, you have to spend a lot of time and effort checking string lengths, allocating and deallocating buffers, worrying about character sets and funny characters ("magic cookies", anyone?), dealing with byte order, and all sorts of other cruft that should be handled by the compiler.

IMHO, the first really useful language that was designed for text bashing was PERL, or perhaps Microsoft BASIC (I've used SED and AWK. Bleagh. I've not used SNOBOL so I can't say anything about it.)

I hit some random website (I don't remember which one) and suddenly my CPU usage pegged and the Java console popped up. The output on the console implied that a Java applet was mining bitcoins. Of course, I killed the browser process immediately.

A few years ago, I designed a Java "CPU leech" applet that would do things like this. Wasn't particularly difficult. I never actually built it; somebody else obviously did.

I wonder how many of these things are out there that are smart enough to throttle their CPU usage.

John Varley clones must die!

The Government has already outsourced its computer security to Microsoft.