Check out the huge regex at the bottom of the RFC 5322 compliant validator from CPAN:

Honestly, this sort of thing is an example of overusing regex when it's the only parsing tool they know. Regex becomes unwieldy when you put too much of it in one place -- but this is because regex is unwieldy, not because the problem of parsing email addresses is fundamentally hard. Parsing email addresses is a case for a modular parser such as Parsec (or any of its ports and imitators) ... which will give you the added advantage of useful error messages on invalid input, instead of just a match failure.

Moreover, isn't it kind of silly to point at an example of someone already having written the code to do something as a way of saying that doing it is difficult? In code, once it's already been done once, correctly, it doesn't need to be done again. If you think CPAN's huge regex (or any other implementation) is correct, and you've tested it to your satisfaction, you don't need to reimplement it; just use it.

For folks who want to record the cops (or anyone else) and be sure that the footage will get to the world instead of being destroyed when they steal your camera phone: check out the Gandhicam project. This is an app for your Android phone that lets you take pictures or video and automatically send it to the net, either by HTTP upload or by email.

This doesn't stop them from filing criminal charges afterward, but that's why you donate to the ACLU and the EFF.

Really, the only way that SCO was going to recover was with a court victory, and while the probability of that wasn't 0, it was as damn near to it as possible for practical applications.

There are people who believe things out of spite. Remember when the SCO case got started? There were plenty of folks -- chiefly in the "open-source haters" end of the trade press, but I met a few in industry, too -- who dearly wanted to see the "upstart" Linux smacked down hard.

It may be hard to believe it now that Linux is everywhere in the industry -- from the datacenter to the cell phone, from the Oracle database server to the displays on the backs of airplane seats -- but just a few years ago, plenty of people would have called you an "open-source zealot" if you said that it was worth using anywhere at all in business. And lots of traditional business people really wanted to see Linux dry up and blow away. Plenty of those people would have put hope, and a few bucks, behind the SCO suit.

Having studied eight foreign languages (French, Spanish, German, Latin, Ancient Greek, Russian, Japanese, and Finnish) in my life, and after talking this theory over with friends who have attained fluency in some really different languages (e.g. Spanish and Bahasa Melayu), I feel safe in stating this here in pretty strong terms:

The only way to learn a language is to use it.

The only sort of "classroom" language class that works worth a damn is an immersion class, in which during the class period you do not speak any language other than the one you're studying. Even classroom instructions ("Open your book to page 23") are in the language, once you've learned numerals.

The worst language classes I've taken have been ones in which the foreign language being studied is treated as a matter of abstract grammar and vocabulary to be memorized, not used ... and in which the teacher spends most of their time telling anecdotes in English about their experiences in the culture in question. I took two years of Russian in high school and a year of it in college -- and forgot more Russian than I learned in that last year, since the teacher spent the class time telling stories (in English!) about run-ins with the KGB, instead of helping us practice speaking and reading Russian.

As regards Chinese: I've never studied Chinese, but I have studied Japanese including kanji, albeit only to the extent of a couple hundred kanji. The above applies fully to kanji, and I expect it applies to hanzi (Chinese characters) as well -- in order to learn them, you have to use them. Write them. Come up with silly sentences and write those. Don't just use flash cards and memorization; come up with things that you want to say in Chinese (even if just to be silly) and say those things with hanzi.

The other half of the equation, of course, is to get someone who is fluent to respond to your crude childish attempts at speaking and writing. That's the point of a good language class: you get to make the sort of errors that a little kid makes, and they correct you. That method of language acquisition works for little kids, and it works for adults too if they're willing to be childish for a while.

Unfortunately there are a few cases you can't do that. No way to use a prepared statement for an "IN" clause, for instance.

You could always use the technique the DBMS gives you for encapsulating complex query logic and passing parameters into it ...

... stored procedures!

