So that's the way video rentals work, and they all stock VHS cassettes, and that's that. But now a sea change occurs: somebody invents DVDs. All of the video rental shops start building their stock of DVD titles, and while doing so they take advantage of their affiliation network, so if your favored shop doesn't have Joe Dirt on DVD, they can get it from the shop across town.

But one little shop bucks the trend — even though DVD is the future, they decide to stick with VHS. And that works out okay for them, because while the other rental shops are investing heavily in building a DVD library, they're making room by selling off their VHS cassettes, and this little dark-horse shop is gobbling them up like popcorn, and their library is huge.

Now it's ten years later. Every video rental shop around the world has switched to DVD, but this little shop is still on VHS. It's impossible to buy a VHS deck in stores, so this shop rents or sells you a VHS player when you sign up for membership, but that's okay actually — some people find that kind of convenient.

But now something interesting happens — a big, new, hit movie comes out... but only for DVD. This little shop is caught-flat footed, because they simply can't compete here. So what do they do? They advertise!

This shop starts running ads, talking about how the local Blockbuster has a tiny library of titles, and it's absolutely terrible how small their library is. Now, in a sense that's true; any individual Blockbuster may have a small library available, but keep in mind the affiliate network — when you get a DVD at Blockbuster, you may be getting it from any one of dozens of DVD rental places all over the world.

---

So what does any of that have to do with anything?

Well, VHS is the creaky old CDMA digital cellular technology. DVDs are GSM, the modern cellular network architecture that almost every cellular carrier around the world uses. Our hit DVD is obviously the iPhone.

And the tiny dark-horse video shop, that's Verizon.

Now, don't read this as a defense of AT&T. Personally I haven't had all that much trouble with them, but I know plenty of people who reflexively spit upon hearing those letters, and it's pretty clear that AT&T has been using their iPhone windfall to make money hats rather than investing in their network infrastructure, and that's clearly subpar. But while I dislike incompetence and don't care for spin, I absolutely loathe deception, and that's what Verizon's 'map' ads amount to, in my opinion.

The 'Verizon map' in those ads is, by necessity, a map of Verizon-owned-and-operated coverage zones; they have to be Verizon-owned-and-operated, because nobody else is running CDMA these days, just like nobody's using VHS or Windows 95. The 'AT&T map' to which they compare themselves, meanwhile, is of AT&T-owned-and-operated coverage areas, which is not at all representative because AT&T has reciprocal carriage agreements with GSM carriers throughout the US, and roaming agreements with GSM carriers around the world.

Personally, I can't stand Verizon — they have a policy of installing Verizon-controlled firmware on every phone they support, which tends to cripple the phone by removing built-in features to encourage you to use Verizon's expensive and inferior network-based equivalents. Ever try to copy a ringtone to your Verizon phone using standard Bluetooth file transfer? If you did, I'm betting it didn't go so well. But Verizon does have a lot to offer customers, and if they want to be taken seriously they should compete by explaining the benefits of Verizon rather than deceiving people about the non-deficiencies of their competitors.

If over a year has passed and two of those three people are still on the list, your company is probably screwed. You might not actually have realized it yet, but that doesn't make it any less true. Your management or business metrics may actually be positive, but if your development team isn't improving, the technology underlying everything is stagnating and sooner or later the smell will reach your customers.

Unless you already employ the best programers in the world, of course.

And if you really and truly believe that you employ the best programmers in the world, then unless your company name rhymes with 'Foogle', 'Schnapple', or 'Sicromoft', you're probably really screwed.

Asynchronous function calls seem, at first blush, only a little more difficult — instead of calling DoSomething() and executing your follow-up code after it returns, you pass in a callback: BeginDoSomething( Action callback ).

So, problem solved, let's go home. Unless you need a return value, that is. But even then it seems simple; to turn a synchronous method like int CalculateSomething( ) into an asynchronous method, you just pass it a delegate that takes a parameter: void BeginCalculateSomething( Action<int> callback ).

So is that it? Nope. Because all of that is wrong.

Even though the original DoSomething( ) method had no return type, it still had a return path — it could throw an exception. Let's imagine that BeginDoSomething looks something like this:

