> Functional programming isn’t an afterthought in C#, it’s effective and you should learn it if you haven’t already.

I think C# is the best functional programming language because you always have access to a procedural code safety valve if the situation calls for it.

100% purity down the entire vertical is a very strong anti-pattern. You want to focus on putting the functional code where it is most likely to be wrong or cause trouble (your business logic). Worrying about making the underlying infrastructure functional is where I start to zone out.

Does F# care if a DLL it references was coded in a functional style?

If you're going to write code snippets, please make sure they compile!

The final example has signature List<Product> but tries to return IOrderedEnumerable<Product>.

I recognise that this is very much a taster rather than even a full introduction, so the author didn't want to explain IOrderedEnumerable<T>, but please when writing blogs, run through your code examples and make sure they compile.

This means that your audience can follow along.

( It just needs a .ToList() on the end. )

Fwiw in the final iteration I would still place each clause on a seperate line aligned by their leading '.' because I find it much easier to scan.

I think the future of programming will be mostly declarative and parametric since most professional software is redundant.

The second SQL-like version is far more readable. There is just less "syntax noise" and it's far more "declarative" by definition.

The author stating that the lambda is "better" because it's less lines is also silly. It's been a while since I've written C#, but pretty sure the SQL-like version can be formatted to a single line as well:

List<Product> GetExclusiveProducts(List<Product> source) => (from p in source where p.ProductTitle == "iPhone" orderby p.TypeOfPhone select p).ToList();

I'm the author of language-ext [1] a pure functional framework for C# and have been pushing the declarative programming thing in C# for over decade. C# is a great language for declarative programming and LINQ is awesome. You need to constrain yourself (and your team) so you don't fall into bad habits, but it can really pay dividends in terms of code stability/maintainability.

I have a couple of samples that I think might surprise you if you think C# must look like Java...

* A game of pontoon [2] - I create a Game monad which is an alias for a monad-transformer stack of StateT > OptionT > IO. This shows how terse you can get, where the code almost turns into a narrative.

* Newsletter sender [3] (which I use for my blog) [4] - This generalises over any monad as long as the trait requirements are met. This is about as declarative as you can get in C#. It's certainly pushing the language, but is still elegant (in my eyes anyway).

[1] https://github.com/louthy/language-ext

[2] https://github.com/louthy/language-ext/blob/main/Samples/Car...

[3] https://github.com/louthy/language-ext/blob/main/Samples/New...

[4] https://paullouth.com

I think the final version is far worse than the second version. This is simpler in what way ?

I like to return IEnumerable instead of List<>:

    IEnumerable<Product> GetExclusiveProducts(List<Product> source) =>
        source
            .Where(p => p.ProductTitle == "iPhone")
            .OrderBy(p => p.TypeOfPhone);

That way the user can decide if they want a List or Array or Set or whatever, and you can also add additional queries to this

Also better to pass IEnumerable to the function instead of List, for the same reasons

Also I forget the syntax but you can use an extension method to add it to linq I think

I love LINQ (the object method syntax not the keyword syntax) and used it extensively in a production application in ~2015-2017. It is easier in many cases to write and read than manual loops.

In performance-critical code at the time it had to be avoided due to allocations and poor performance compared to loop-based implementations.

However, the new versions of .NET have been reducing this penalty [1], to the point where it might make sense to try LINQ first if it's more concise/clear then only rewrite after profiling!

[1] https://devblogs.microsoft.com/dotnet/performance-improvemen...

"But what if I told you we could make it simpler"

... and then the author proceeds to presenting clunky, unreadable fluent syntax

That was a good joke for the afternoon.

I’m going to reserve a thread on this post for folks who want to share horror stories trying to implement their own LINQ providers.

The example with lambdas should be written on multiple lines, too. At the same time, you can leverage the => syntax to avoid braces and end up with five lines:

    List<Product> GetExclusiveProducts(List<Product> source)
      => source
        .Where(p => p.ProductTitle == "iPhone")
        .OrderBy(p => p.TypeOfPhone)
        .ToList();

(You could join the first two lines, but I think that’s ugly for multi-line expressions.)

Also, less lines is not a good argument for SQL-style syntax vs method-call syntax. The good argument is that the SQL-style syntax is limited to only a few basic operations, when there are many more useful methods available.

Another reason is that this does not compile:

    List<Product> GetExclusiveProducts(List<Product> source)
    {
      return from p in source
             where p.ProductTitle == "iPhone"
             orderby p.TypeOfPhone
             select p;
    }

This method returns IOrderedEnumerable<Product>, not a list. To fix it, you would need to either change the return type, or go outside of the SQL-style syntax and call the ToList method:

    return (from ... select p).ToList();

> Your coworkers and QA will thank you for learning LINQ and ditching the imperative methods that plague your Python brain.

This is a very unfortunate joke: Python has list (and generator) comprehension expression for a long time (2.3?) which are similar to LINQ. At some point in the history many languages stole useful expressions from other paradigms.

Let’s joke on BASIC, it always works.

> with a one-liner for the actual logic

Looking at that 'one-liner' I get strong perl vibes, or is it chills?..