A personal corollary for code related to this theme is to always try to make the code I write as "boring" as possible. I've found that programmers often get themselves in trouble by trying to be "clever", which often makes for horribly unintuitive or unnecessarily complex systems. I've heard people asking about how to perform crazy language tricks and I nearly always think to myself "My God, why in the hell would you even *think* about doing something like that?" Such things nearly always point to very fundamental flaws elsewhere.

In the US, railroad engineers are required to be state certified and re-certified every two to three years. How about civil engineers? Oh yeah, them too. Mechanical engineers? To become a Professional Engineer in the US, state certification is required. As for electrical engineers, I don't think they have any state licensing requirements, but for all practical purposes, a four-year degree (a state-certified document as well) is typically required for employment.

This shouldn't be surprising to you. Any profession that could adversely affect the safety or lives of the public if mistakes are made often requires state certification. For the most part, this doesn't affect EE or CS. No one dies if MS Word crashes or your microwave stops working. And in those exceptions when that's NOT the case, certification is typically required of the products themselves (cars, airplanes, medical equipment) instead of the people who worked on them.

I tend to use "programmer" or "computer programmer" for myself, because I think it's the most accurate description.

Most professions with "engineer" in the title require state certification and licensing to practice their trade. I figure that's a reasonable benchmark for whether someone should put "engineer" in their title. Some engineers get in a snit about this, and I can sort of see their point.

I generally view "developer" as anyone who works on the software product in any capacity, although "software developer" still would likely refer to a programmer. For many products, there may be little distinction between "programmers" and "developers" simply because all the developers happen to be programmers. I happen to work in video games, where there are typically many more non-programmers than programmers working on a given project. As such, the distinction becomes more important. It's fairly common in the video game industry (and the public at large) to refer to everyone involved as developers, or "devs".

My first thought was poor nutrition as well. It's the same sort of claim that dentists make, like how unhealthy teeth can lead to other health problems. I've always figured it's more likely that people who don't take care of their teeth also don't take care of their bodies in general.

About your proposed food stamp rules... you're missing the "grains" food group (bread, flour, rice, etc) entirely, not to mention a few other fundamental things like eggs, butter, salt, and sugar. I'm going to take a wild guess that you don't do the bulk of the shopping and cooking for your household.

You can read the rationale as to why the US government currently does not restrict any "food" item, no matter it's health value. Personally, I think it's more worthwhile to focus on working to get people off food stamps altogether than trying to add a bunch of regulatory burdens to the program. If you want to focus on abuse, let's look at more rampant fraudulent welfare claims to start with. Buying a candy bar instead of an apple is a terrible health choice, but I'd hardly count it as "abuse".

They surely never have to bother with this on their own. It's handled all by their underlings, of course. I suppose one way to explain it would be that it might cause some minor political embarrassment if it were revealed the head of state / elected leader didn't have a passport, and therefore, technically speaking, was actually breaking the law when traveling abroad. They don't really *need* it, of course, but bureaucracies, if nothing else, tend to mind their p's and q's. The sender undoubtedly intended to send that information to another civil servant for properly processing it in some mundane fashion, as they tend to do. I'm betting 1000 to 1 that it was for no interesting or glamorous reason other than fulfilling a bureaucratic rule or an information filing law.

And so naturally he gets modded "Flamebait"

Heck, I'm going to go our on a limb and predict that we'll see at least seven or eight billion people die within the next century.

If you get overrun by a glacier, I'm not sure how much sympathy I'd have for you.

Oh, don't misunderstand... I'm betting that what was patented is actually not all that complex in principle. And naturally, being patents, they're written as broadly and confusingly as possible. That doesn't mean the software as a whole is not extremely sophisticated. Try reading an open source video or audio codec and you'll see how complex it really is in practice.

