LINQ and Learning to Be Declarative

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 like to return IEnumerable instead of List:

    IEnumerable GetExclusiveProducts(List 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.

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.