The He-Man Pattern Haters Club

Richard Mansfield has a bone to pick with object oriented programming:

Certainly for the great majority of programmers -- amateurs working alone to create programs such as a quick sales tax utility for a small business or a geography quiz for Junior -- the machinery of OOP is almost always far more trouble than it's worth. OOP introduces an unnecessary layer of complexity to procedure-oriented design. That's why very few programming books I've read use OOP techniques in their code examples. The examples are written as functions, not as methods within objects. Programming books are trying to teach programming -- not the primarily clerical and taxonomic essence of OOP. Those few books that do superimpose the OOP mechanisms on their code are, not surprisingly, teaching about the mysteries of OOP itself.

I am skeptical of dogmatic adherence to OOP myself, but even I did a double-take while reading this article. Is it a parody? I don't think so, considering he cites an entire website devoted to this subject.* But before (or at least until) you write Mr. Mansfield off as a kook, consider his background:

Richard Mansfield has written 32 computer books since 1982, including bestsellers 'Machine Language for Beginners' (COMPUTE! Books) and 'The Second Book of Machine Language' (COMPUTE! Books). From 1981 through 1987, he was editor of COMPUTE! Magazine and from 1987 to 1991 he was editorial director and partner at Signal Research.

This is a guy who has written a lot of code. While his opinion veers awfully close to religion, I wouldn't disregard it altogether. Too many people accept patterns as gospel, so I think a little counter-programming is healthy.

On the other hand, if you think the Gang of Four is as cool as, well, the Gang of Four, then you may be interested in this retrospective on Design Patterns, with comments from a variety of developers.

Ten years have passed since Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (aka the Gang of Four or GoF) wrote and published Design Patterns: Elements of Reusable Object-Oriented Software. And while most programming books that old are as pass as the technologies they covered or required second and third editions along the way, the GoF's seminal work still flies off bookshelves, despite being the same text that debuted in the fall of 1994 -- an eon ago in Internet time.

One interesting fact: the most commonly cited patterns were Singleton, Factory, Observer, and Command.

I'm currently reading Head First Design Patterns, which is basically Design Patterns for Dummies. It's a good read. But I still feel patterns are more useful as a common design vocabulary than as actual implementation models. It's kind of damning that even the radically simplified pattern examples in the book are far more complicated than they need to be. Would I really design a point of sale system that used the Decorator pattern to represent coffee pricing? I think I'd use a simple relational database table and some procedural code. If I needed to add a topping, I'd simply add a record to the table-- no complex objects or inheritance models required.

* As Damien Katz points out, this is the website of a "a megalomaniac nut named Bryce Jacobs", not the article's author.

MAME Cocktail Arcade, documented

After two weeks of non-stop tweaking, I think my MAME Cocktail arcade is finally complete. I created a MAME cocktail project page documenting everything I've done so far with lots of pictures and links to the products I used, and the rationales behind the choices I made.

