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.

LINQ and how generic implementations can lead to so much more

I don’t know what the original remit of the design for LINQ in C# was, but my impression is that the aim was to be able to make SQL style queries on data sets directly in the code. Now, the implementation of this bit of it is much like many other SQL 4th generation language addons, in that at compile time, the query text is parsed and converted into some library calls that actually do the query at runtime.

However, this is where the similarities end, because with the implementation of LINQ the underlying query system was added directly onto the standard container classes of the .Net Framework. So instead of having a specific system for querying for data matching a given constraint and iterating through it, such as an SQL select with a cursor, the designers realised that you could achieve this using a generic IEnumerable with a selection constraint attached.

The result of this idea, means that you can now use LINQ to filter any data that is stored in a generic collection class.

When I first learnt about LINQ, I couldn’t see why you would want to use it for this job though, after all it looks like all you are doing is writing the same code in a slightly different way.

A piece of code for extracting all of the values greater than 1, from a data set would look like this:

List<float> upperVals = new List<float>();

foreach (float f in inputData)
{
    if (f > 1.0f) {
        upperVals.Add(f);
    }
}

and using LINQ it would look like this:

var upperVals = from val in inputData where val > 1.0f select val;

However, it wasn’t until I read this blog and started to think about things more that I realised the true benefit of the LINQ way of doing it.

Firstly, the code makes it much clear to see what it is trying to do, but I think that this is the secondary win. The main benefit is that the LINQ version doesn’t actually make a second copy of the data all it does is build an IEnumerable that is a filter on the original data. This means that you save memory in not copying out the filtered data and in many cases, especially for large data sets, also save CPU as the results are only lazily collected.

Needless to say, I’ve recently been changing code to use LINQ when it didn’t previously.

The start of something new

.. well maybe.

I have decided that it is time to start blogging. Mainly, my aim is to blog about software engineering, but not in too greater detail, just cool stuff that I bump into or grumblings about things. There are far too many other people out there writing huge chunks of text talking about seemingly obvious stuff to make me know that I don’t want to write pages of stuff about nothing.

A long the way, hopefully, I’ll also throw in the odd post about cycling and rock climbing. As a result this blog is almost certainly going to appeal to nobody Smile

Follow

Get every new post delivered to your Inbox.