If I have an idea, I have to write it down. I am a cyborg, and the pad of paper is my augmentation. Paper does not forget. It does not change what I write. I would change my ideas later on to sound more reasonable, but paper does not change a thing. The pad is an extension of my long-term memory that actually requires less processing to store. It is an overflow file where I can route the excess bandwidth during peak times and come back to parse the logs when things have died down.

Ironically, I am not writing this on a pad, or paper of any kind. I did use a pad earlier, to capture fleeting thoughts during a speech. When high-tech isn't available (for whatever reason), low-tech is well-developed enough to handle some scribbled half-baked notion, as it has been for millenia. While driving, I dictate voice memos to myself (for safety as much as anything). At my desk I use whatever program is at hand -- or a pad, or a post-it note, or a piece of scrap paper, or my PDA... as long as it is captured somehow, I can attempt to salvage it later. While writing this short essay I opened two or three tabs in various background applications as a way to record ideas that were flashing through my mind.

There are three things that can happen to an idea after you have had it:

1. it can be forgotten and all potential lost,
2. it can be acted upon and made to serve you, or
3. it can be ignored, sinking into disuse but not erasure.

The first is unfortunate but rarely fatal. The second is the best case, but it can monopolize your time. The third is the killer; an idea ignored comes back again and again, sounding worse each time but never going away. Know this, that either you will cause your thoughts to serve you or you will be made to serve them. It is a tyranny of the mind, and you must capture them somehow. Otherwise your mind may choose to hold onto its ideas until you are ready to listen again. Even if you capture an idea only to throw it away later on, now it is out of your mind and you can move on with accomplishing other things. If you were not going to act on that idea, then you have forcibly moved it from the third case to the first and avoided the mental fatigue that accompanies an idea that is ignored!

So, with apologies to Frank Herbert:

I must not procrastinate. Procrastination is the mind-killer. Procrastination is the little-death that brings total obliteration. I will face my idea. I will permit it to pass over my mind and through my fingers. And when it has been recorded I will turn the inner eye to see its path. Where the procrastination has gone there will be nothing. Only my productivity will remain.

For content producers, it might also be important to search the Internet for images identical to images they own to protect against copyright infringement. Performing that kind of search using text would be difficult at best, and impossible to automate.

This is not really my research area, but a few years ago I needed to write a research paper for a class and hit on the idea of using fingerprint recognition algorithms for image search. Thus the incredibly wordy title of (deep breath):

A Novel Use of Automated Fingerprint Identification Systems for Large-Scale Image Search on the World Wide Web

Self-important titling out of the way, it was quite an interesting technology evaluation to perform. Of note, several of the companies I looked at also sell facial recognition software, and some may even produce large-scale image search systems now; I haven't kept up with the market.

Most interesting of all, though, is the productization of image search: a site called TinEye takes an image as input and returns a list of similar images, along with their location on the Internet. This, of course, is a long tradition in computing: yesterday's research project is today's hot product and tomorrow's old hat. Fun to see it in action, though.

Update: Google image search using images was just announced today at Google's 'Inside Search' event. Interesting that this space is starting to get populated now!

This is not a common use case, so Word doesn't make it easy for you. Fortunately, there is a simple (though non-obvious) process for getting the sources back:

