Interview: Erik Meijer on LINQ

In this interview made during QCon SF 2008, Erik Meijer talks about less known LINQ features, like the ability to do meta programming or the fact that LINQ works against any data collection that implements the sequence operators. Meijer also talks about the differences between functional languages and objectual ones, asynchronous computation, and the evolution of languages.

Meijer covers many topics from a look to the impact LINQ has had over the short time since its release to the future of programming as foreseen in parallel and asynchronous programming. He thinks that LINQ has not had a full impact yet because it is mostly perceived as a way to access a database without considering its meta programming capabilities and the fact that one can work basically with any type collections.

Miejer talks a lot about functional programming and objectual one, highlighting the benefits brought by both and the need for constant evolution. He shows how languages can borrow from one another resulting in improvements on both sides.

On the topic of asynchronous and parallel computation, Meijer thinks that we have just scratched the surface and there is no clear solution right now. They involve a fundamentally different approach to programming, and while a few steps have been made in the right direction, more are to be made.

As a C# programmer, I admit that all those features in C# 3.0 like lambdas, extension methods and LINQ are nice. But I would definitely like C# to be more Haskell-y.While what Erik Meijer says about "too much of" type inference is true, C# has a long way to go in that direction. Not only does C# conditional operator fail to infer the type if no type was provided, it also fails to infer it when it was explicitly provided in the signature of the method, or in the variable declaration.Yes, LINQ is extensible - but due to the nature of extension methods, it's not polymorphic most of the time. Waiting for extension interfaces...Yes, LINQ is "almost" monads, but one cannot define an IMonad interface due to the nature of C# generics, see the comments to this blog post for details: blogs.msdn.com/wesdyer/archive/2008/01/11/the-m....I find C# operator overloading mechanisms no less confusing than those of Haskell, but much less powerful.It is questionable if the non-local return operator mentioned in the talk is worth keeping - it's a goto statement in disguise and I've seen some programs entangled to something unrecognisable by all those return-s and continue-s.In fact, there is a design by contract framework for Haskell, it's the QuickCheck testing library - implemented as a library, not a language extension. The tests look like "prop_test args = precondition ==> postcondition" and they are kept separately from the main code, which is a good thing.Having said that, I'm not sure if it's easier to write a conventional business application in Haskell than in C#. I'd like to experiment with it but don't see a reasonable opportunity.

Definitely. And being able to make those lambda expressions generic would be nice. I sometimes use them as local functions but then I have to move them to a separate method. I guess all those things - generic variables and generic parameters - correspond to rank-2 polymorphism in Haskell somehow.

Reasons why nobody is ever going to care about Monads in C#
by
Stefan Wenig

1) It's all but impossible to learn Monads using C#. You'd have to learn them in an FP language and then move that knowledge to C#. That's not going to happen for a whole lot of people.2) There are no good explanations. Eric Meijer used to have a paper on his MS Research page that got linked quite a bit, but it's no longer there. The article from Wes Dyer that Dmitry linked to got quoted a lot, but it doesn't even try to explain why anyone should use Monads. (The null propagation? If you get to the core of it, it checks all input parameters for null-ness and then either evaluates the whole select expression - or not. The arithmetic expression itself is not elevated. Quite a lot of noise there, not very impressive. Continuations? Same problem. Now in addition to Monads, I have to go somewhere else, find out what continuations are and what they are there for, come back and try to understand Wes's implementation, and think hard about how I could use LINQ to support real-world scenarios using continuations. Unlikely.)3) C#'s syntax is flawed. I like a lot about the way LINQ was integrated via new C# features. But the Func<> delegates kill me, especially when their arguments are generic too. I frequently find myself using some currying-like notation on paper when trying to read stuff like Wes' article.4) I don't know a lot about Monads, so I could have that wrong. But I believe that while LINQ is obviously an application of Monads, it just sucks for any amplification that is _not_ IEnumerable. It might be fun to try and use it anyway, but only while you're busy playing with Monads. Who want's to see this in production code?

I might be wrong, maybe someone comes up with a great paper that shows how to implement some parser using Monads in C# in a way that really makes sense, or something like that. But LINQ has been around for some time, Eric has written and preached his stuff, explained how LINQ is just Monads to the Lambda-the-Ultimate crowd, and nothing happened. Why should that suddenly change?<>

Re: Reasons why nobody is ever going to care about Monads in C#
by
Dmitry Tsygankov

4) for any amplification that is _not_ IEnumerable.

Actually, there are some problems even for IEnumerable. I stumbled into one of those today.In LINQ framework, there are some 22 independent implementations of IEnumerable.Min extension method, and the same for .Max, .Sum, etc.If I have my own number-like class with some operations of addition and negation, I don't get the two overloads of .Sum for free. Instead, I have to implement them by my own, which is a bit annoying and in my case it probably makes the whole idea pointless.Now, suppose I'd like to fix that, so that I have one implementation of .Sum I can always use. I could do something like this: public static T Sum<T>(this IEnumerable<T> sequence) where T : IAdditive<T> { return sequence.Aggregate((left, right) => left.Plus(right)); }Is that an adequate replacement for IEnumerable<int>.Sum? No, it's not. It doesn't behave the same way for empty sequences. If I want it to behave reasonably, I'll have to fetch the zero value somehow and return it in case of an empty sequence. The problem is I cannot do that! The default(T) gives me null, which is not what I want. What I would like to have is something like zero(T), that is, I'd like to have a method that is polymorphic in it's return type. But I can't do that in C#! C# only allows me to have polymorphism of this kind on the first parameter of the method.The same thing happens with methods like long.Parse, int.Parse, decimal.Parse, etc. A colleague of mine tried to create a generic Parse method a few days ago, it all ended up with "if (typeof(T) == typeof(int))" etc.It's not a big deal, one can always fall back to code duplication and if-else, but those little traps are everywhere!Now I have no right to tell anybody that Haskell is the best language in the world for all possible tasks, but the Read and Num type classes are definitely better than what I described here.While what Stefan said about syntax and tutorials is definitely true, those problems are not fundamental and can be easily resolved, but a few more fundamental problems exist.</int></t></t></t>

Re: Reasons why nobody is ever going to care about Monads in C#
by
Stefan Wenig

Dmitry,

some of those problems _could_ be resolved. But this stuff has been here for quite some time now, and nobody seemed to care. Why should that suddenly change?

Other problems are fundamental. The syntax is so hard to understand that it's actually easier to learn a bit of Haskell in order to get monads than to use your existing C# knowledge. At least that's my opinion, and I've tried it both ways. It's not just the Func<> syntax, it's also the strange SelectMany overload you need to transform if you want to use LINQ statements like Haskell's "do" and a few other details.

On the other hand, the lack of an IAdditive interface or polymorphic return types in C#/.NET is not a weakness of IEnumerable. You could just as well complain about any other feature, but it does not stand in the way of using monads in C#.

For the Aggregate function, you could supply a seed of "new T()", which would probably do the same as zero(T) anyway.<>

But LINQ has been around for some time, Eric has written and preached his stuff, explained how LINQ is just Monads to the Lambda-the-Ultimate crowd, and nothing happened. Why should that suddenly change?

Functional programming is still very new to a lot of people, so you are going to see a lot more about what they are than how they are useful. That's always the case. However, I've started using continuations and am looking at the state monad for some real applications. They are terrific for parallel/async programming models. If you aren't doing async, then you probably won't see a benefit. As more move to that model, though, you'll see a lot more about applications of monads, I guarantee.

Also, the Reactive Framework (IObservable/IObserver) is coming out and works using the continuation monad (or something very close). See more here.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.