Browsing through some old entries, I see in late 2007 I predicted: One of the milestones I've been watching for is the first entirely DVD-based TV-style series. It's going to happen sooner or later, and will mark a major shift in how TV is produced, once it becomes possible to make it without advertising or subsidy, the only two models that currently work. I'm going to give myself only half-a-point.

Dear Meijer Corporation: I love you guys. You guys are great. I know it's tradition for Internet "open letters" to be extended complaints, but nah, you're great. But you know, I do want to air just one tiny grievance. 'Cause this is the Internet and all, and that's what we do here. But rest assured, it's just a tiny little thing. Hardly worthy of note. But I thought I should point it out anyhow.

A couple of months back, I analyzed whether I wanted to propose switching to Go for work. I've still technically got the blog post with the results of that analysis in the pipeline (though who knows when I'll get it up), but there's a part of it that keeps coming up online, and I want to get this bit out faster. It's about whether Go has "sum types".

An article about why virtual worlds died reminded me of a pet theory, by virtue of not mentioning it as one of the possibilities. I call it the BOAC Fallacy, which stands for "... but on a computer!"

Yes, complete with the ellipses and italics. There's a recurring pattern I've seen in technology prognostication best shown by example.

I surrender. Many years ago, I set myself a simple task. I would create a blog layout for myself, and it would have some sort of color in it. It would not simply be a white background. After all, the best way to learn something is to force yourself to do it, right? Unfortunately, I failed. The resulting design could be charitably described as "quirky" and accurately described as "

Human words are a great deal fuzzier than the concepts they hope to cover. For instance, consider the word "love"; it means anything from stalker-level obsession to a moderate preferance ("I love pizza!"). In order to talk about anything precisely it is often necessary to specify what a given word refers to in some specific context. Every writer has the right to choose what definitions they are using in a particular bit of text.

(A not-quite twitterable bug report for @Netflixhelps:) Setting family controls on the XBox 360 (system-level preference) to G correctly causes unrated content or content rated higher than G to display the locked-out icon. In the previous version, navigating to one of them and pressing A would prompt for the family password, then unlock all the covers. You'd have to enter the family code again to watch. In this version, if you navigate to a locked folder and press A, you get the family code entry, but upon successful entry you immediately begin watching the selected video.

When I was younger, I thought leadership was oversold, and what really mattered were the people on the team. I have recanted this belief. I still don't entirely understand why leadership is so important, but the experience I've collected over the years is pretty clear on the matter. My best guesses are that it is some combination of the following: It is true that the performance of a team is bounded on top by both the quality of the team and the quality of the leadership, but people tend to badly underestimate how much quality and talent there is in the world.

It's time for gas stations to drop that nine tenths of a cent off their signs.

Learn You a Haskell for Great Good! (A Beginner's Guide) by Miran Lipovača, published by No Starch Press (2011). No Starch was kind enough to send me an advance copy for review.

Haskell books for "real programmers" are still thin on the ground, being limited at the moment to Real World Haskell (2008) and possibly Programming in Haskell (2007). As its introduction states, this book is aimed at existing programmers who are currently fluent in something like Java, C++, or Python, and would like to learn Haskell.

I put my take on the traditional discussion of why you should consider learning Haskell in another blog post, so we can get on with the review here.

The hardest thing about learning Haskell with no previous functional experience is bootstrapping the strong foundation that you've long since taken for granted in your imperative language. If you don't have this strong grasp of the fundamentals, then every line of code is an invitation to get stuck on some subtle issue, and you'll never have the fluency that great work requires until you have that foundation.

This book is the best way I know to obtain the Haskell foundation you need for fluency.