Should you care about closures?

If you are a frequent reader of this blog and the comments associated with it, you have probably run across the concepts lambda calculus, closures, or anonymous functions. And if you strictly stay in the Microsoft ecosphere, you may have seen these terms suddenly springing up all over the place; the ideas are being talked about like they are the greatest thing since the CPU. C# 3.0 brought with it closures to C# (2.0 had anonymous functions), and Visual Basic 2008 is getting them as well. What exactly is the point, and why should you care?

The first thing to understand is that these are not new concepts. Lambda calculus has been around for about 70 years. Closures have been around in languages since Scheme in the 60s. C# 2.0, backwards as it may be, had anonymous functions (think of them as lightweight, limited purpose closures). Perl, Ruby, and even ECMAScript (more commonly known as JavaScript) have had this functionality forever. For a good overview of the history and technical details on these ideas, Wikipedia's article on closures seems to be accurate (even if it is a bit difficult to follow).

In the .Net world, C# and VB are really only getting closures because it is needed for LINQ. Microsoft may not come right out and say, "Gee, we left a really useful feature out until we decided we needed it to support the LINQ gimmick," but articles like the recent one about lambda expressions in MSDN Magazine make it clear that, without LINQ, it would be 10 more years before VB.Net or C# saw closures. Here's a quote: "To support LINQ queries, a few features needed to be added; among them were Visual Basic and lambda expressions." So there you have it.

Lambda expressions, closures, etc. are now big news. So what? They have always been around. It's time to start using them; with all of the recent buzz, you can't pretend you have not heard of them anymore.

One of the things that has continuously irked me about nearly every one of the recent discussions on the topic is the brainless parroting of the usefulness of closures. "Pass them as delegates to another function." Yawn. "Now your code looks so much better, define a function where it is used!" Ho hum. "Type inference!" Isn't static, strong typing a safety feature that most VB.Net and C# developers rely upon? C'mon folks. Let's get real. It sounds to me like what developers are really saying is, "Closures let you pretend you are using a dynamic scripting language inside of a strongly typed compiled language!" Well, it is true, but it is not the point.

What I really, really like closures for is the ability to use them to create Domain Specific Languages (DSLs). The other thing I really like closures for is their use in projects where you need to be able to late bind entire portions of functionality. Of course, those two concepts are nearly synonymous. What I mean is: Closures allow the programmer to work pure, blinding magic at runtime, where the functionality of the software can be defined post-compilation with no editing of the source code. This can come from configuration, a DSL (this can be as simple as code written in the same language as the program and lambda'ed or eval'ed at runtime to something as complex as a parser for a small, dynamic language), templating systems, and so on. Another interesting (albeit rare) usage of closures is in N-dimensional logic matrices.

These are just a few of my common usage items for closures. The stock list of examples and recent press sells closures short. So go ahead -- get your hands dirty and try them out. With the full support of them in C# 3.0 and VB.Net 2008, .Net developers have access to closures already (or in a few months, depending on their language preference). Sadly, for Java programmers, it appears that closures are still not part of Java. Hopefully, Java will meet parity soon. I recommend that, at the very least, you start looking at them and seeing how they can simplify your life down the road.