Cue screams of terror; cue fist-waving and incoherent irate noises. These will be heard from people who never cared to actually learn how their DBMS works, or who think of the DBMS as some foreign thing that their application throws data at once in a while.

(Your application does not use a DBMS. Rather, a DBMS is one of your application's components. If your app contains a DBMS but you don't know what it's doing, you are in the same camp as "programmers" who do not know how their language's object model works, or who are a little rusty on whether a loop with a false loop condition executes zero times or once. That is: you are not a programmer; you are a burger-flipper who sometimes farts out bad code.)

Stored procedures are not the chapter of your DBMS manual that was put in there to pad it out so it qualified for the better binding at the publisher. Nor were they put in there just to entertain your DBA. Stored procedures let you simplify the interface between your DBMS and the rest of your application, and this can radically improve your overall security.

After Google's CEO's comments about privacy is only wanted by wrongdoers

Except, of course, that he never said that. He was asked in an interview whether users should consider Google as a "trusted friend" -- and he said no. He said that if you're doing something that you don't want anyone to know about, doing it on Google is a bad idea ... since Google is just as subject to U.S. law, including the USA PATRIOT Act, as any other company is.

He didn't say that only wrongdoers want privacy and that everyone should trust Google. He said that if you want perfect privacy, you can't get it from Google, because the law doesn't allow it. That's pretty much the opposite!

People spend a lot of effort blathering about which programming language is best to use for teaching. But the hard part of programming is not the programming language. It's the logical thinking skills; the abstract concepts like function and algorithm and data structure and type; the reasoned approach to breaking a problem down and seeing algorithms and patterns; the ability to learn new tools such as a utility or an API and put them together usefully.

These things transcend language. Yes, you will probably use different algorithms or data structures in Python on a Linux box than in C on a microcontroller, but you will use largely the same sort of thinking skills. You will approach writing code differently in Lisp than in Java, but in both you will be combining known parts in a new structure to accomplish a task.

And it is these abstract skills -- especially the skill of abstracting, of recognizing and using patterns -- which separate those who learn to program well from those who do not. (And this is different again from being a successful professional programmer, which entails a quite different set of skills.)

A monad is not a specific data structure (like an array) or a language feature (like a loop or conditional). It is not something that is put together by the compiler (like a compiled function) and it is not magic, either.

