It’s been a while since I played FizzBuzz, so I coded it up in F# to compare how the two answers look:
let x=seq{0..100}
|> Seq.iter(fun x->
(match (x%3=0, x%5=0) with
|(true,true)->printfn "%s" "FizzBuzz"
|(true,_)->printfn "%s" "Fizz"
|(_,true)->printfn "%s""Buzz"
|(_,_)->()))
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.
I have friends that talk about C++ being functional. Just start using some consts! I have other friends fond of functional Javascript. These things to me always seem like sticking two things together that work but don’t look right.
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.
C# code can be functional, but the language leans more OO. Also, C#, probably owing to its heritage, tends to be more verbose, and functional C# can look a little noisy compared to something like F#. The same can be said for Java and C++. Javascript is a different beast that occupies a unique space.
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.
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:
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.
I have friends that talk about C++ being functional. Just start using some consts! I have other friends fond of functional Javascript. These things to me always seem like sticking two things together that work but don’t look right.
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.
C# code can be functional, but the language leans more OO. Also, C#, probably owing to its heritage, tends to be more verbose, and functional C# can look a little noisy compared to something like F#. The same can be said for Java and C++. Javascript is a different beast that occupies a unique space.
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.