Two qualities that I like about software in general are simplicity and elegance. Unfortunately, most of today’s software is neither simple nor elegant. People generally argue that it’s impossible to write simple software when customers are asking for a lot of features and therefore for a lot of complexity. Of course they’re right, but they’re also wrong. Simplicity and complexity aren’t mutually exclusive; in fact, all complexity is built from simplicity. Think about CPUs for example. CPUs may be among the most complex devices ever conceived by humans, but at their core, they’re built from logic gates which are actually quite simple. The key to building complex systems that work is to found them on a small set of rules that are simple and elegant. I’m only just beginning to realize that, but so far, the experience has been great.

Some time ago, I was given the assignment to prepare a talk about LINQ, the language integrated query component of Microsoft’s .NET framework. In all honesty, I picked the assignment myself, not wanting to talk about some arbitrary XML framework which would have been the alternative. LINQ was something I had been interested in for a long time. It’s essentially a DSL for querying various data sources including RDBMS tables, XML documents and in-memory collections. What struck me about LINQ though was the fact that it isn’t so much a DSL but a library and if you step back even further, it’s actually more of a design pattern. LINQ was co-invented my Erik Meijer who is also heavily involved in the development of Haskell. Now I don’t know Haskell, but I know of it and I quickly realized that LINQ wasn’t much more than applying some of Haskell’s most interesting language concepts to C# and VisualBasic.NET. What I also realized was that LINQ at its core is just a clever way of composing functions and that gets me back to simplicity and elegance. If you look at LINQ from close up, you’ll see a bunch of magic and a lot of complexity. Take a step back and it all dissolves into simplicity, elegance and even beauty.

When I was preparing for my talk, I decided that I wanted to have a full understanding of how LINQ worked and so I finally came to the conclusion that the only way to get there was to implement it myself. What came then was a crazy two day frenzy. I forgot to eat, I forgot to sleep and when I tried to sleep, I couldn’t because of how excited I was. After those two days however, I had a complete and fully tested implementation of LINQ to Objects minus the expression compiler (I’ll get to that in a second). I gave the talk and despite the insomnia I felt very confident. Also, I felt like I had entered a different world (hi, my name is Kai and my drug is sleep-deprivation), seen the light or whatever you want to call it. I had seen the elegance and simplicity of LINQ and it was awesome.

Then came the realization that while the LINQ library by itself was a nice thing to have, writing queries with it was actually quite awkward (because of JavaScript’s verbose lambda expression syntax). So I decided to write a LINQ compiler that would translate LINQ-style queries into JavaScript code. I’m going to spare you the exact details of how that compiler was implemented, but it was both an enlightening and an exhausting experience. I finally got to do something with parser combinators which was great fun, but writing the actual compiler turned out to be quite tricky.

Anyway, my JavaScript implementation is now done, it is inappropriately named “JSINQ” and I’m sharing it with all of you in the hopes that you might find it useful. Let me know what you think, be sure to report any bugs you may encounter and of course: stay in school.