public void BeginDoSomething(Action callback)
{
    PrepareForLongRunningOperation( );
    
    ThreadPool.QueueUserWorkItem(
        delegate
            {
                LongRunningOperation();

                callback();
            });
}

A handy way to think about this sort of thing is to figure out where a thrown exception would emerge.

If something goes wrong within the call to PrepareForLongRunningOperation, that happens in the same context as the calling code — any exceptions will throw up to the calling code and come out of its call to BeginDoSomething. The same applies to the call to ThreadPool.QueueUserWorkItem — no problem there.

But what if LongRunningOperation throws?

LongRunningOperation would throw up into whatever internal part of the ThreadPool implementation actually launched it. That exception can't come out of ThreadPool.QueueUserWorkItem, because by the time the asynchronous anonymous delegate is running ThreadPool.QueueUserWorkItem has already returned. And since the exception can't come out of ThreadPool.QueueUserWorkItem, it also can't come out of BeginDoSomething — which means there's no way for the calling code to get the exception.

There are two main approaches to this problem — error handlers and completion calls.

Instead of passing your begin method one callback, pass two: a callback to be invoked if everything goes to plan, and an exception-accepting callback to which errors will be passed.

public void BeginDoSomething(Action callback, Action<Exception> errorHandler)
{
    PrepareForLongRunningOperation( );
    
    ThreadPool.QueueUserWorkItem(
        delegate
            {
                try
                {
                    LongRunningOperation();
                    callback();
                }
                catch(Exception ex)
                {
                    errorHandler(ex);
                }
            });
}

// Sample usage:

BeginDoSomething(
    delegate
    {
		// Do something now that we're done
    },
    delegate(Exception ex)
    {
		// Do something with the error
    });

There are strengths and weaknesses to this approach. The biggest strength of this model is that it forces the calling code to think about error handling — the prompt for it is right there in the method signature. Error handling tends to fall through the cracks in any sort of code, but it's especially easy to overlook in an asynchronous context (It's also a lot more dangerous in an asynchronous context, because often dropping a callback invocation will cause a process to spin forever, sucking down resources and accomplishing nothing).

Separating the success case from the failure case may be either a strength or a weakness, depending on the particular task. Sometimes it makes your code much cleaner, but it often happens that your success and error handler need to share context and implementation, which can make for some very ugly code.

Instead of just invoking a parameter-less Action callback or a single-parameter Action<TReturn> callback, your code calls a single-parameter callback and passes it an Action or Func<TReturn> that the callback in turn invokes.

public void BeginDoSomething(Action<Action> callback)
{
    PrepareForLongRunningOperation( );
    
    ThreadPool.QueueUserWorkItem(
        delegate
            {
                try
                {
                    LongRunningOperation();
                    callback(delegate { });
                }
                catch(Exception ex)
                {
                    callback(delegate { throw ex; });
                }
            });
}

// Sample Usage:

BeginDoSomething(
    delegate(Action complete)
    {
        try
        {
            complete();
        }
        catch (Exception ex)
        {
            // Do something with the error
            return;
        }
        // Do something now that we're done
	})

At first blush, this seems like a much clumsier solution; you're essentially trusting the calling code to call your completion method. That's true, at least in this case.

Where completion calls really shine are for asynchronous calls returning values; instead of calling their callback and handing in an Action, you call their callback and give it a Func<TReturn>, which they then must invoke to get their result. That gives you an opportunity to throw exceptions that they can't cleverly bypass:

public void BeginCalculateSomething(Action<Func<int>> callback)
{
    PrepareForLongRunningCalculation();

    ThreadPool.QueueUserWorkItem(
        delegate
        {
            try
            {
                int result = LongRunningCalculation();
                callback(() => result);
            }
            catch (Exception ex)
            {
                callback(delegate { throw ex; });
            }
        });
}

// Sample Usage:

BeginCalculateSomething(
    delegate(Func<int> complete)
    {
        int result;
        try
        {
            result = complete();
        }
        catch (Exception ex)
        {
            // Do something with the error
            return;
        }
        // Do something with the content of result;
	})

