Your documentation appears to be a bit broken. When I try to click on pipes I get a 404. Just to let you know.

I'm largely with you on this... I prefer the extension methods myself most of the time.

Also adjacently worth mentioning that I tend to use Dapper instead of EF, so there's even less use of this type of expression all around unless it's actual SQL or assembled SQL via a query builder.

There are some things that are harder to write in extension methods too. Such as `let` declarations. Or multiple from clauses referencing iterating variables from multiple levels. I use both.

Never understood why a lot of programmers are so obsessed with reducing lines of code at the expense of all else.

What's important to me is that I can understand the intent of the code, that I can reason about how that code will be executed at runtime, and that I can easily debug the code if needed.

Of course, there's no need to go full enterprise Java. Never go full enterprise Java.

But having ten lines of clear code that's easily debuggable and which runtime characteristics is predictable is much better than one dense line that's difficult to untangle, or a few that's hard to predict what will do etc.

You can format it on one line if you want. Please don't do that, though. Personally I prefer the method syntax with one method per line, it reads more linear than the query syntax.

Over all, peoples prefer writing with lambda, somes use the SQL-like, but there is a major preference towards lambdas.

C# isn't unique in that, and it also doesn't offer the tools required to help avoid having to dip into procedural code.

Here's things Clojure, for example, offers:

1. Structural sharing which makes you less likely to have to dig in to procedural code.

2. The transient function which takes an immutable data structure and makes it... not immutable... you can now do your procedural code, then switch back into immutability land with persistent!.

3. If the above fails, you can dip into Java.

So yeah, I vehemently disagree with C# being the best. I could kinda see it if you said F# (type safety), but C# itself? Uhhh.

There are a lot of patterns you get when you can be 100% certain of something. For certain functional languages, you could actually safely assume immutable patterns and such.

I really love C# but I will also say that 100% purity is a super power that C# will never have (can't have 'em all).

> 100% purity down the entire vertical is a very strong anti-pattern.

It really isn't. The benefit of pure all the way down is that later you can replace bits with something more performant if necessary. But starting out with the idea that some bits should never be pure just means none of it is. The beauty of pure functional programming is that its very compositional nature means that you can replace a component without having a detrimental effect to everything its composed with: as long as you maintain referential transparency for that component.

What we gain from imposing the pure functional constraints on ourselves is genuine composition. If we compose two pure functions into a new function, that resulting function will also be pure. This is the pure functional programming super power that leads to fewer bugs, easier refactoring, easier optimisation, faster feature addition, improved code clarity, parallelisation for free, and reduced cognitive load. Opting out for arbitrary reasons at certain stages of the vertical threatens all of that.

Thanks for the heads up, must've slipped my mind. Edit: fixed

> This is a very unfortunate joke: Python has list (and generator) comprehension expression for a long time (2.3?) which are similar to LINQ.

I love Python, its my main daily driver, both at work and by preference for most of my personal coding, but Python comprehensions and genexps are much more limited than LINQ language level query syntax (Scala’s visually-similar construct is more like LINQ in capabilities) and Python—purely because of core and stdlib convention which also drive convention for the ecosystem, not actual structural features—lacks anything like the method syntax as a common API (unlike, say, Ruby).

EDIT: Thinking about it a little bit, though, it should be possible in theory to implement LINQ in Python without language level changes (including providing something close to but not quite as clean as the language level query syntax[0]) as a library via creative use of inspect.getsource and ast.parse, both for providing the query syntax and for building the underlying expression tree functionality around which providers are built (support for future python versions would require implementing translation layers for the ASTs and rejecting unsupported new constructs). Conceptually, this is similar to how a lot of embedded DSLs in Python for numeric JIT, compiling GPU kernels, etc., from (subsets of) normal Python coded are done.

[0] existing comprehension/genexp syntax looks similar, but relies on simple iteration, not pushing code execution out to a provider which may be doing something very different behind the scenes, like mapping "if..." clauses into SQL WHERE clauses for a database query.

List comprehension is pretty good, but I prefer LINQ method-style because it's executed left-to-right, whereas I keep having to look up the order of Python.

Why?

Writing your own LINQ provider is a very niche activity done by people who want to translate or “transpile” C# expression trees into something else.

It is fundamentally a difficult endeavor because you’re trying to construct a mapping between two languages AND you’re trying to do it in a way that produces efficient target code/query AND you’re trying to do that in a way that has reasonable runtime efficiency.

Granted, on top of that, I’m sure LINQ provider SDKs probably add their own complexity, but this isn’t an activity that C# developers typically encourage.

Not a horror story. I like how marten worked with postgres and wanted something similar for sqlite, so I made a library that stores data as json, and translates linq to sql using json query functions. It wasn't very fast, but it was fun experience. For next attempt (once I have more time) I will probably include source generators to precompile queries and skip if not all, then most translation at runtime.

Agreed. That's how I would write it in a professional codebase. I added it to show the transformation from separate functions -> LINQ one-liner. Cheers!

You worked in a C# shop and never wrote LINQ? How is that possible? That's like driving a manual car and never shifting out of first gear.

It really depends. IEnumerable could have a lambda that leaks the world and makes a web call on every iteration for all the caller knows. You know iterating a List will be fairly banal.

So from an API perspective, I think returning IEnumerables can end up being too cute. The caller has to deal with this unknown thing.

In general you should be clear about what you return and loose about what you accept. If your whole API is returning IEnumerables and some are expensive to iterate and others are not its actually less clear what I'm getting. And this isn't to say List is always the answer either.

The only problem with IEnumerable's open-endedness is that it's so open-ended. It makes no implicit guarantees about order, finiteness, side effects, speed/efficiency, idempotency etc. It's easy to assume those things until you accidentally find a situation where one or more are not in your favor.

This is generally better yes, especially if it's going to end up inside another LINQ operation - you can avoid materializing the list.

Cases where it isn't:

- risk of multiple execution (there is a CA warning for this)

- when returning data protected by a mutex, you should always materialize a copy of the returned list/array rather than return an enumerable

Given the use case I’d consider IGrouping<PhoneType,Product>. My point being LINQ is a wide subject and most code I see barely touches the surface.

I only have ever used LINQ in the context of enterprise. What are your thoughts on using it in game dev?

Are you saying that you’re unable to read a fluent syntax that’s been supported by most mainstream programming languages for the past 10 years?

Or are you suggesting that the majority of programmers struggle to read and understand fluent method chaining?

I don’t have a dog in this fight because this blog post is very novice oriented. I’m just genuinely confused why you think it’s unreadable or “clunky”. What is it about the fluent example that you find clunky?

Can you show me how you would write it? I don't see how this contributes to the conversation unless you show me how or why

These patterns are commonplace for many years now in many languages.

The intention was to show how declarative code can come from imperative with a 'true' one-liner.