A locked and reinforced cockpit door prevented hijackers from gaining entry to a Chinese flight a few years back. Members of the crew and some off-duty policemen among the passengers fought back and subdued the entire group of hijackers - even killing two of them in the struggle. There have apparently been other hijackings in which the criminals never gained entry to the cockpit either, instead holding either passengers or the plane itself hostage with weapons or bombs respectively.

Locked doors may also have deterred other hijackings in recent years, along with the realization that passengers seem far more likely to react by attacking and subduing the hijackers on their own, though of course you really can't know for sure one way or another. It seems as though 9/11 permanently altered the "rules" of airline hijackings when it was realized that airliners could be turned into extremely deadly guided missiles powerful enough to take down the largest structures. At that point, instead of dealing with hundreds of dead, you could be looking at many thousands of dead.

It's true a pilot could conceivably do the same thing in the future, and I'm not sure there's ever really a way to prevent that from happening. The copilot could just have easily have switched to manual control and pushed the nose of the plane straight into the ground just prior to landing, and there would be no way for the pilot to react in time since this would only take a few seconds. As such, I think the locked and reinforced door still seems like the safest option. As horrible as this event was, it remains an even rarer occurrence than hijackings, even though we've seemed to have a recent uptick.

Everything they say is already recorded. Recording audio is arguably much more privacy-invasive than video, so I fail to see how video would be some dramatic chilling effect like you suggest. Yes, all the plane settings are recorded by the black box, but video could give another insight as to *why* the pilots reacted the way they did. If it increases flight safety in the wake of an accident, I think that deserves consideration. I don't want to necessarily alienate the pilots, but I'd like to hear the professionals on both sides talk about the pros and cons of this. In the wake of questionable pilot actions in recent years, I think it's not unreasonable to re-consider this.

I'd also support a law stating ensuring that the audio and video can't be accessed by the airline unless there is an incident involving serious damage or the loss of the plane in order to protect the privacy of the pilots and crew.

Never let bothersome facts or evidence get in the way of a good conspiracy theory. After all, if you dig down a few layers of turtles, you can convince yourself that any of these "facts" are simply manufactured, and therefore are evidence of the conspiracy themselves.

Occam's Razor be damned. It's much more entertaining to think up wildly implausible theories to explain how the pilot could somehow be locked out of the cockpit and the plane be instructed to descent carefully and controlled straight into a mountain range. Although, come to think of it, I still haven't heard anyone come up with even a remotely plausible explanation as to how this could possibly happen other than the official version of the story.

Are you crazy enough to trust your life to a wetware computer we can't even understand with any real confidence? There are 100,000 miles of blood vessels in your body, and if just the wrong one clots up, it's over for you. Many important components have no redundancy. Fatal malfunctions regularly occur with no way to repair them. Worst of all, you don't even have an offsite backup system for your most critical data.

That's basically what your body is. If you're dumb enough to rely on an organic life-support system designed through random trial and error, you deserve to die in a messy pile of organic failure.

California is a nutjob of a state, but I have to say, I don't really see a problem with them outlawing flamethrowers. I mean, vast portions of the state are hot, dry, and pretty much a tinderbox waiting to be ignited. What could possibly go wrong?

Of course, they probably weren't considering this aspect when they outlawed them. They were thinking "ZOMG! Flamethrowers?!? We're going to see DRIVE-BY-FLAMINGS if we don't outlaw these things!" I'd guess it was just a happy coincidence that they banned something that's probably better off banned for more pragmatic reasons.

To answer your question: Yes. Whatever you think of patents (personally I despise software patents and think they're a cancer on our industry), these are not single algorithms, nor are they in any way simple. This is very sophisticated software. At least scan through the Wikipedia entry linked in the summary to get a rough idea of the complexity of these monsters.

Modern video formats are comprised of a vast collection of different algorithms and techniques, and part of the encoding process is determining how best to apply those various techniques to create the best compression while maintaining a specific desired perceptual quality. It's perhaps best to think of a video codec as a family of many different video encoding, decoding, and storage techniques.