Fascinating writeup! I enjoy it when a writer thoroughly details an entire thought process like this, instead of just focusing on the end result. This is precisely the type of content that belongs on the HN front page.
This is also one of the first articles I've seen on hn in a while that had a decent number of comments, all of which were fairly positive and/or insightful.
"On the other hand, the equivalent imperative code is stupidly hard to get right because you end up mixing everything together in a big jumble. (I spent my time doing other things while the computer did the tedious work.)"
The PL geek in me really likes this nice demonstration of the power of higher order functions, as opposed to C-style for loops, when it comes to getting things done.
I generally program on the Linux platform and use Ruby, Java, a bit of Perl and occasionally C++. In one previous job however, I did Windows development in C#. Whenever I tell people that C# is a seriously awesome language they look at me like I'm crazy; but its true. In many ways Java is still years and years behind C# for a general purpose OO language. It is really a shame that (outside of Mono), C# is trapped over in Windows land.
LINQ is incredibly awesome, expressive, and powerful. I generally prefer the lambda syntax to the more verbal syntax the author has used here, but both are really great and miles ahead of what's available in other, similar languages.
I vaguely remember LINQ from when I had a real job, but this is way cooler. I just remembered it as chained function calls on a database query return (you could do your filtering in C# instead of in the SQL) but this just looks like SQL (or better - python) in C#.
LINQ comes in many flavours e.g. LINQ to XML, LINQ to Objects. You're talking about LINQ to SQL. The chained function calls are equivalent to the more SQL-style LINQ, it's a matter of personal preference and which sits better given the context. Personally I always prefer the chained methods with lambdas.
However don't let the seemingly chained methods fool you! The great thing about LINQ is that is defers execution, by building an expression tree [1], meaning the code is lazily executed only when needed. And the expression tree means that everything (filtering, projection etc) is done in a single for loop [2]. e.g.
var results = collection.Select(item => item.Foo).Where(foo => foo < 3);
This builds an expression tree, but no work has been undertaken on our collection. When we attempt to enumerate the results, the expression tree is converted to code (again, as a single for loop, not multiple iterations as the code might seem):
results.ToList();
It's extremely cool to work with and highly expressive. One of my favourite features of C#
The syntax in the article desugars to the method calls you remember (which are the common HOFs). Since the calls are lazy, they can also generate SQL when asked to execute.
LINQ exists, to some degree, in the list comprehensions of Python and to a large degree in the for-comprehensions of Scala and many of the Monads of Haskell.
The monadic interfaces can get much more powerful, such as the Logic Monad in Haskell which embeds Prolog-like search.
Seriously impressive write-up! I love it, and really want to have a go at doing something like this myself. Where's the best place to start? I know a _tiny_ bit about hashing functions, enough to know not to ever write one myself... ;)
This was really interesting to read, it also made me somewhat nostalgic since I started programming "seriously" thanks to JASS, reading obfuscated JASS code from DotA maps to answer questions in the official forums helped me make many great friends, get a moderator position and collaborating in beta-testing, great experience for my young years :).
