Oy vey, LINQ. Meshuggeneh. Nothing like dropping COMPLETELY out of your language's idiom for a line or two to implement some Enumerable-like behavior.

It is interesting that this kind of context switch for some programmers is a breath of fresh air, and for others its a horrible hack.

I think the fact this is not an objectively good or bad thing has led to a lot of the tension we see in other aspects of programming.

I think a connected issue is tooling: if you presume a certain floor on tooling, more 'advanced' things like multiple composed domain languages become much more feasible since the tooling can remove the need for memorization and help guide construction without fear of errors. But if you presume all tooling beyond text editing should be regarded as non-essential at best and superfluous at worst, it greatly constrains the set of things in programming one can consider sane or not. I do wish we had more projects experimenting + getting traction with "high tooling, high abstractions, high domain mixing" so we could get more literacy around these methods, but I think the vast majority of programmers today have abandoned these kinds of ideas as good or worthy of further development. On pure interia alone, I long ago capitulated to the idea we will be stuck in text editors and having heated debates over typographical syntax for programming languages for the foreseeable future.

People working on things like LINQ and more advanced domain mixing like MPL or (where I once worked) Intentional Software run up against lots of resistance from people I think probably due to some fundamental differences in assumptions, but I'm not really sure what the deepest differences are.

I'd argue when I'm writing C# in a web-development setting (ASP APIs etc.) that a large majority of the code is LINQ. Especially if using something like Entity Framework. It's really just part of the language now.

A line of LINQ looks and works nothing like a line of C#, and the difference is even worse in VB. Whether it's "part of the language" or not, it's a fundamentally different way of writing logic than the base language you're writing around it. I agree it's completely coupled with EF, but I hate EF too. (After you've used ActiveRecord for over 10 years, any other ORM just feels like a ball and chain, but that's another topic.)

> A line of LINQ looks and works nothing like a line of C#

Maybe if you're using the query form, but if you're using the method form, I'd argue that they work together very nicely.

For me, at least, I've found embracing Lambda expressions to be very helpful in a number of cases, between Linq, or writing my own code for doing things like rendering tables (long story there).

Granted, I learned C# right after LINQ was released, but I'd still argue that LINQ is well worth having around.

I came from a Rails background and it was definitely painful to learn EF since it has a lot of nuances and things you wouldn't know without experience (e.g. How things mutate throughout the object lifecycle, migration funkiness, how tracking works and 'AsNoTracking()' etc.)

Think I'd still prefer ActiveRecord really but after you get used to EF (Core) it's still a good tool.

Are you using the query syntax instead of the method syntax? Because the method syntax is completely in line with normal OO code (it's just a bunch of chained methods). I'll agree that the query syntax is weird, but I haven't seen it used much.

Are you talking about the `from x in y select x.z` syntax or the `y.Select(x => x.z)` syntax? Because the latter is the one I most commonly see, and it fits in fine with the rest of the language.

Out of idiom? Extension methods, the way LINQ is implemented, has been introduced in C# 3