1. Export the document as a "Web page with supporting files".
   • This will save all embedded images (and their original forms, if they've been modified) to a folder in the same directory as your exported HTML file.
   • Note that the folder and files are linked to the HTML file, so moving it around may have unintended consequences.
2. Look inside the 'supporting files' folder and find the image(s) you want to use.
3. Copy the image(s) to another location to break their link to the exported HTML file.

That's it! Your source images will even be in the same format as they were originally.

One leg is not stable at all; two legs, stable on one axis; three legs, stable on both axes. But four legs (a chair) can be unstable if the surface does not match the lengths of the legs precisely.

So it is with product marketing: you need to provide some number of selling points in order to make a solid case. You must be careful in the construction of these points, however, because if you are too zealous and exaggerate the benefits, later selling points may interfere with or negate those that came before.

If you can't add any more selling points to your list without contradicting what you've already said, you don't have any more selling points. Or you lied. If you run out of selling points before the sale is stable (a two-legged stool), then you don't have a compelling product.

This is a toy example, so the interface isn't really that useful. However, what if I want to treat ExplicitAdder and ImplicitAdder the same way? Both classes provide an Add method that accepts two integers and returns void. They're still different types, however, and ImplicitAdder doesn't declare that it implements IAdd even though the method signature matches the definition. This is by design, of course; it could be that the method in ImplicitAdder has nothing to do with IAdd and only matches the signature by accident. But it does make things difficult when you really want that class to implement IAdd:

This code shows the result of two different types of casting in an attempt to "attach" the IAdd interface to ImplicitAdder. Of course, casting ExplicitAdder to a variable of type IAdd works just fine. But when we use the 'as' keyword to perform the same conversion on ImplicitAdder, a null value is returned, indicating that this is an invalid cast. The explicit cast throws an InvalidCastException.

It is possible to execute the Add method using reflection on the type (or in C# 4, using the dynamic type), but this makes code fragile. What if the interface changes? The compiler cant' tell us to update the class. What if the class changes? The compiler can't tell us to update the reflection code. It just moves the problem into the run-time arena. This is a tactic to use when there's no other solution, but I don't like it much for software maintenance. No, the proper way to attach an interface to a class is by using a decorator of sorts:

Here we wrap the ImplicitAdder in a class that does implement IAdd. We pass a reference to an ImplicitAdder into the constructor and then use the wrapper object instead. This way the compiler can check all of our references at compile-time due to static typing.

All well and good, but this model feels pretty limiting if you want to have multiple visitors that work on the same objects but produce different data types. In that case you can a) create as many versions of the visitor interface as you have data types to be returned, b) always aggregate within the visitor class, thus having to deal with mutable state inside the visitor, or c) always return object. Of those options, the first is tedious and the third is ugly. To my mind, both of them defeat the purpose of having the pattern in the first place. The second option is not bad, but I wanted something better than that.

Modern languages such as Java and C# include support for generics, so I tried my hand at writing a generic Visitor pattern that could be used on the same data structures by multiple visitor implementations that produce different data types. Using the new (well, newly old) features in C# 3.0, I was able to get a lot more. Let's start by looking at the IVisitor interface, which is parameterized by data type:

IVisitor is fairly straightforward when you think about it — we define a set of methods that accept an object of type R and produce an object of type R by visiting an IVisitable. This way we can write a single IVisitor interface for a data structure and then specialize it for a specific type later on, during the implementation. This is a nice improvement, but there's more we can do. C# 3.5 introduced extension methods, which allow us to attach methods to a wide range of classes at one time. Using a single extension method, we can eliminate the need for the second half of the traditional Visitor pattern, the Accept() method:

Now the Accept() method is available to be called on any class that implements IVisitable, as long as we provide an implementation of IVisitor. This means that we don't have to copy and paste the same code to every class that implements IVisitable any more! We can just call this method and .NET will wire it up.

The above definition makes use of a marker interface called IVisitable, but you could even restrict the application implicitly by which Visit() methods you define. In the case of a marker interface, you simply need to include a default method for visiting an IVisitable like so:

Which completes the generic visitor. Using a generalized class like this one allows us to program in a more functional and (hopefully) testable way. Plus, it's nice to actually use the new language features once in a while.

It's entirely possible that I've missed something in the implementation, so be sure to shout out in the comments if you've found a problem. Otherwise, enjoy your new generic Visitor in C#!

P.S. I should also give credit to some StackOverflow answers that suggested this approach, as well as a blog post on generic visitors in C# by Nicolas Penin, though I'm not aware of anyone else with an identical approach.

Update: Daniel Gröndal pointed out some issues with this approach in the comments. It turns out that the extension method does not work as I thought it did during my initial testing. Please read the comment thread for more details!