Google has had my phone number for years. To my knowledge I've yet to receive a single call that originated from Google or someone to whom Google gave my phone number.

I'm all for identifying evil as evil, but it would be nice to have some actual evidence before making the accusation.

Given online prices and quality (if you know the right places to shop) combined with next day delivery in many areas, it's gotten to where you need to be REALLY desperate to pay Best Buy prices for interconnect parts. When they're charging literally 10 to 20 times what it costs to buy an equivalent item online, that instant gratification thing is really costing you.

Cables are to Best Buy as soda is to McDonald's.

And, actually, as Best Buy prices go, $57.63 for TWO SATA cables isn't that bad. A couple years ago I had an immediate need for a USB cable. They wanted $50 for ONE. I decided my need wasn't that great. Ordered ten online (to meet minimum order requirements) and got them for $12 plus shipping. I was tempted to take the other nine and hang out in front of Best Buy offering to sell them for "half price".

I think I have all of two OTA network shows on my regular viewing schedule. Everything else I watch is either from cable-only networks or the premium stations. For my money TNT, USA. FX, and A&E have far better programming than OTA. I honestly don't remember the last time I followed a show on ABC. And NBC has had only one show in the last several years I found interesting. I don't eschew OTA channels because they're OTA, I do it because their content is of little interest.

I will grant you that the picture quality over cable is pathetic. I wish they'd dump those fringe channels watched by just a small handful of people and give the bandwidth back to the rest of the channels.

There are taxes on the electricity produced from the gas and coal. With solar panels at least some of the power will be produced at the point of consumption with no utility company or governmental agency involved, hence no taxes.

It's similar in concept to the states that are realizing the shift to electric vehicles will hit them hard in the gas tax pocket so they're making moves to shift to a tax on the miles driven regardless of the power source of the vehicle.

To say they will tax sunshine is somewhat euphemism. They'll actually find a way to tax the electricity generated by the solar panels on your roof.

Just wait until solar energy really catches on and use of coal and natural gas drop off. Then the government, seeing their tax revenues for these energy sources drying up, will start taxing sunlight. So much for your free fuel.

Yes, there would be the same lack of market as exists for homes, large appliances, water heaters, carpeting, etc. Clearly there's a major scarcity of all these items.

It varies with the specific poker game, but I've read estimates that Texas Hold'em is about 60% skill, 40% luck. That's considered a nearly ideal split for skilled players. Any more tilt to the luck side and there's no percentage in it for the good player. Any more tilt to the skill side and unskilled players seldom win and don't find the game fun. Ideally, the unskilled players will donate most of the time, but will win just often enough to keep them interested. As they say, you can shear a sheep many times, you can only skin it once.

While all of Harrington's books are excellent, they aren't the best place for a real beginner to start. They assume the reader has pretty good knowledge of the game to begin with.

I'd start with Lee Jones' "Winning Low-Limit Hold'em" or something along those lines, then move on to Harrington once you're familiar with the basics of the game.

I don't really have a problem with Agile development techniques. I have a problem with people who preach about them with religious fervor, always trying to convince others that Agile is the one true development methodology and all others are pretenders.

It's my feeling that Agile techniques probably work well for certain situations and problems, but they don't always work in every situation. As you point out, Using Agile methodology when building a jet airplane is probably not the best way to go. Which is not to say some aspects of Agile couldn't be put to good use even with that scenario.

One thing has become clear to me from years of reading Slashdot -- there are many different development environments. Anyone who thinks the techniques used in their little corner of the development world will be universally applicable is sadly deluded. This was recently revisited in the article questioning why people are still using C. The answer is that for some problem sets C falls somewhere between adequate and best language for the job. For other problem sets C is far from the best choice.

The same applies with Agile. In some situations it works very well. In others, not so much.

Fast - If the plan changes halfway through Agile development, how does that NOT result in the same discarding of work and starting over? In my experience it's very uncommon for non-Agile projects to change so drastically halfway through that you have to scrap everything done so far. Has it happened? I'm sure it has. But I'm sure something similar has happened to Agile projects as well.

Cheap - Your conclusion is only valid if priority and value are directly related. Due to the various priorities of different departments, I've not found this to be at all the case. The marketing guys might think it's imperative and of the highest priority that the product use whatever the latest designer colors might be. Does this add value? Not in my book.

Good - I fail to see how short development time necessarily leads to "good". As far as I can see, all it does is lead to doing things in bite-sized pieces. I'm not saying that's a bad idea, but it's been my experience that on any project of real substance it can be very difficult to break everything up into chunks small enough to complete in a week (or even two). We've tried this several times at my company and have always failed. Even with a two-week cycle it was very difficult to break things up into sufficiently small pieces.

I would also suggest that non-Agile development in no way insists on you juggling 60 features at once and not submitting any of them until they're all complete.

You obviously like the Agile approach, and that's great, but some realism in the implied criticism of other approaches would also be a good thing. The non-Agile developers aren't all dunderheads who do everything in the dumbest of all possible ways.

I'm afraid I don't see how online merchants have killed my choice of products. In my not so limited experience, the exact opposite is true. Most local stores have almost no product selection. This trend of reduced product selection was in place long before Amazon existed or Wal-Mart appeared in my local area. The selection of products in almost every category has skyrocketed with online shopping. I'm sorry for the local merchant who goes out of business as a result, but, as a consumer, I see this massive selection as a very good thing.

Even with the reduced selection, I don't see grocery stores disappearing any time soon. Same day delivery is not the same as the 20 minutes it takes to run to the local store and pick up the items needed for tonight's dinner.

Your experience may vary, but I go into my bank branch at least once a month. I will admit they don't have nearly as many tellers as they once did, but there's seldom a wait of more than a couple minutes -- considerably less than it used to be before ATMs and direct deposit -- they don't charge me to talk to a teller and the service is always top notch.

The problem you describe is shoddy development practices. This has nothing whatever to do with the language being used. No language is going to protect you from an organization that allows rushed code to go directly to a customer without code review, thorough unit test, integration test, and V&V testing.

Dangerous, crap code can be written in any language. It is not unique to C.

I partly agree with the sentiment about learning to code in a particular language, but the bit about math skills is nonsense. I've been making a good living from coding (and design, test, specification, etc.) for almost 35 years. I've never once had to use math more complicated than what I learned in high school trigonometry. The vast majority of code doesn't require anything more complicated than the basics of add, subtract, multiply and divide. I'm not saying math skills don't come into play in some programming jobs, but suggesting skills at complicated math are a prerequisite for learning to code is just wrong.

Where I think many people go astray is in equating the learning of the mechanics of a language with having skill at programming. To a large extent the two are orthogonal. I might be able to teach somebody to speak English so they can do what's necessary in everyday life. This is not going to simultaneously make them a great author.

Lack of knowledge of a particular language is a temporary bump in the road for a good programmer. Complete knowledge of the ins and outs of Java will not by itself make someone a great Java programmer. I've spent far too much time cleaning up after "programmers" who were technically proficient in a language yet couldn't write "Hello world" in an elegant, maintainable way.

On the laptop or on the kid?