You can certainly write pure functions in C#. But it can be a bit awkward. Anonymous functions have overhead to setup, often requiring a type declaration in the form of Func<type1, type2, returntype>. Partial application becomes more verbose. C# makes it difficult to avoid nulls and thrown exceptions. (To be fair, .NET itself makes that latter hard to avoid in F# code too.) C# lacks the primary means that F# uses to avoid these: union types. (Union types are also a great modeling tool for business logic.) The C# alternative to this could be subclassing or marker interfaces, which also work well with the new pattern matching feature. However, it's quite verbose to setup compared to union types. Avoiding mutation is really tough to ensure in C#, and foreign to most of us coming from OO. It requires a high level of discipline (and training for new team members).
I'd say that you can do pure functions in C#, but it's not what is made easy there. And under deadline, I find that I will often go with the path of least resistance. If the goal is to write pure functions, F# makes that easier. F# is not perfect in that regard either... it's still pretty easy to introduce side effects like getting current time. I wish there was a way to mark modules "pure" so they would generate a compiler warning if a side effect was introduced. (I'm aware of Delegate.Sandbox, but I don't really want to run unoptimized code.) But in all, F# gets you a long way towards making pure functions easier to write.
Have had many hats on in my life: Developer, Team Lead, Scrum Master, Architect and Product Owner. Now back to developer \o/ Interested in product discovery, quality assurance and language design.
"And under deadline, I find that I will often go with the path of least resistance"
Yes, that's the point. The new C# features are all going in a functional direction, but it's still too easy to either skip or miss core elements of FP. But it's still interesting to see how virtually all languages currently add functional elements (or new languages start functional from the beginning, like Elm), so hope for FP becoming more mainstream is still there.
Absolutely. As several recent languages show, there's no reason why FP can't exist alongside OO (and procedural) in the same language. I'd like to believe that FP becomes the dominant paradigm before long. I just hope people don't fall into the same trap I did and get discouraged with FP. The trap was that I focused on using match and Maybe and partial application, and all the other mechanics of FP. But disappointingly, I found they didn't provide much benefit, because I wasn't striving to make pure functions with them. Nobody really explained that to me, so I thought I would take a stab at it with this post. :) Best wishes!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You can certainly write pure functions in C#. But it can be a bit awkward. Anonymous functions have overhead to setup, often requiring a type declaration in the form of
Func<type1, type2, returntype>. Partial application becomes more verbose. C# makes it difficult to avoid nulls and thrown exceptions. (To be fair, .NET itself makes that latter hard to avoid in F# code too.) C# lacks the primary means that F# uses to avoid these: union types. (Union types are also a great modeling tool for business logic.) The C# alternative to this could be subclassing or marker interfaces, which also work well with the new pattern matching feature. However, it's quite verbose to setup compared to union types. Avoiding mutation is really tough to ensure in C#, and foreign to most of us coming from OO. It requires a high level of discipline (and training for new team members).I'd say that you can do pure functions in C#, but it's not what is made easy there. And under deadline, I find that I will often go with the path of least resistance. If the goal is to write pure functions, F# makes that easier. F# is not perfect in that regard either... it's still pretty easy to introduce side effects like getting current time. I wish there was a way to mark modules "pure" so they would generate a compiler warning if a side effect was introduced. (I'm aware of Delegate.Sandbox, but I don't really want to run unoptimized code.) But in all, F# gets you a long way towards making pure functions easier to write.
Yes, that's the point. The new C# features are all going in a functional direction, but it's still too easy to either skip or miss core elements of FP. But it's still interesting to see how virtually all languages currently add functional elements (or new languages start functional from the beginning, like Elm), so hope for FP becoming more mainstream is still there.
Absolutely. As several recent languages show, there's no reason why FP can't exist alongside OO (and procedural) in the same language. I'd like to believe that FP becomes the dominant paradigm before long. I just hope people don't fall into the same trap I did and get discouraged with FP. The trap was that I focused on using
matchandMaybeand partial application, and all the other mechanics of FP. But disappointingly, I found they didn't provide much benefit, because I wasn't striving to make pure functions with them. Nobody really explained that to me, so I thought I would take a stab at it with this post. :) Best wishes!