Cool to "see" F# in action. Like the union types, but not so much the list operations; seems more natural to: [1;2;3;4] filter isEven sum vs. List.filter isEven [1;2;3;4] |> List.sum in Scala it's: List(1,2,3,4) filter isEven sum Of course I'm not familiar with F# so don't know all of the WIN within (Type Providers, for example, are very impressive, would love to see that on the Scala side of the fence one day).
So in
List(1,2,3,4) filter isEven sum
it looks like filter and sum are instance methods on the List class, and I'm guessing isEven is a predicate that's being passed as an argument to the filter method.F# leans closer to its functional roots in this respect, so it's more idiomatic to keep object-oriented constructs at arm's reach in most your code. The language has full support for OOP, it's just that you're not expected to trot it out except when you're writing public interfaces that are meant to be consumed by code that might be written in C# or VB.NET. So the List class mostly sticks to static methods in its public interface because that approach fits better with traditional functional idioms.
That gets you as far as something like this:
List.sum (List.filter isEven [1;2;3;4])
The next step is the "pipeline" operator, which is defined as let inline (|>) x f = f x
So it's just letting you swap a function and its argument, which facilitates reorganizing the code so that the functions are listed in the order in which they execute. That's what gets you to the example you give - or better yet: [1;2;3;4]
|> List.filter isEven
|> List.sum
which I think captures some of the natural expression that you were talking about while still sticking with functional idioms instead of object-oriented ones.