"Being a monad" is a mathematical property, like "being commutative" or "being symmetric". It has to do with values following a particular pattern, having operations defined on them that interact in a particular way. (These are called "monad laws", and they're the same sort of thing as the "identities" you get in high school algebra.)

Any sort of thing that follows the monad laws is a monad. In Haskell, we say that any type that follows the monad laws can be made a member of typeclass Monad. Casually, we say that "lists are a monad" and "IO actions are a monad".

What does it mean to be a monad? Roughly, it means that you can chain operations together. You can map a function over a list, or filter the list's elements to get a new list, or more generally "fold" a list by recursively applying an operation to collect a result. (Like the factorial function repeatedly applies multiplication.) Also you can join a list of lists together into a single big list.

It turns out that monads can represent the idea of "sequence" quite well. Lists are, after all, a sort of sequence. But so are IO actions -- all those "non-functional" things a program has to do, like read a file from disk, or write its contents to the terminal. IO actions form a sequence in time: if you want to write the file's contents to the terminal, you have to read them from the disk first.

The way that this works, under the hood, is to express the "later" actions as having the "earlier" actions' results as function arguments. Since a function's arguments have to be evaluated before the function can be applied, the disk gets read before the terminal-writing happens.

So monads are not a loophole that lets you cheat and do non-functional things inside a functional language. Rather, they are a model that lets you describe IO actions as just another sort of functional value. The only bit of "magic" necessary is that the main function of a program has the IO type.

most adults do not really believe the tenets of any major religion anyway.

Of course not. The question is, do most adults believe some of the tenets?

That depends profoundly on what you mean. Most religious people, most of the time, do not permit their religion to get in the way of their common sense or their common decency. When questioned on a point of religious belief, they will reliably respond according to their understanding of doctrine ... but with equal or greater reliability, when presented with a practical challenge in life, they will respond based on an ordinary secular understanding of how the world works.

An example: Martyrdom. We know from the lives of the saints, and from the acts of certain modern-day counterparts, that there are those who put their faith in God ahead of their self-preservation, placing themselves in harm's way in the service of faith. We know, also, that only a tiny minority of religionists do this ... even among those who claim to revere the saints and martyrs who do, and who when questioned on the matter state clearly their belief in heaven. In gist, people who claim belief in life-after-death act just as fervently to avoid death as those who do not claim that belief.

This is what people mean when they question whether religionists really do believe what they say they do. Most of the time, when we say "belief", we mean something that we are willing to rely upon: if you believe it is cold, you do not wear shorts; if you believe that Jane does not love you, you do not propose marriage to her. Your belief is detectable in your actions which rely upon it, which are explained by it.

Dennett presents the notion of "believing in belief" -- the idea that many people think that religious belief is a good thing, a thing to be desired, indeed one which you should pretend to, or "fake it until you make it". People who believe in belief can be expected to say they believe religious claims, but not to actually rely on them. This seems to be a cogent explanation of the way that most "religious" people actually deal with the real world.

I think they would have to define a man as someone that is XY and a woman as someone that is XX, anything else doesn't qualify or gets removed based on medical grounds.

Go read about androgen insensitivity syndrome. A person with complete androgen insensitivity has the external appearance (including external genitals) of a normal female, and usually has been raised with a female identity, and so identifies as a girl or woman. But she has no menstrual period because she has no ovaries or uterus -- she has an XY genotype and undescended internal testes. Androgens (male hormones) create the male external appearance; in the absence of androgens, a fetus develops a female appearance -- and parents and society assign a female identity.

It seems to me that a reasonable approach to dealing fairly with intersexed people in sports would be to replace sex separation with weight-class separation. Human sex and gender turn out to be complex and fraught with both social and technical problems, and it is unreasonable to deny an athlete the chance to compete just because their genetic curiosity happens to be on the 23rd chromosome.

I've known folks whose workplaces used to pay Sun a license fee for Perl ... the same Perl you could download for free (as in beer); and yes, the same Perl that is one of the usual examples of successful free (as in speech) software.

No, they didn't get tech support. They didn't get to file bugs against Perl that would be resolved by a Sun engineer. They didn't even get a custom build of Perl optimized for their Sun hardware. They didn't even get a CD. What they got was an invoice ... precisely what their company's IT procurement process required.

It's idiotic, but there is in fact a market for nothing: if you are correctly positioned as a trusted supplier, there are cases when you can get paid for delivering no product at all, but merely for carrying out the ritual of delivering a product, with all the paperwork thereunto appertaining.

1. Freedom of speech and of the press; freedom of religion and assembly; freedom to speak your mind without fear of governmental violence of any sort. Can't say it too many times: expression is sacrosanct.
2. Right to keep, control, and protect one's own property. The rights of physical property owners to control devices in their ownership reaffirmed over and against claims by "intellectual property" owners. You don't get to scramble my hard drive just because you think maybe I'm a pirate.
3. Domestic espionage upon political rivals by government agencies, or other use of law enforcement powers for political gain, declared to be a "high crime" removing the perpetrator's right to run for office or occupy any government position.
4. Protection from unnecessarily destructive or disruptive searches and seizures. Disallow seizure of property when access to information is sufficient for law enforcement purposes: if you need a copy of a public Web site, you take it with "wget" from a secured and audited computer certified to be part of the evidence chain, not by seizing all the owner's computers, stereo, and video game systems too.
5. Right against self-incrimination extended to passwords, crypto keys.
6. Right to technically competent counsel in criminal cases where the details of technology are directly pertinent to the case.