Personally I prefer completion calls, mainly because the the pattern works so well for return values. In practice, any time you need this sort of a pattern it's because you care about return values; if you need to ensure that X happens after Y, it's generally because X depends on the result of Y. If X doesn't depend on Y, that's often a sign that you're being too linear in your analysis and that the tasks should be happening in parallel.

Microsoft seems to have collectively reached the same conclusion; IHttpAsyncHandler, the asynchronous methods off of SqlCommand, and the asynchronous forms of WebRequest all use the completion call approach.

My function takes a function and when done it calls that function, passing a function that the calling function calls for the result.

Now in fact my function calls another function taking a function accepting a function to call for its result, and to that function it passes a function which when called calls the first function passing a new function that when called calls the function that was passed to the function that my function passed to the other function, thereby returning the result of that function to the function that called my function.

And they say you can't write Lisp code in C#.

I'm trying to decide the best way to show text bubbles. Everything's pretty scrupulously iPhone-friendly this time around (that's actually what got me started on Xclan again, figuring out how to work with UDP CFSockets in a run loop), but as I understand it uploading new text textures every few frames will bog an iPhone down pretty quickly. I'm thinking of switching my NSOpenGLView to a CAOpenGLLayer and putting a bunch of CATextLayers on top for the bubbles.

There's actually an NSTextField in a layer in the game window; on Leopard it floats above the NSOpenGLView, but in Snow Leopard (where the screen shots were taken) it's invisible. I haven't pursued it because I was planning on replacing the OGL view with a layer anyway, but it's a strange difference.

Your code sucks.

It's okay though, so does everyone else's code, including mine. But a big part of improving is recognizing what you're doing wrong, and a big part of that is having random bald guys berate you. So in the spirit of improving the world, here are five thoughts on writing code that sucks less. Heavily C#-centric because that's what I've been reading lately, but I think most of it's meaningful in any environment modulo some terminological adjustments.

1. Dumb Comments Are Dumb

A comment that doesn't say anything useful is worse than worthless; it's actively harmful.

If you have a property named Marklar with a comment telling me that it 'gets or sets the Marklar', you haven't told me anything of value, and reading your useless comment has cost me precious seconds of my life that I'll never get back. You've also probably raised my blood pressure a bit, but I suppose that's more on me than on you.

Now if a Marklar is an odd or confusing type of thing, and you can't reasonably expect everyone to know what it is or why it's there, by all means explain it. Similarly, if this property has unusual behavior in some respect — perhaps it's lazily loaded — mention that in a comment. But don't just put a bloody comment on every property because some never-been-employed professor once told you that that's the right thing to do. It isn't. If someone can't tell you that the EyeColor property lets you get or set the color of the receiver's eyes, they have no business writing code in the first place.

You should only put comments where they're needed, and generally if a comment is legitimately needed it's a sign that you're writing bad code. Don't name the property Age and then add a comment explaining that it's in seconds; name it AgeInSeconds and skip the comment entirely. That saves you typing, saves me reading, and has the further benefit of being completely impossible for future programmers to miss unless they're severely mentally impaired (in which case, see above, they have no business writing code in the first place).

Similarly, if you feel compelled to add a comment explaining that the next five lines of code are stochastically approximating the chronosynclastic infundibulumation of the yada, yada... that's your sign that those five lines should be extracted into a method with an appropriate name like 'AproximateTechnobabble'. That makes it easier for me to read the original method because I can temporarily ignore the hard stuff, while also making it easier for me to understand the hard stuff later on if I need to (since it's now isolated with clear, labeled inputs).

Finally, dumb comments are dumb not just in the code, but everywhere. If your checkin note is "I changed the twelfth character of line 37 from an 'e' to a 'z'", you have so completely and cleanly missed the point of checkin notes that I can't even scrape together a proper disparaging simile. Checkin notes are there so I can get a high-level understanding of what you've checked in, without having to open the bloody file. "Ran a match along a patch of bark" is a lousy checkin note when what you actually did was "burned down the forest". Tell me about the forest, I couldn't care less about the trees.

2. Every Time You Type '#region' I Die A Little Inside

