I think these kinds of arguments are rather pointless.
The only thing that matters: if I open a random file, how high is the chance that the author wrote in my “preferred style” (functional in this case)?
If it’s not close to 90%, “you can also also do X in language Y” is nothing but a useless party trick.
It’s been a while since I played FizzBuzz, so I coded it up in F# to compare how the two answers look:
|> Seq.iter(fun x->
(match (x%3=0, x%5=0) with
|(true,true)->printfn "%s" "FizzBuzz"
|(true,_)->printfn "%s" "Fizz"
I don’t know. There’s nothing wrong with the C# code.
I tend to view languages differently now than I used to. So instead of asking if a language has $FEATURE_X, I tend to like just a few features can care more about the experience I get coding things. To me the F# code looks more enjoyable, while the C# looks tediouis. It works, but it’s like the language doesn’t want it to work. I don’t think I’d be recommending to C# coders to code this way. I’d rather have them switch over to F# and use OO concepts. That gives them a clear path towards FP if that’s what they want to end up doing. This looks like a little of everything.
My two cents, fwiw.
I agree. Most modern languages are multi-paradigm and have ample support for both functional and OO constructs and styles. However, some languages lean a little more one way than the other.
I love the trend towards adopting a more functional style in traditionally OO languages like C# and C++. I wish languages that lean a little more functional, particularly F# (and Elm), would gain more traction in general.
As an aside, I code in about a dozen languages or more, and I’ve learned enough new tech in my career that I don’t get very excited about programming languages and such.
Having said that, F# is fun. I’ve been using it since it was in beta, and it’s just a joy to play with. Because it’s fun, and because it also handles OO, I consider it first and foremost a training language. You can come here and code using any paradigm you’d like, then go through and by taking out the fp smells learn to be a better functional coder. I don’t get that from the C# code.
This is some excellent “Code Golf”, but I would never write C# in this style. I’m pretty impressed that C# now has the functionality for pattern matching on tuple values though.
Apart from the valid but already generally accepted point about single responsibility and pureness of a function, the implied advice of this article seems to be to get clever with code just to use functional-style syntax, and maybe save a line or two.
I am still convinced that compared to making code easy to read (to which single responsibility and pureness obviously contribute), all other concerns are as good as negligible. In that light, following this article would actually be detrimental to code quality.