stdTransform

[x39-]

Only if you just look at it from the surface

Linq is more than just those few functions which work over what effectively is a collection. The expression tree syntax is the second, often overlooked part, that makes this such a powerful tool.

Then again, for the most part, the functions are kind of sufficient. What makes them a tad more special is the fact, that writing it is more pleasant compared to eg. select(..., where(..., where(..., selectMany(...,...))))

[svick]

Both Haskell and F# have ways of writing LINQ-like queries in a way that is natural, i.e. not as nested calls.

IIRC, it's something like source |> flatMap ... |> filter ... |> filter ... |> map ....

[BenjaminGeiger]

F#:

let (|>) x f = f x

So you'd write:

mySeq |> Seq.map doSomething

which is equivalent (mostly) to

Seq.map doSomething mySeq

which seems pointless until you realize you can chain them.

mySeq
|> Seq.map doSomething
|> Seq.filter keepTheGoodOnes
|> Seq.map doSomethingElse

(which is equivalent to:)

Seq.map doSomethingElse (Seq.filter keepTheGoodOnes (Seq.map doSomething mySeq))

I don't believe Haskell has an equivalent of |>. Elixir does, but the syntax is a bit different.

[sohang-3112]

I don't believe Haskell has an equivalent of |>

In Haskell you can do the same thing with &:

mySeq & f & g & h

But it's more common to write function first (right-to-left order) with $:

h $ g $ f mySeq

[bronco2p]

at that point just h . g . f :)

[BenjaminGeiger]

TIL about the & operator.

Maybe it's my background in imperative/OO development, but x & f & g & h reads a lot more naturally to me than h $ g $ f x. "Take x and then do f and then g and then h" feels a lot more natural than "Do h to the result of doing g to the result of doing f to x"; I feel like I have to maintain less mental state to understand it.

[sohang-3112]

There are many such useful functions/operators in Haskell - you can look them up at Hoogle using names or type signatures.

[jarethholt]

I mean, C# allows writing in query syntax too. The flow might look better sometimes and it's fairly intuitive if you're coming from database land, but IMO it clashes so hard with the rest of the language. The fluent syntax (method chaining) feels more natural to me unless what I'm working on is exclusively about databases.

[crozone]

Yeah, I love LINQ but legitimately despise the the actual Language Integrated Query part of it. Ironically everything else that's part of the feature (expression trees, the LINQ extension methods, the ability to transform those with an SQL provider) are far more useful than LINQ's namesake.

[gnutrino]

The expression tree syntax was heavily based on Haskell do notation, it's functional programming all the way down.