Regions suck. If I were king I'd ban 'em outright, so sincere and total is my dislike. They're a trick you play on yourself to let you pretend that your bad code is good, and they tell the world that you're a good enough coder to know a three-thousand-line file stinks, but that you're either not good enough to fix it or you're just plain too lazy. In either situation the solution is to step up, not to add a region and sweep part of the bad code under the rug.

A special note on regions within methods: wrapping a region around your twelve constructors to hide the excess complexity is a venal sin. Putting a region inside your method to hide 3,000 of its 4,000 lines is a mortal sin.

Some people might ask why extracting methods (like AproximateTechnobabble above) is good but collapsing regions within a method is evil. The simple answer is encapsulation; a region isn't a new scope, so it has access to all the fields and variables of the method it's within. That greatly increases the difficulty of understanding the code, because now I need to actively read through and figure out how the code inside the region interacts with the code outside the region. An extracted method doesn't have the problem, because I can look at exactly what parameters are passed in and exactly what comes out, without having to trace through and worry about side effects. Regions superficially seem to simplify the complexity of your code; extracted methods actually do.

3. Static Methods Are Your Friends, And You Should Want More Of Them

Static methods are pure functions, in the mathematical sense; they're black boxes that take some input and return some output. Remember where I said methods are better than regions because they simplify complexity? The same logic recommends static methods over non-static methods. Static methods help you make sure you're not weaving a tangled web of side effects and dependencies with each method call.

Imagine coming upon a call to myComplexMarklar.CalculateInfundibulumation(). Now, if you don't know what infundibulumation is (incidentally, the state of being or the act of becoming funnel-like or akin to a funnel), and have no idea how you would calculate it (no idea), that method doesn't tell you a whole lot. Now imagine stepping through that rather lengthy method and figuring out how it works. You are potentially entering a world of pain.

Now imagine a static method, Marklar.CalculateInfundibulumation(float topRadius, float bottomRadius, float height), and further imagine that the non-static method works by calling the static method and passing along the three appropriate values. It has instantly become a whole lot easier for me to understand what infundibulumation is, because now I know that no matter how gnarly the math is it's just a function of those three values. Now not only can I better understand that particular method, but a lot of the meaning of the Marklar class in general has become more clear.

In an object-oriented language, every instance method is getting more parameters than you've listed in the declaration line; it's also getting access to all of the instance's member fields. Imagine seeing that written out — would you deliberately write a method that takes a hundred parameters but only uses two of them? That might be a good sign that it's time for some judiciously-applied static methods.

Static methods have other benefits. For one, they're a lot more reusable; if the static CalculateInfundibulumation( tR, bR, h ) method is general, you might find you need it in another class. Depending on your situation, you could either make it public and call it right out of Marklar, move it to a new common base class, or move it to a utility class. Each of those solutions would be far more complicated if it were non-static. I've been in situations where I needed a complex non-static method from a pre-existing class that I couldn't reasonably modify, and ended up constructing an instance with a bunch of bogus data, setting the handful of fields that the calculation actually depends on, and calling the instance method on that. That's hideous — ugliness wrapped in brittleness wrapped in unmaintainable complexity. Don't make me do that again.

Static methods also lend themselves incredibly well to a form of optimization known as memoization. The root of memoization is basically the realization that the next time you run the same calculation, you'll reach the same result (yeah, I know, 'duh', right?). The tie-in to static methods is that static methods let you know precisely what the inputs are to the calculation you're running, while instance methods don't. Memoizing a static method is 'easy' (in the sense of being a solved problem), while memoizing instance methods can be a buggy pain in the butt.

3b. Subverting Static Methods Is Bad And People Who Do It Should Be Forced To Write Pascal

Sometimes you'll see a static class, full of static fields and static variables and static methods. That's not what I'm talking about when I say static is good. That's not good, it's the other thing. Bad. It's a crappy-ass degenerate-global-variable-singleton. Don't do that. Smart people hate singletons.

4. Properties Are Properties, Methods Are Methods

A property is intended to represent an attribute of an object, while a method models an action that the object may take or that may be taken upon the object. These are different concepts, and you need to think about which is appropriate for a particular case. If you have a property with a verb in the name, you're almost certainly thinking about things the wrong way.

