Anybody doing imperative programming can start using the functional constructs of their current language. It's the lowest learning curve to being introduced to a new paradigm.
Sure, but some of them make it really difficult to do so or don’t have features to support really common practices of the paradigm. Like in C#, I can do partial application, but it’s awkward without curried functions. Also functions can be values, but I frequently have to make long type declarations to make that happen. It’s annoying enough to be discouraging because the language doesn’t support me in it.
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 current project, thus you can learn it at work. It's a great way for somebody to expose themselves to something new and spark their interest.
Partial application is easy with lambda functions. You don't need currying for that. var in C#, auto in C++, and perhaps even implicit typing in Rust, also remove a lot of the need for long declarations.
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.
Anybody doing imperative programming can start using the functional constructs of their current language. It's the lowest learning curve to being introduced to a new paradigm.
Sure, but some of them make it really difficult to do so or don’t have features to support really common practices of the paradigm. Like in C#, I can do partial application, but it’s awkward without curried functions. Also functions can be values, but I frequently have to make long type declarations to make that happen. It’s annoying enough to be discouraging because the language doesn’t support me in it.
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 current project, thus you can learn it at work. It's a great way for somebody to expose themselves to something new and spark their interest.
Partial application is easy with lambda functions. You don't need currying for that.
varin C#,autoin C++, and perhaps even implicit typing in Rust, also remove a lot of the need for long declarations.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.