Getting into the sugar of a language’s syntax
I have never been one to study the theory side of computer science and certainly not language design, so when I first heard people talking about a language needing to support closures I didn’t really know what they were talking about.
When I later learned what they were and that most decent scripting languages had them, I couldn’t see what the fuss was about. It just looked like another way to obfuscate your code.
Now, until last year, I had spent pretty much my whole software career writing in C++ and so these things were pretty irrelevant, because C++ didn’t support them anyway. It doesn’t need to. No language does. What they provide isn’t anything that you couldn’t do in a slightly more long winded but clearer to follow way.
Last year, when I read that they were being added to C++ in the C++0x specification I started to understand more about what they might be used for, but still didn’t really understand why people were getting so excited about it. Literally claiming that they could now achieve things that were previously possible. I never, really understand people like this anyway, why not learn to use the tools that you have instead of inventing ways that you want to work with tools that you don’t have.
Anyway, to get to the point, this year I have finally started using C# properly and recently find my self using closures all over the place.
It doesn’t really make the code any harder to follow, but it does make it much easier to write.
A good example of this is, is when calling asynchronous code, such as:
WebRequest req = HttpWebRequest.Create("http://www.example.com/"); req.BeginGetResponse((res) => { try { WebResponse res = req.EndGetResponse(); SaveFile(res, localFile); } catch (WebException we) { // .... } }, null);
The alternative version, without closures would be something like:
WebRequest req = HttpWebRequest.Create("http://www.example.com/"); req.BeginGetResponse(HandleResponse, new RequestState(req, localFile)); void HandleResponse(IAsyncResult res) { RequestState state = (RequestState)(res.AsyncState); try { WebResponse res = state.Request.EndGetResponse(); SaveFile(res, state.LocalFile); } catch (WebException we) { // .... } } class RequestState { public WebRequest Request {get; set; } public string LocalFile { get; set; } public RequestState(WebRequest r, sting localFile) { Request = r; LocalFile = localFile; } }
Now, obviously this second version would be fine if it was used in more than one place or RequestState could sensibly provide more functionality, so it could become a class that had a real reason for existing, but you don’t want to have to do this every time you need to provide a callback.
So, I finally understand the need for this type of language feature, not because it is essential, but because it makes life so much simpler, when you just want to get the job done. I now look back at languages like C++ and hope that I don’t have to go back to using them again, because things can be such a struggle doing them then 1990’s way instead of the 2010 way.


