Largely because of the first-sale doctrine, which codifies property rights sanity: if you sell me something, it is now mine, not yours. I can do whatever I want with it. Use my spatula as a screwdriver? Use a thermos bottle for a hammer? Watch scenes in a movie out of order? It's none of your business. I bought it. It is now my property, and I'm free to do with it as I please.

(Averting pedantry: of course that doesn't involve violating copyright. Straw men will be ignored.)

Better idea is to voluntarily test yourself on a regular (monthly?) basis. I know doctors who do this so that in the event of a lawsuit they can prove that they were not chemically impaired. If anyone questions them then they can produce a multi-year stack of clean drug tests.

Often there is very little or very illogical differences. In many places a teenager voluntarily sending a picture of themselves without clothing to someone else counts as a felony (considered child porn) whereas an adult doing the exact same thing to the exact same person for the exact same reason would not be considered a crime at all in some cases. In fact the teenager in that case may get the privilege of registering as a sex offender for the rest of eternity even if the picture was just sent to a boyfriend/girlfriend. It's absurd but it happens. The line between felony and misdemeanor is an often arbitrary and capricious one and not all felonies are particularly serious crimes.

That's an awfully broad brush you have there. I have an alcoholic who works for me. Served time in prison because of it and lost his driver's license for over a decade. He's been sober for some years now but he'll always be an alcoholic. He's a good worker, nice guy and very reliable. He just had a problem with addiction. You could easily substitute alcohol for cocaine and the situation would identical. Just because someone has/had a problem with substance abuse does not mean they cannot ever be trusted again. They have to prove they can handle the responsibility but a blanket ban against people who have had a problem in the past is needlessly harsh. You have to address it on a case by case basis.

Sadly that problem will not be confined to IT. Even if you try to change careers a felony record is going to follow you and (right or wrong) there aren't a lot of employers who are going to be willing to take a chance on an ex-con. Companies just generally do not want to take on avoidable known risks and a felony makes a job candidate into an avoidable known risk.

Your best chance is probably through personal networking but it's going to be tough. The good news is that there are companies that will work with people with troubled pasts but finding them usually takes a lot of work. If your skill set is in IT and your convictions aren't for things related to IT then I see no particular reason to switch because the same problem will exist regardless of what type of job you seek.

Hell yeah, I'll admit that I am King of the Geeks. Talk nerdy to me.

OK, OK. I'll double-check with a calculator that's not "bc" before publishing. I've done enough physics work, though, to trust that 1) calculations showing explicit conversions are almost always correct, and 2) calculations that don't almost never are.

Like when Bell Labs developed C to write Unix? There's a long tradition of major companies coming up with new languages to scratch an itch. Thank God is hasn't died. How boring to live in a time when we'd decided that there was nothing left to innovate?

For nontrivial math, I don't always trust Google's interpretation of the question to be the same as mine. That page is a little short on details of what it's actually doing. On the other hand, WolframAlpha is really good about showing its work. I just always forget that it's there.

In either case, yeah, I like doing it the hard way. Or as I call it, "learning" or "practicing".

Moore's law describes the number of transistors in a package, not linearly their size. Doubling the number of transistors means that each one has to be 1/sqrt(2) as big as the old version, and that to-the-11th would be about 1/45th as large, not 1/2048th. That's still pretty dinky.

We think it's great because, among other things, it has first-class functions and a very high code:boilerplate ratio. This lets us write very concise, readable, and maintainable code.

Eww, no. I've never seen good Python code that asserts types because it's not the idiom for you to care. For instance, suppose you write a function like:

def get_contents_of(obj): return obj.read()

In this case, obj might be a file, or a web request, or a string (via the StringIO interface). Who knows? Who cares? As long as obj.read returns something, it works. BTW, this is supremely nice for unit testing when you don't really want to hit an SQL server 1,000 times in a tight loop.

Now, you could write something like assert isinstance(obj, file) to guarantee that you're only dealing with file objects. Of course, that lays waste to the whole concept of duck typing and people will laugh at you for doing it. So dropping that bad idea, you could write assert hasattr(obj, 'read') to ensure that the object has the needed methods. But why? Python gives you that check for free when you try to call the method. Let it do the heavy lifting and concentrate on the parts of the problem you actually care about.

Yeah, that would be terrible. You almost never use them in Python like that, partially because Python tends to have a vastly shallower call stack than, say, Java (largely because you don't need 10 layers of abstraction between bits of code thanks to the duck typing we just talked about).

I think it boils down to you not knowing idiomatic Python. That's OK. I'm ignorant about lots of things, too. But I think you'd find that you enjoy it more if you stop trying to write C or Java in Python, because that almost never works out well.

I agree, but remember that Python is interpreted in exactly the same way that Java is: both compile high level code to bytecode and run it on virtual machines. PyPy selectively uses LLVM to compile that bytecode into assembler for some enormous performance boosts, much as the Java JIT compiler does.

Whatevs. I co-built a web service on Python that handled 250,000 requests per second with a horizontally scaleable design. We could bump that up to 1,000,000 requests per second by deploying 4 times the servers (which isn't as easy as it sounds because most things don't scale out well like that). I left that company and went to another employer that handled "only" 80,000 requests per second, averaged over a month. If you can ditch the chattiness of HTTP, well, I've written single-threaded UDP servers in Python that could handle 200,000 requests per second per server. How fast do you want it to be?

Unless you're seeing extremely low numbers or your design requires vertical scaling because it was architected in 1965, choice of language isn't all that important. Ruby is slow, too, but Heroku manages to shovel the data pretty well.

I love Python because it maps very neatly onto how I model problems in my head. I'm not averse to using other languages, but Python is my comfort zone because Guido and I apparently think about algorithms in the same ways. As it turns out, I make a decent living with it.

So, do I have a good job because I know Python, or is it because the thought patterns of the people who are drawn to Python are the same ones that companies want to pay for, regardless of language? If the former and you want a good job, then by all means learn Python. But if knowing Python is just a side effect of the properties that employers are actually looking for, then it's probably not going to help you all that much.

It's not but I can see how it might seem that way. A lot of the physics is pretty out there and not all of it can be experimentally confirmed, at least not directly. The logical underpinnings and evidence used are fairly sound but there is a LOT we don't really know. There is a lot of "if A is true then B must be true" going on but sometimes we're not actually sure A is really true. It's not faith but much of it is very theoretical. Almost everything relating to stuff like black holes should be taken with a huge grain of sodium chloride.

Sometimes that is true and sometimes it isn't. There are plenty of measurements we are quite confident about. Others not so much. Unfortunately for the lay person it can be hard to tell the difference. Apparently sometimes it can be difficult for those in the field to tell the difference too sometimes.