Am I the only one who read this initially thinking that "supercharger" meant a pump that forces compressed air into an internal combustion engine?

Not my choice, we got them in a deal with a VC. And I will tell you from experience that they're not all great programmers. A *few* of them were very good programmers, most of them were OK, and a few were very *bad* programmers. Just like everyone else. The idea that the H1B program just brings in technical giants is pure fantasy. This isn't 1980; if a CS genius living in Bangalore wants to work he doesn't have to come to the US anymore, there are good opportunities for him at home..

H1B brings in a cross section of inexperienced programmers and kicks them out of the country once they've gained some experience. I have nothing against bringing more foreign talent into the US, but it should be with an eye to encouraging permanent residency. I think if you sponsor an H1B and he goes home, you should have to wait a couple years before you replace him. Then companies will be pickier about who they bring over.

I have to say, managing a team of H1Bs was very rewarding, not necessarily from a technical standpoint but from a cultural standpoint. Because I had to learn about each programmer on my team and the way things are done in his culture, I think I became closer to a lot of them than I would have to a team of Americans.

I feel here are positives and negatives to being older.

The positive is a depth of experience. An inherent patience to work through problems, looking for the right answer. My boss can - and does - tell me "Laura, figure out XYZ and see if we can use it in our company." This will keep me busy for extended periods.

While it's not strictly age-related, I find many "younger" companies have views on work/life balance that are incompatible with my own. I do not eat, live and breathe my work. When I go on vacation I go, and make damned sure I'm out of cellphone coverage when I do.

Also, many "younger" companies have messages I do not believe in. A prime example is local media darlings HootSuite. Since I don't buy the problem, I can't be part of its "solution".

...laura

That needs a big 'citation needed' next to it, but:

You don't understand risk analysis. He's investing a very small proportion of his wealth in something that may have massive returns. The probability of said returns may be small, but that doesn't make it a bad investment if the potential payoffs are huge, as long as you can afford to take the loss if it doesn't pan out. Most people with his money will invest a few millions in a few fringe ideas, because it only takes one to pay off to more than make up for your investment. The majority of his portfolio will be in relatively safe investments with a close-to-guaranteed return, a bit will be in risky venture.

You missed decay, which is the most common form of nuclear reaction on Earth. Proton capture can technically be thought of as fusion (fusing a hydrogen nucleus with something heavier), but it generally isn't referred to as such. Neutron capture is not fusion and a lot of LENR reactions are neutron capture.

Insertion sort is terrible for the use cases the grandparent described. For one thing, it requires allocating a new data structure for storing the data (an immediate disqualification for a lot of embedded tasks). Second, it has much worse cache interaction because it requires searching the second array. Assuming that your target is an array, then it also requires a bit memcpy for each insert, which means that it likely requires a similar number of memory operations to the bubblesort, but with more temporaries. You can do a bubblesort in-place, with good cache locality, and only a handful of registers (insert base, top, current, and two for holding the current elements). If your CPU has 8 GPRs then the space requirements of a bubblesort are effectively zero - no memory required.

That's only if you don't have the requirement to sort in place. Bubblesort is also a good way of getting students to start thinking in terms of induction. Each step in the bubblesort leaves the array more sorted than it was before.

Insertion sort is one of these good-on-paper algorithms. It's very fast if insertion is cheap. But insertion relies copying unless your data structure is a linked list. If it's an array (worse, a contiguous on-disk store) then that copying can be very expensive. If it is a linked list, then you're going to have very expensive search (sure, you may still be O(log(n)), but that constant multiple is going to be hurt by the fact that you're hammering your cache and killing your branch predictor).

Teaching algorithms separately from data structures is one of the biggest flaws in modern computer science education. It's impossible to reason sensibly about one without the other.

Bubblesort has two advantages. The first is that, because it's only swapping adjacent elements, it has very good locality of reference (which means better cache usage, but can also mean more amenable to fine-grained locking). The second is that it performs well on almost-sorted data (that O(n^2) is the worst case - it's closer to O(n) if your inputs are mostly sorted). These two mean that there are situations where bubblesort can be useful, though they're quite rare.

What is that measuring? The fact that it doesn't say means that it's meaningless, but it looks like they're comparing number of ships, so a coastal patrol boat counts the same as an aircraft carrier...

A statistic that floated around earlier in the year when Argentina was grumbling about the Falklands again: one of the battleships that the British were sending to the area could fire, in one minute, more munitions than were fired in the entire 1982 conflict. I'd imagine that the differences between 1945 and now are even more pronounced.

One constant trend has been that soldiers are less expendable. In the first world war, sending men to walk slowly towards machine guns and throw a grenade if they survived to get close enough was their patriotic duty. By Vietnam, having large numbers of soldiers come back in body bags was politically unacceptable.

In the 1940s, Japan was flying aircraft loaded with bombs into American warships. A few years later, people realised that you could design aircraft for this purpose and make them a lot lighter and able to accelerate more if you removed the human pilot. They called them anti-ship missiles.

The fighter screen that fleets needed to protect themselves from aircraft in the '40s is now replaced by anti-aircraft and interceptor missiles (and dumb projectiles). In the next generation of ships a lot of this will be replaced by lasers, which reduces some of the resupply need (you can't run out of laser ammunition on a nuclear carrier unless your ship is so badly damaged that it's not a good idea to be anywhere near it).

Gradually, a lot of the roles for aircraft are being replaced by drones, which means that you need smaller carriers. They don't need to house as many pilots, they don't need as many support staff.

Another part of this trend is to replace reusable vehicles with single-use munitions. Fighters are more expensive than missiles, so you spend a lot on maintaining them. Drones are a lot cheaper, so you can afford to fly them for a couple of missions and then scrap them (explosively, near someone you don't like).

Comparing numbers, as the grandparent did, is completely meaningless. You may as well compare the size of the air force to the number of soldiers Napoleon had.

There are basically only three decoders that cover most of the market: Microsoft's DirectShow filter, libavcodec / libavformat, and QuickTime. Hardware decode doesn't help much, because you still have the same software path as everyone else doing the de-encapsulation and file parsing, which is where the exploitable bugs often show up. If you have vulnerabilities in each of these then it's not generally hard to hide them all in the same file, as the codecs aim to be resilient to corrupted data so will usually just drop a frame or two for the exploits aimed at the other implementations.

Oh, and libavcodec / libavformat are used in Android (and in a lot of iOS apps, as AVFoundation doesn't always expose useful APIs), as well as in desktop browsers, so they're a pretty good target to aim for.

How does that prevent Facebook from building a profile of you? The only way to avoid that is block all Facebook like buttons, never visit the Facebook site, and make sure that your account has no friends.

People who think a fake name on Facebook protects them from any of the privacy invasion really haven't been paying attention to the last decade of data mining. The reason Facebook no longer cares if you register with a fake name is that they've been able, with very high accuracy, to get your real name and address without your providing it for a few years.

As with all legislation, just like contracts, you never know how, good or bad or how they will exactly be interpreted, until they are tested in court. The fun thing about trying to sue them of course is what you are entitled to do under the discovery process. The corporations have no qualms about suing government and try all sorts of things on all of the time. It is about time the electorate did exactly the same thing, form temporary political activism groups and class action sue corporations and the government for all sorts of things. Pretty cheap to try on and by spreading out the cost and using as much volunteer labour as possible, likely reasonable cheap in the long run compared to what they will have to spend.