No, because Infosys uses the H-1B's not just to replace American workers, but to facilitate offshoring. The H-1B's already know how the company works in India, fewer problems from language and cultural differences, etc. Most importantly, the Infosys H-1B's know that if they do a good job on their tour of duty here, they'll be rewarded when they return to India. The Indian Commerce Minister has publicly called the H-1B the "outsourcing visa".

Good thing you don't generalize. Would you prefer Irish H-1B's to Indian ones? It makes no difference to me.

They can start with the CEO's, who are the most globally uncompetitive. Typical American CEO of a large company makes about 400x the average compensation of employees. In the UK it's 45x, and in the rest of the developed world is 10x-20x. Forget about India - just go to Canada and get a CEO for about 5% the cost of a US one. Similar culture, short travel, little time zone difference ... what's not to like?

Not the OP here, but the main thing I dislike about git is the UI. The internals may be good, but the UI is a hack, complete with counter-intuitive alternate uses of commands via switches that seem like they should be used elsewhere, etc., etc., etc. Contrast that with Mercurial, which has a much more logical and consistent UI, and UI's are important (command line or of that other trendy variety). People who think the git UI is fine are probably just used to it. If you can get used to the spelling of my mother tongue, English, then you can get used to anything. That doesn't mean it was the best choice though.

As for features and capabilities, it seems to be neck and neck, which of course leads to endless debates about pros and cons. It's interesting that before git was quite so popular, people that actually sat down and compared the two, like FogCreek and Google Code, generally chose Hg. I suspect the main reason that git initially won the popularity contest is that Linus wrote it. Nowadays the choice is a bit different because using anything other than git is trying to swim against the tide, but the initial reason for its success over Hg bugs me.

In your inability to to distinguish between simplistic reasoning and the real world. You're free to accept the wage or not, just as you're free to become destitute. So many choices in a "free" market. Bonus points if you can tell me who has the greater bargaining power in a situation with 10 buyers and 10,000 sellers.

Guess which party gets the largest donations from the tech industry.

Big deal. Just use a white list instead of a black list.

That's the point.

And if it were actually used for this purpose you could simply download a list of plates whose registrations have expired or been revoked into each scanner, and have the scanner report it when it saw one of those plates. In other words the LAPD's monitoring goes way beyond what is necessary to enforce the law, which is (or used to be) strongly frowned on by the courts.

Where did I say it did? I simply pointed out that "CME will fry your car" is a myth. CME will fry the electric grid is not a myth, and that's a monster of a problem. Many of the things you mention follow from that.

You could point out that dynamic typing was introduced one year after static typing. Dynamic typing is state-of-the-art, circa 1958.

Don't be absurd. Type problems don't show up during testing - they show up 3 weeks after the code has been released, and then only in situations that are practically impossible to reproduce. That makes debugging more interesting. Any idiot can find type problems when the compiler does it for you.

So do you rely on implicit or automagical type conversions? That doesn't do much for error checking. No, I don't do web programming, but I've worked on code that had to do a lot of string to whatever conversions. The biggest pain, but one of the most important things, is detecting errors in the string format. You need an explicit function to do that right, and a way to handle the errors. Once you have the explicit function, what's so hard about declaring that it returns an object of class ObiWan?

Much worse than writing dynamically typed code is reading it. If I write function foo in a dynamically typed language, I know it's supposed to return an integer. If I'm reading somebody else's code, I often winding up guessing that an integer makes sense. Of course it may return a float or a string on odd Tuesdays when the moon is full. Much nicer for it to explicitly say it returns an integer, and have the compiler check that that's the truth.

I haven't tried SQL, but in general Haskell's libraries are one of its weaknesses.

I don't agree. A closure should produce a new pure function (some languages allow otherwise, but not Haskell). With functions as first class objects, you can just pass and return them like data. There is nothing about that that suggests the evils of globals.

If you spend half, or any appreciable part of your programming time dealing with static typing issues, then you're doing something seriously wrong. Occasionally the compiler will be a pain in the ass about it, but most of the time static typing should require nary a thought. If it's otherwise, you're not thinking about types clearly. The static typing is there to catch you when you screw up. It also serves as useful documentation for the next poor schmuck that has to look at your code, and for good measure the compiler enforces the accuracy of this type of "documentation". If you're really too lazy to type "int" or "double", try a language with type inference.