Is this supposed to get me to buy through gamestop? Is this their effort to claw at a dwindling physical-medium retail space?

No amount of douche-baggery will cause me to give up my preferred method of spending money. If I want the release-night environment and other anonymous gamers to talk to while waiting for my copy, then gamestop it is. If I want to forego putting on pants, I'll go with a digital distributor, and no amount of virtual clothing tweaks or outlet-specific items can make me put on my pants!

They're looking for potential hires. What better pool to pull from than technical terrorists?

When you get into the statistics, numpy, and scipy, it's all just python bindings for native fortran/C code--so it tends to be about the best there is in terms of execution time.

Every web framework and technology has benefits and drawbacks. It's a matter of finding the right fit for your company. It's a good thing they're letting you ask the question, because managers/bean-counters make bad decisions in this area claiming that devs can't "see the big picture." Find one that fits well with your system and needs.

But, I assume that's why you're asking slashdot--you don't know what's out there or what their benefits are.

Well, I've spent the past 7 years benchmarking web frameworks and systems and I'll share a bit of what I've found out. Keep in mind, all information given here is my opinion and subject to debate and correction.

First--if you need near-infinite scalability and the absolute best performance, there is nothing that can beat mongodb for a database backend with fastcgi++ for your "framework." Mongodb is a bit buzzy still, but there are good reasons for that. It scales extremely well, and was designed to scale at speed. Fastcgi is anything but buzzy, but it's the fastest there is and it's built right into most webservers--but you're writing C/C++ code so that's an odd beast to deal with.

Now that I've said something that management will undoubtedly shoot down, here are some other frameworks and what they were originally designed to do, and some highlighted features.

Python - Django : "perfectionists with deadlines." Django was designed to chug out simple, straightforward web applications as quickly and cleanly as possible inside of your overall project. Contains template inheritance that has a small learning curve and is very powerful. Uses any SQL backend you want and provides an abstraction layer for it with caching. Cons: can be pretty heavy for a webapp, and difficult to integrate into a production environment.

Python - Flask : Simple and lightweight. Uses the same templates as django, but no database backend. It's meant to be standalone and simple (5 lines of code will get a website up). It's easy for your code to grow unwieldy inside of flask.

Ruby - Rails : Continuous development and test-first environment. This is kinda the poster boy for buzzwords, in my opinion, but it has some strength beneath it. Ruby is largely on-par with perl, so you have that. Rails provides the data modeling and really streamlines a lot of the annoyances common to web development. They designed the system to be the whole "45 minutes to a production environment" pipeline. You're supposed to write your tests first, then your code, and you write your deploy scripts and settings before you even start your project.

PHP - Drupal : Make a website without knowing crap about making a website. Haven't used it personally, someone else can comment.

PHP5 : "Hey, let's fix all the problems with PHP4!" Seriously, though. PHP was meant to add one-off server side scripts inside of your html, and has grown to be so big in comparison. PHP5 is actually a good language though, but it took a while to get it there. It's best used for image data processing, in my humble opinion, but it's on-par with any other language out there.
So, search them, find out who is using which systems, and which ones seem the most similar to your setup and go from there.

You mean there are venture capitalists who can't do basic risk assessment?

That's how these miner manufacturers operate. It is relatively low and well-understood risk to sell physical goods. We have X orders, and can produce Y units each month. The reason they don't mine bitcoins themselves is that they don't want to take that risk. They sell the machine, and they get their money. They sell more machines, they get more money. It's simple, it's safe.

For the people who purchase them, they are assuming the risks of mining. They take the risk that their machine will underperform, that their miners won't find any blocks, and that the value of the bitcoin will stay stable or increase. The people actually mining have much higher risk than the people just selling the equipment.