Some people will tell you that properties should just be get/set wrappers around your fields. Others will say it's okay to do some field validation. Others go hog wild. It's hard to draw bright lines because the simple fact is that it's sometimes a judgement call. A good heuristic is to think like someone using your class. The default assumption is that properties are simple get/set wrappers around a private field, and everything you do to violate that assumption nudges the scale towards building a method.

Let's say your class has a ServerConnection property that returns some sort of communications channel to a remote server. As a caller, my mindset is that this connection already exists, and the property is giving me access to it. But if only a subset of the calling code ever needs this connection, it might make sense to lazily connect when the property is first accessed rather than connecting in the constructor and keeping around a connection that may never actually be needed. But that's changing the semantics of the property a little bit, because the mindset of the calling code is still 'this already exists, the property is just handing it to me', and the calling code may not expect this property to take a long time to execute. Maybe now there should be a progress bar, or the call should happen in another thread.

Like I said, judgement call. In situations like that one, asking ten developers will get you fifteen different opinions. There isn't a 'right' answer, it's just a matter of getting it right enough. All anyone can ask is that you think.

But in other cases, it's totally cut and dried. I've seen code with a LastSaveDate property that saves to the database and returns DateTime.Now. If you're not physically ill at the thought of that, you need to figure why and get sick fast.

5. Public Methods Are Contracts, Which Should Not Be Entered Lightly

When you make a method public, you're inviting the world to use it and you're promising that it will continue to do exactly what it does now. Forever.

Let's say you're creating a CarFactory class that creates new Car objects. CarFactory.CreateCar( ) was starting to get a little long, so you started extracting out helper methods: CreateTransmission( ), CreateBody( ), CreateWheel( ), etc. That's good, keep doing it.

Now let's say you decided that since CreateCar( ) was public that you might as well make CreateTransmission( ) et al public too. That's no-so-much with the good. Unless you know right now that someone else needs to create a transmission without creating a full car, leave that method private.

To the calling code, a CarFactory and a Car are black boxes. The calling code doesn't need to know that a car contains a transmission, and next year when you change CarFactory and Car to build fully-electric vehicles, which don't need a transmission, you won't have to worry about supporting that public method that a bunch of your coworkers have just spent twelve months linking against.

There's a more general lesson here: Share the hot dog, not the making thereof.

Which, come to think of it, is a good moral on which to end any story.

I'm pretty sure this is roughly what the designers of Twitter had in mind, incidentally. If you take a look at the XML or JSON feeds provided by the Twitter API, each individual tweet is actually called a 'status' — the URI for a particular tweet is <username>/status/<some_big_number> — the <OL> element that contains the tweets on Twitter HTML page is of CSS class 'statuses'... the list goes on. Obviously the original intent of the tool doesn't define what the tool is actually used for — I don't think AIM away messages were intended as an out-of-band communications protocol, at least at first — but it's interesting nonetheless.

What's also interesting is that Twitter users seem to fall into two separate and largely non-overlapping groups. Group A are people using it much like I am, as a non-ACKed broadcast medium for random thoughts that aren't important enough for a reliable messaging protocol like IM, email, or a blog post. Group B are the people who see Twitter as a marketing/communication tool that will allow them to get the word out to members of Group A, for whatever value of 'the word' is meaningful to them.

I see three ways this can go: either the two groups diverge completely and group B develops a self-sustaining ecosystem of their own; or group B recognizes that marketing in this context is futile and dwindles and dies; or group B is so persistent in their efforts that group A abandons Twitter and finds a new bicycle.

If you get the 'new bicycle' thing, you're definitely in group A, though not getting it doesn't necessarily relegate you to group B.

But if you know you're in group B and want to understand group A, then you should figure out what it means, why you don't get it, and what you can do to make sure you get to autotune the new new bicycle... and then despair of ever marketing effectively on something like Twitter.

First some background — I don't expect folks who haven't spent time with C++ to know much about this, and a surprising number of veteran C++ coders seem to be unaware of it as well. In C++, const can be many things. One role is as a type modifier that means "I'm not going to change this". A common usage is to accept a const references:

int calculateAverage( const std::vector<int> & values );

