Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LINQ and Learning to Be Declarative

nickstambaugh.dev

Post reply on HN
Print view View original

41–50 of 60 posts

Re: LINQ and Learning to Be Declarative

#41

Post by Kuinox »

cjonas wrote: post #8

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 GetExclusiveProducts(List source) => (from p in source where p.ProductTitle =…

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

Re: LINQ and Learning to Be Declarative

#42

Post by dfee »

I worked in a C# shop for a bit, but never wrote LINQ and saw very little of it.

However, in my Java days, I've very much enjoyed using streams. Looking back at LINQ now, it seems like a nice DSL around streams (which probably exist in C# land, too).

Interested in commentary around this!

Re: LINQ and Learning to Be Declarative

#43

Post by bcrosby95 »

bob1029 wrote: post #2

> 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…

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.

Re: LINQ and Learning to Be Declarative

#44

Post by tracker1 »

Kwpolska wrote: post #21

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 GetExclusiveProducts(List 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 f…

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.

Re: LINQ and Learning to Be Declarative

#45

Post by sieep »

Etheryte wrote: post #9
sieep wrote: post #6

Earlier quoted context omitted.

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!

Having things on one line is not an upside. Just think of all the Bash one-liners that are write once edit never. Doubly so in what's essentially a tutorial.

My intention wasn’t to promote one-liners as a best practice, but to illustrate how declarative style can evolve from imperative code.

In production, I agree that clarity should come first.

Re: LINQ and Learning to Be Declarative

#46

Post by neonsunset »

bcrosby95 wrote: post #43
bob1029 wrote: post #2

> 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…

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 immutabili…

[dead]

Re: LINQ and Learning to Be Declarative

#47

Post by sieep »

HackerThemAll wrote: post #17

"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.

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.

Re: LINQ and Learning to Be Declarative

#49

Post by mrsmrtss »

dfee wrote: post #42

I worked in a C# shop for a bit, but never wrote LINQ and saw very little of it. However, in my Java days, I've very much enjoyed using streams. Looking back at LINQ now, it seems like a nice DSL around streams (which probably exist in C# land, too). Interested in commentary around this!

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.

Re: LINQ and Learning to Be Declarative

#50

Post by Digit-Al »

louthy wrote: post #11

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 m…

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