Most of the comments there apply to MAME cabinets of all types, so if you have any interest in classic arcade gaming at all (or perhaps, like my coworkers, you're obsessed with Golden Tee), it's worth reading.

Video Codecs are the next DLL Hell

This issue needs more attention. Via Steve Makofsky

Codecs are the next DLL hell. While I love Nero Digital's simplicity and quality, the MP4's it produces aren't compatible with most commercial DVD players (due to the AAC or AVC audio). I've tried Dr. Divx - I get audio that isn't in sync with the video. Heck, even the camcorder video I saved the other night as an MPEG had some sort of audio codec problem. The most surprising? Some Windows Media (WMV) files that I've created in Adobe Premiere have had problems showing on my dad's machine. I suspect he has a codec problem of sorts. Codecs are the next DLL hell. While I love Nero Digital's simplicity and quality, the MP4's it produces aren't compatible with most commercial DVD players (due to the AAC or AVC audio). I've tried Dr. Divx - I get audio that isn't in sync with the video. Heck, even the camcorder video I saved the other night as an MPEG had some sort of audio codec problem. The most surprising? Some Windows Media (WMV) files that I've created in Adobe Premiere have had problems showing on my dad's machine. I suspect he has a codec problem of sorts.

Via Chris Lanier:

Another big issue is that these companies want their codecs to decode everything. Not only does the DivX codec from DivXNetworks decode DivX, but will also do XviD and 3ivX decoding. The 3ivX Suite decodes 3ivX, XviD, and DivX. So you get people installing DivX, XviD and 3ivX because they all have different names, and all the decoders can basically do the same thing (which is not always true; decode quality can be very different). Nero and EZ CD Creator also ship with MPEG-4 decoders that will generally decode XviD and DivX. Are you counting how many things on the system can decode the same content? It's too many!

Microsoft has always been slow to correctly address these problems, and they really are problems. They can't address or fix people on the Internet being dumb and offering packs of pirated and hacked codecs but I would say a good 60-70% of the problems people have with Windows Media Player are due to codecs. People have issues with Windows Media Center Edition and codecs all the time. The main problem is that a large pool of [uncoordinated] companies are [doing this]. Microsoft should take a stand and do a good job of educating people on what codecs are, what they do, how to find out what codec is used in a file, and where to download the correct codec.

It's an embarrassment that Windows Media Center [in its Windows XP incarnation] is totally dependent on a valid MPEG-2 codec -- it literally cannot function at all without one -- and yet does not ship with one in the box. On Chris' site, there's a response from Microsoft's Ted Youmans that lists the reason I've always suspected: licensing costs.

The problem with shipping an mpeg2 codec in the box is the royalties. When MS includes something it goes out in every copy whether the user will use it or not. Including the codecs would dramatically increase the price of windows to OEM's. These same OEM's already have deals with IHV's to include their mpeg2 decoders and use it as an upsell to customers.

Note that a DV codec is almost synonymous with an mpeg2 codec.

I can't say what MS will or won't do in the future, but it isn't quite as simple as just including them.

As to the original post: It's a very difficult problem to solve. DShow was based on the merit system (pun intended) with the idea being that using a combination of the filter's merit and how specific the media type/sub type is one could reasonably pick the right codec every time. It wasn't really designed for a competing merit nuclear arms race.

Now you can solve it on an application level easy enough, just specify the filter you want and ignore the merit. But how to generically solve it, where any application will always get the "right" filter is quite a bit more complex. The question becomes how do you know what the right filter is? You can't programmatically tell if one has better decode quality than another. Heck, people can't even subjectively agree on what is best.

Test solution 1: within the current framework each user can choose what they want their "default" one to be and raise its merit all the way. If individuals do it, then there is no arms race, but if MS provides a mechanism for you to do it you will suddenly see every new codec with its merit set at the max, and it will all be useless again. So now we need to provide a way to lower the merit of other "unwanted filters", easy enough but now the system is just as complex as it is today.

Test solution 2: Teach each app writer how to select their own filter and ignore the merit. This way they don't need to register high, they will get what they want anyway. The problem is this is extra work and they can just get this for "free" by raising their merit. Development time is money. Aside from that there are the generic applications (like MCE) which need to rely on someone else's codec and they don't have the luxury of specifying their own unless they present you with a list and ask you to choose.

I really don't have any answers for you. What I can tell you is that we are (and have been for quite some time) aware of the problem. It is one of our main concerns while designing the next generation of multimedia API's.

The parallels with DLL Hell are eerily accurate.

I think Ted's response is a copout. Cost? What about the "hidden" cost of all the thousands of codec problem posts on The Green Button forums? Microsoft needs to provide a default MPEG-2 implementation in the MCE box. Yeah, the OEMs may get pissed, but so what? Which is more important: the Microsoft software customer, or some faceless OEM? At some point Microsoft has to take a clear stand for the customer. Nobody else in this random collection of companies has the authority to make that kind of binding decision in the customer's favor.

OEMs will do what is best for them, not for us. Microsoft is the only consumer advocate that can help. If they abdicate their responsibility here, all Microsoft customers lose.

It's the IDE, dummy!

In VB.NET vs C#, round two, I realized that choice of IDE has a far bigger impact on productivity than which language you choose. Lately I've started to think the relationship between language and IDE is even more profound: the future of programming languages isn't a language-- it's the IDE, dummy!

Let me illustrate with a question:

Which would you rather use: QuickBasic with the world's best IDE, or (insert your favorite language here) in Notepad?

We now have languages that are the product of thirty years of computer science, but visual IDEs are still in their infancy. There are some tantalizing screenshots of proposed IDE designs in Lutz Roeder's Interactive Source Code presentation (powerpoint), even though it's four years old. There are also some intriguing IDE ideas from Roland Weigelt in his "wouldn't it be cool" series of posts, where he summarizes with

It's kind of frustrating to see computers rendering 3D worlds with 100s of frames/sec, but source code editors advancing only in very small steps.

Amen to that. I suggest any future language development proceed in this order:

1. Develop a kick ass IDE, incorporating the most popular features from existing IDEs, plus some innovations of your own.
2. Hard-code your IDE to a specific language or two; make it completely symbiotic and as deeply integrated as possible with those specific languages.
3. If you have any money left, pay third parties to design and sell IDE extensions. Take the most popular extensions, buy the company, and incorprorate those features in your IDE.
4. If you're not out of money yet, hold a contest with cash rewards for the best user-designed IDE add-in. Buy rights to the top three and incorporate them.
5. If you have any extra time or money left over-- and you can't think of any possible way the IDE could be improved any more-- wash it all down with the sweet nectar of syntactic sugar.

I don't think a one-size-fits-all-languages IDE strategy is sustainable. At least not if you want to be the best and most productive tool available. In the future, IDE will be synonymous with language.

RegexBuddy and Friends

Jan Goyvaerts released a new version of RegexBuddy today. I've talked about this tool before-- it's easily the best regex tool available. Some feature highlights for this version are:

• Built in GREP tool
• Visual regular expression debugging support
• Full unicode support

The GREP tool is an unexpected bonus; it's a mini version of his full PowerGrep application, which I use occasionally. GREP is a natural (and very UNIX-y) progression once you've mastered regular expressions; consider the utility of regexes on files and folders instead of strings and you've got the idea. Jan also maintains the excellent and free www.regular-expressions.info tutorial site. It's a great reference.

Have you noticed that the Visual Studio .NET find dialog supports regular expression searches? That's the good news. The bad news is, Microsoft decided to use bizarro world regular expression syntax. Many of the key regex tokens are the same, but they behave in ways I wouldn't expect from a regex search. For example, searching for "[a-z]+" results in a match on entire words, but it also results in per-character matches in the word unless you tick the "Match whole word" option. So be prepared for some trial and error. Why couldn't Microsoft just use standard regex syntax, like the built in .NET regex classes? If it's a compatibility issue, why not let us select between bizarro and standard regex syntax? I also heard that the VS.NET 2005 find dialog has the same problem, which is disappointing.

There is at least one add-in that provides standard regex find support in VS.NET 2003. I've tried it, and it needs a bit of polishing, but it's functional.

Universally Annoying Remotes, Revisited

Alex Gorbatchev posted his very favorable review of the Harmony H659 universal remote:

This weekend I made one of the best purchases ever and I'm not exaggerating. Up until now I have been in the remote hell. Let me describe my living room setup: TV, DVD, Receiver, PVR and Xbox. That makes a total of five remotes I need to operate to do certain tasks. Most of the time any activity involves at least two remotes. I was seriously getting tired of this.

Which reminded me-- It's been a month since I purchased my Harmony H680 remote. I try to avoid commenting on products until I've lived with them long enough to get past the new purchase honeymoon phase, and I think I'm well past that point now.

The short answer is, yes, it really works. You want one remote that's easy to program, easy to use, and controls all your devices? Look no further. I haven't touched any of the original four remotes in a month!

Although this is the likely the best and easiest to use universal remote on the market, I still have a few quibbles.

1. Web interface
   You set up the remote through a website, which seems like a good idea at first. However, the more you work with it, the more you realize that plain HTML interfaces are a giant pain in the ass for complex applications like this. Harmony Central is a classic argument for smart client applications. It's great that they have a huge database of user-submitted devices, but that doesn't justify suffering through a tedious HTML interface to edit everything, or waiting ~12 seconds to postback through 3 screens to get somewhere. And programming the remote over USB is done by downloading a file from the browser, which executes through an associated handler. It works, but it's all very hacky and much slower than it needs to be. Square peg, meet round hole. This should be WinForms + HTTP and a supporting website.
2. Button delays
   The default inter-button and inter-device delays are far too slow, on the order of 200ms. This can be adjusted in the advanced options of the website*. Even with the button delays set to minimum, the remote isn't responsive enough. On the Tivo remote, I could hit down-down-down and see immediate response, but with the Harmony it's down (pause) down (pause) down (pause) if I want the commands to be registered.
3. Command repeat
   Evidently, most remotes repeat individual IR commands multiple times to ensure they're received. By default, the Harmony repeats IR commands three (!) times. This results in weird side effects-- when I press volume up, the receiver steps up the volume 2 to 3 notches, and when I use channel down to navigate through long lists I frequently move down two screens instead of just one. Setting the repeat* value to 1 caused the remote to barely function. And setting it to 2 still results in some repeated IR commands.

None of these things are dealbreakers, but they're annoying. I suggest reading through the Remote Central Harmony forums for lots of great tips and tricks.

* good luck finding these advanced settings on the website, by the way. They're under "troubleshooting" and at least 3 webpages deep on the site, none of which allow you to use the back button. Someone send these guys a clone of Chris Sells-- patron saint of Smart Client applications-- stat!

Disk Space

Hard disk space, like CPU speed, isn't increasing as fast as it used to:

Still, 400gb drives can be had, and it's not difficult to build a terabyte array if you need to. Which begs the question-- where does all that hard drive space go?

Two tools I use to demystify the "gee, I had 50gb free yesterday" conundrum are overdisk

... and treesize.

Stuart Dootson also pointed out spacemonger, another graphical representation:

I like the Tufte-esque visual style of overdisk, but I'm not convinced the information is any more useful when presented in that format. I run Treesize on servers, too, and I'd like to find a command-line equivalent of Treesize if anyone knows of one.

Websites as Pinball Machines

I'm not sure I entirely agree with the website as pinball machine metaphor, but it's an interesting one:

A pinball machine is a great metaphor for describing how a Web site works -- not the mechanical side of working that involves ASP, PHP and databases, but the reality of how a Web site attracts and retains customers. By thinking of the Internet as a huge arcade, and your customers as kids with a pocket full of quarters, it's possible to take a fresh look at your Web site and how it can be more effective.

Some lessons from Forth

It's easy to get caught up in the "newer is better" mindset of software development and forget that ideas are more important than code. Not everything we do is obsolete in four years. The Evolution of Forth, which outlines Charles Moore's guiding principles in creating and implementing the FORTH language, is an excellent illustration of the timelessness of ancient computer wisdom:

1. Keep it simple
   As the number of capabilities you add to a program increases, the complexity of the program increases exponentially. The problem of maintaining compatibility among these capabilities, to say nothing of some sort of internal consistency in the program, can easily get out of hand. You can avoid this if you apply the Basic Principle. You may be acquainted with an operating system that ignored the Basic Principle. It is very hard to apply. All the pressures, internal and external, conspire to add features to your program. After all, it only takes a half-dozen instructions, so why not? The only opposing pressure is the Basic Principle, and if you ignore it, there is no opposing pressure.
2. Do not speculate
   Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each has 0 probability of realization. If you need an extension later, you can code it later -- and probably do a better job than if you did it now. And if someone else adds the extension, will he notice the hooks you left? Will you document this aspect of your program?
3. Do it yourself
   The conventional approach, enforced to a greater or lesser extent, is that you shall use a standard subroutine. I say that you should write your own subroutines. Before you can write your own subroutines, you have to know how. This means, to be practical, that you have written it before; which makes it difficult to get started. But give it a try. After writing the same subroutine a dozen times on as many computers and languages, you'll be pretty good at it.

I covered the first two points before in KISS and YAGNI. Point 3 is more subtle. It seems to fly in the face of don't repeat yourself, but what he's really saying-- and I agree-- is that you have to make your own mistakes to truly learn. There's a world of difference between someone explaining "you should always index your tables because it's a best practice", and having your app get progressively slower as records are added to the table.* You learn "why" a lot faster when you're actually experiencing it instead of passively reading about it.

* you laugh, but I've worked with developers who did this.

(Via Andy's underrated, unicode obsessed blog. Andy also points out that Moore characterizes simplicity as a force that must be applied instead of a passive goal. And he's right-- all too often, I see developers failing to make the hard choices necessary to keep their applications simple. It's easier to just say yes to everything.)

Ideas Are More Important Than Code

Do you have coworkers whose shelves groan under the weight of hundreds of pounds of technical books? I do. And I always try to gently convince them that maybe they should buy books by content instead of weight:

It took me a while, but I finally came to realize that books that are heavy on ideas and light on code end up having a longer shelf-life and make more of an impact. Books about tools are needed, but books that teach the "why" are so much better. Unlike those VB5.0 and .NET 1.0 books, theory changes slowly and incrementally. That is why some books are timeless. That is why some books with no code at all are constantly listed in developers' list of "must reads". Knowledge and theory never goes out of style, unless you stop improving on it.

Similarly, in my recommended reading list, I urge developers to consider that reading The Mythical Man Month-- which is over 20 years old-- might be a better use of their time than poring over the latest thousand page technical tome du jour. This can be surprisingly difficult to get across to skeptical developers.

An alternate take on this topic is Chris Sells' the most important thing that I've ever learned is how to learn:

Still, teaching without the foundation of knowledge isn't effective. How do I gain that foundation of knowledge? I consume the available material and ask "why" a lot. If I look at a class hierarchy and it's design isn't immediately obvious to me, I ask why it was built that way and why was that way chosen over another. And to the answers to those questions, I keep asking why 'til I get to something I know already or until I get to a human reason. The reason for not stopping 'til I get to something I know is that I believe that all learning is only as affective as well as it can be tied to what you already know. How easily it is to learn something is directly related to how much you already know about related topics, so the more you know, the easier it is to learn more.

It seems a bit myopic to me that Chris states COM was too hard to learn "naturally", and emphasizes the value of asking "why", yet he can't seem to ask himself why is COM this hard to learn and teach?. Well designed systems are easy to understand. Anyone can develop a complex system that takes a week long training course to comprehend. Developing a complex system that a developer can master in a day, well, that's a lot more impressive.