Skip to content
loading...

re: Why you are scared of Functional Programming VIEW POST

TOP OF THREAD FULL DISCUSSION
re: Why would this be a problem? You'll still be learning a functional paradigm, but comfortably in your current language. You can also use it on your ...

You definitely have a point about applying the principles to whatever language you are using. I certainly try to when I am working in our legacy systems which are in other languages. You don't have to have currying and partial application and whatnot to write pure functions and well-structured functional programs.

But at the end of the day, not having those features provides a lot of resistance to using the paradigm, and can actually be more work than using the language's default paradigm. I learned this the hard way when I tried to implement error handling in C#, like I was using in F# (which also has to handle exceptions from framework/ecosystem libraries). Some things will simply not be worth fighting the resistance (and if talking about doing it in a team using OO, won't make code review), and so you won't get to learn them.

As far as implicit typing, give it a try and see. It doesn't work well for functions (in C# anyway). Example: var addOne = x => x + 1; gives compile error "Cannot assign lambda expression to an implicitly typed variable." That was a great disappointment to me. I was used to being the consumer where the function was already defined like list.Where(x => x.IsTrue). But when you are the one defining the functions, not just plugging them in, it gets painful quickly.

I'll admit that isn't nice in C#. Maybe I was thinking more C++ where auto and template arguments remove a lot of the need for typing. Or in Python where the dynamic types also remove the need for typing.

code of conduct - report abuse