I would say that both LINQ and lambas are amazing on their own (and even better together). Both of these completely change how you write code and makes it much more compact and readable

I feel a little disappointed by LINQ. On the one hand, it is an awesome feature. On the other, I feel there is a more general theory of what LINQ does that could have been integrated into the language core, and then it wouldn't be necessary.

In other words, LINQ should have been a library, not a language feature. (In my ideal world. It is possible that someone with better info could see such a move as a terrible mistake.)

AFAIK LINQ pretty much is a library since its just extension methods, in itself I don't there's any other specific language feature needed to support it, is there something else you had in mind?

I do agree though that LINQ seems to hint at and start evolving C# into a different semi-functional kind of language, and what we're stuck now with is a language with one foot in both worlds. Hopeful another language will come along one day and chisel out those ideas into a more pure form. (and I'm not meaning a pure functional language like for instance F#)

I mean that it is basically a DSL with special syntax, and that it would be nice to be able to write such things in libraries (without needing it to be part of the C# spec.)

There is obviously a relationship between code like

    .Select(blah).From(blah).Where(blah)

and

    SELECT blah FROM blah WHERE blah,

and I think it would be worthwhile to look into a language feature that allowed a reliable translation between these kinds of things. Maybe I want to write

    LET a = blah IN blah

from

    .Let(a, blah).In(blah)

or some such thing. It it just syntactical sugar? Is it a pattern that can be abstracted well?

Well, each linq "operator" is just an extension method to the ienumerable interface that are chained together. So nothing prevents you from doing your own operators.

Most of the features that came along around the time of LINQ (var variables, extension methods, anonymous classes, lambdas etc) was done specifically to support the LINQ kinda syntax but LINQ in itself is not so much part of the language as it is of the .net libraries.

Btw, I personally think the "dot notation" syntax is superior to the "query expression". It's easy to follow from start of the line to the end and you get great autocompletion along the way.

Generally agree, but it depends a lot on the query. I find that join syntax especially is more readable in the query style.

I liked chaining expressions for things that were done in memory and query style for deferred. My brain handled the code a bit better when things were written that way.

F#'s not a pure functional language, it's a multi-paradigm language that has very good support for the .NET object model and imperative programming, even if it is "functional-first".

> AFAIK LINQ pretty much is a library since its just extension methods

No, that's flat-out wrong. LINQ's main feature is turning code into data: Put code in, get an expression tree out.

Hmm, perhaps it would work for LINQ to objects, where the LINQ statement just becomes a delegate that is executed at runtime. I can't see how it would work for LINQ to anything else (SQL etc..), where the compiler only emits an Expression which is then consumed to generate SQL/Amazon queries/whatever.

Can always write your own query provider :)

Yes, but someone needs to create an expression out of the LINQ statement, so that the query provider can do its job.

I suppose it is possible to build expressions with just libraries, but that would be very ugly (like control flow in XML) :)

Fair enough.