Like pink is the new black right?
When I started programming I was luck enough to jump right into the C# world riding the LINQ horse. The first time I foreach’d over an IEnumerable using a .Where() statement was pure heaven coming from a PHP and classic ASP world. No more {} nesting craziness for me. The code was just easier to write in that style.
The impact that LINQ and its Extension Methods had was not truly realized until I came back to that first code projects months later after focusing on an entirely different domain. Because I was ( and still am ) a relative newbie to the object oriented and professional programming world I didn’t comment my code well. The results where typical, I had no idea why I did what I did and lots of implementation details where lost.
Yet when I came upon my LINQ statements the codes meaning was immediately clear to me. I knew what I wanted to do with my collections and was able to infer why I did them because the LINQ preserved some of the more declarative meaning about what I was doing. LINQ created a DSL right inside of my application that didn’t need much further commenting. On top of it all the code using LINQ rarely had to change when I had to shuffle some bits around. Replacing one property with another inside of a lambda is so much neater than tracing through the nested if blocks of the C# 2.0 world.
It was at this moment I realized the importance of readable code. LINQ offers that benefit and I decided I should use it wherever possible.
Almost a year later I now came upon a problem for a new project I’m hacking away at in my free time; Georum, a geographically aware message board application. This led to my Thanksgiving weekend being wasted researching IQueryable because my only solution to my problem was to implement my own IQueryable provider. And like white on rice, Expression Trees also entered the picture.
During the next week at work I had another revelation while working on a piece of messaging functionality; I was trying to solve an architectural problem when the true problem was more of a composability one. Once I realized my true goal was to create code that others and myself could more easily use a solution using Expression Trees just fell into my lap and because of them, no functionality has to be sacrificed.
Expression Trees offer a kind of dynamic hook into execution that used to be the sole domain of Reflection, or if you were truly brave, custom IL output. The research this blogger did indicates there is a 600% improvement over reflection based code using Expression Trees.
Expression Trees have already been used in a couple of interesting ways in DI and Mocking frameworks but haven’t really made their way into a lot of mundane code examples at this point and I don’t understand why.
Yes, parsing over expressions is a little harder than just calling normal code but I think they offer a tremendous opportunity for us to create composable, self-documenting, and intellisensed dynamic code. It’s my prediction that Expression Trees will eventually completely change how we work with C# in the long term future just like LINQ changed how we work with collections.
In this series of posts titled “Expression Trees are the new Magic Strings” I’m going to write out my discoveries surrounding Expression Trees, explore some interesting implementations using them, and also eventually offer my own.
My goal is to reproduce that “aha!” moment when we all first used a IEnumerable<T> extension method or when we hooked into a database using the same syntax. Using Expression Trees is going to increase the readability of our code and offer a lot of functionality that was previously restricted to badly performing but easy to write reflection and well performing and hard to write IL generation.
*Why doesn’t Composability show up in the spellchecker?