That const means "I'm just going to look at it, I'm not going to mutate it" (or, if you like thinking functionally, "I'm a real function, hand me my immutable input" — more on that angle later). What does that mean, in terms of actual code? It means the body of that function can't call (for instance) values.push_back( 12 ) and mutate the data it was handed. And when I say "can't" I don't mean "shouldn't", I mean the compiler will actually flag that as an error and stop you. If you keep trying it'll even call you names.

Now obviously the body of the function still needs a way to call methods on that vector — it'll need some to get at the contents, whether it's running a for loop from zero to values.size( ) and calling operator[] in between, or looping from begin() to end(), or whatever. So what makes those methods okay, and push_back, pop_back, insert, swap and various other mutators verboten?

The answer (as you've doubtless cleverly deduced already) is the const keyword. In C++ const isn't just a type modifier for variables and parameters, it's also a permitted modifier on methods too. The size( ) method on an array is declared like this:

size_type size() const

That const means "you can call me on a constant object, object reference, or object pointer! I promise I'm safe!". And that isn't an idle promise, it's a promise enforced by the compiler. If you declare a const method in a class and then try to alter member variables, the compiler's going to call it an error (unless that member is declared as volatile, but that's getting into advanced C++ and beyond what I'm interested in talking about here).

The final crucial piece of the big, tasty, onst-in-C-plus-plus-pie is the fact that you can overload by const-ness. The aforementioned std::vector actually declares not one but two operator []s (or should that be 'operators []'?), one of which returns a reference to the space in the underlying array, and one of which returns the simple value.

So that's what I mean by const when I say "I like const in C++".

The usual justification for this feature set is efficiency; the compiler can differentiate between const operator[], which returns a simple value, and non-const operator[], which must return either a reference to an internal data structure or a proxy object, neither of which is necessarily easy or fast.

But me, I like const for a different reason. And that's documentation.

Backwards digression, the second: Defining the types and parameters of a function or method isn't a fundamental necessity; you could define a language where functions access the parameters they were passed by indexing into an array and assuming things are where they belong. It's very easy to do this in JavaScript, for example — the language doesn't verify parameters, and a function is free to get them out of the local arguments array:

function sayHello() {
	alert("Hello, " + arguments[0] + "!");
}
sayHello('World');

There are two reasons to specify type parameters; to tell the compiler the semantics of the function, and to tell the human reading the code the semantics of the function. I'm phrasing those in parallel for a reason, because they're two aspects of the same principle; function argument lists exist to document the code. This just happens to be one of the (distressingly rare) cases where the documentation is so intrinsic to the language that we don't realize it's documentation.

There's something special in that. Microsoft recognizes how important self-documenting code is; that's how IntelliSense works, and I think you (or I, at least) could argue very plausibly that (a) the entire .NET architecture can be viewed as a means to improve and extend IntelliSense and (b) this may well represent Microsoft's biggest strategic advantage over its competitors. The core idea that makes IntelliSense work is that the best documentation of the code is the implementation itself; the more information you can mine out of that, the better.

The back-end of one of my employer's new (award-winning!) products is a suite of RESTful web service APIs. One of the core parts of any such system is the routing engine; given the URI of an incoming request, how do we map that to the bunch of code that represents the appropriate response? Our system uses XML-formatted resource maps that contain the information necessary to do that; a resource map contains not only URI paths, but the parameters to extract from those URI paths and the types of those parameters, as well as the required and optional query parameters and their types... it's pretty rich and pretty nifty.

But the really nifty part is that I had a moment of insight one day and realized I could hardcode a mock resource into the router that ran the resource map through an XSL transformer and returned a pretty (or at least, legible) HTML page that documents the system. Every URI, every parameter, all right there.

And — and this is the important bit — nobody ever has to worry about updating this documentation. It's automatically derived from the actual implementation of the system; to add something new to the system, you need to add it to the resource map, and bam, there it is in the help page.

This sort of implementation-derived documentation is the primary advantage that strong, static typing has over more dynamic approaches. IntelliSense for a more dynamic language means your either execute the code as it's being typed and use real-time introspection (as proposed by Steve Yegge in a talk at Stanford — and probably other places, but that the first time I saw it in print) or you start trying to layer a more static type system on top of them. Either way has its problems. Running the code so you can IntelliSense it has sandboxing problems, particularly if you're doing anything that's concurrent or distributed, and laying a static type system on top of a dynamic type system is kind of an advanced, compiler-powered form of missing the point, if you ask me. I have a lot of vaguely-connected thoughts on that last point that I should probably bundle together at some point. The Readers' Digest version is that adding classes to JavaScript is like adding wheels to a unicycle, in that your 'addition' has the unavoidable side effect of squashing what made the original unique. But that's a rant for another day.

Languages like C#, C++, and Java don't have those problems when it comes to rich syntax acting as embedded documentation. It's still not easy, but it's a well-studied problem, and there's existing code you can point to and say "here, here's where that feature goes!".

And it is happening, albeit slowly.

Generics in Java are widely (and correctly) criticized for not being integrated into the VM the way .NET 2.0 generics are, but on the other hand they do serve as a form of compiler-checked documentation; this ArrayList is of Marklars, and that ArrayList is of Widgets. The compiler will force me to keep those types distinct, and I can look a method signature and know what it expects. Yes, it's really just an annotation for the programmer and the compiler and doesn't actually change the generated code, but in a sense that's exactly the point — const in C++ doesn't change the generated code either most of the time, it's just letting programmers express both constraints and intent in a richer and more robust fashion.

Critics of static typing frequently argue that it provides a false sense of security, and they're right to an extent. But that doesn't mean that static typing is bad, it simply means that static typing is insufficient. Choosing between compiler-powered semantic tests and human-written unit tests is akin to choosing between seat belts and airbags — the correct choice, anticlimactic though it may seem, is both.

So what's my point? Good languages let me do more than just write code, they let me codify what I expect my code to do and how I expect other code to call it. It lets me express in a simple and clear form every assumption I'm making, and then it explicitly checks my assumptions with all the thoroughness it can muster. That's important today for writing good code, and it's only going to get more important.

Imagine syntax-level support for concurrency.

There are methods in the next version of iClan that are designed to only be called on the main thread; any time I want to activate them from elsewhere I call performSelectorOnMainThread:withObject:waitUntilDone: (boy that's a mouthful). If Objective-C had syntax for concurrency, I could mark my methods as 'mainthreadonly', and the compiler could stop me from calling them from elsewhere. Or better yet, the compiler could note from the headers that the UI-related methods I'm calling in those methods are mainthreadonly, and from that deduce which of my methods must be mainthreadonly, and either warn me for not labeling them or just cascade the analysis all the way up the call graph.

Similar story: I recently built a lockless queue in C#; it's built around Eric Lippert's immutable queue code, and it uses Interlocked.CompareExchange to swap a new immutable value for the old immutable value (Or rather, it repeatedly tries to make that swap, regenerating a new new immutable queue from the new old immutable queue if it fails... It's fun code, I should write about it someday — it turns out not to be terribly useful, but fun nonetheless.). The exercise would've been a lot easier on a lot of levels if C# gave the const keyword all the magic powers it has in C++.

You'll notice both of those examples have a concurrency angle, and that's not a coincidence. All of the self-anointed experts agree that the age of concurrency is upon us, and for a change the experts who aren't self-anointed and are too smart and humble to actually call themselves experts and the nobodies like myself seem to be in pretty general agreement with them. And the thing about concurrency and distributed system is, well, they're hard. Maybe not hard like NP-hard hard, but still pretty bloody difficult. And the more the compiler and the runtime and the VM and the OS can do to check our work for us, the better.

The example Graham cites in the appendix is a function for generating accumulators:

(defun foo (n)
  (lambda (i) (incf n i)))

For those of me who always find reading Lisp akin to reading the opening chapters of the Bible (but with parentheses standing in for the voluminous 'begats'), he also helpfully provides equivalents in a few other languages, such as JavaScript:

function foo(n) { 
  return function (i) { 
		   return n += i } }

An accumulator is a function that maintains internal state; when you invoke it with a new value it adds that value to its internal state and returns the new sum. An example usage would be to initialize it to zero and invoke it with each value in an array of integers; the result of the final invocation would be the sum of the integers -- or rather, the accumulation of the values.

For instance:

var myAcc = foo(0); // Initialize to zero
myAcc(1); // 0 + 1 = 1
myAcc(10); // 0 + 1 + 10 = 11
myAcc(44); // 0 + 1 + 10 + 44 = 55

So, can we build that in C#? The answer is an enthusiastic 'kinda'!

[TestFixture]
public class AccumulatorTest
{
	private delegate int Accumulator(int inc);

	private static Accumulator MakeAccumulator(int start)
	{
		int n = start;

		return delegate(int inc)
		{
			n = n + inc;
			return n;
		};
	}

	[Test]
	public void TestAccumulator()
	{
		Accumulator acc = MakeAccumulator(0);

		Assert.AreEqual(0 + 0, acc(0));
		Assert.AreEqual(0 + 0 + 1, acc(1));
		Assert.AreEqual(0 + 0 + 1 + 10, acc(10));
		Assert.AreEqual(0 + 0 + 1 + 10 + 44, acc(44));
	}
}

It's not actually that long -- the TestAccumulator function at the bottom is a quickie NUnit test case to verify it's doing what I think it should. It's still longer than the Lisp or JavaScript version though.

But there's one other major difference from those versions -- typing. The C# version only works on integers, whereas the Lisp and JavaScript version will work on anything that can be added. But if we try to genericize the C# code we'll run into problems at the n = n + inc statement, because you can't add two objects and thus can't add two generic objects without a generic constraint guaranteeing you can. And since there's no IAddable interface that integers and floats and strings and everything implement (and since C# still doesn't have a more generalized form of where clause that would let us specify constraints as duck types rather than static types), we're basically SOL with a generic C# accumulator.

Or are we? (Bum-bum-BUM!)

What if we passed our MakeAccumulator function two parameters: a starting value, and a delegate function to use for incrementing?

[TestFixture]
public class AccumulatorTest
{
	private delegate T Accumulator<T>(T inc);

	private delegate T AccumulationDelegate<T>(T a, T b);

	private static Accumulator<T> MakeAccumulator<T>(T start, AccumulationDelegate<T> accumulationDelegate)
	{
		T n = start;

		return delegate(T inc)
		{
			n = accumulationDelegate(n, inc);
			return n;
		};
	}

	[Test]
	public void TestIntAccumulator()
	{
		Accumulator<int> acc = MakeAccumulator(0, delegate(int a, int b) { return a + b; });

		Assert.AreEqual(0 + 0, acc(0));
		Assert.AreEqual(0 + 0 + 1, acc(1));
		Assert.AreEqual(0 + 0 + 1 + 10, acc(10));
		Assert.AreEqual(0 + 0 + 1 + 10 + 44, acc(44));
	}

	[Test]
	public void TestFloatAccumulator()
	{
		Accumulator<float> acc = MakeAccumulator((float)0, delegate(float a, float b) { return a + b; });

		Assert.AreEqual(0 + 0, acc(0));
		Assert.AreEqual(0 + 0 + 1, acc(1));
		Assert.AreEqual(0 + 0 + 1 + 10, acc(10));
		Assert.AreEqual(0 + 0 + 1 + 10 + 44, acc(44));
	}

	[Test]
	public void TestStringAccumulator()
	{
		Accumulator<string> acc = MakeAccumulator("", delegate(string a, string b) { return a + b; });

		Assert.AreEqual("" + "", acc(""));
		Assert.AreEqual("" + "" + "marklar", acc("marklar"));
		Assert.AreEqual("" + "" + "marklar" + "smurf", acc("smurf"));
		Assert.AreEqual("" + "" + "marklar" + "smurf" + "foo", acc("foo"));
	}
}

Yay!

So what is it good for? Absolutely nothing! But it sure was fun!

1. Ask the caller whether he or she currently owns a product.
   1. If the caller says 'yes', go to step 2.
   2. If the caller says 'no', go to step 5.
2. Ask the caller what is wrong with the product.
   1. If the caller says 'it will not turn on', go to step 3.
   2. If the caller says 'it will not turn off', go to step 4.
3. Tell the caller how to turn the product on. Hang up.
4. Tell the caller how to turn the product off. Hang up.
5. Tell the caller where to buy the product. Hang up.