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.
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 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 likelist.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
autoand template arguments remove a lot of the need for typing. Or in Python where the dynamic types also remove the need for typing.