I remember when I used to hear about so-called "functional programming" (I mean was I doing dysfunctional programming before? Weeeeell, I probably ...
For further actions, you may consider blocking this person and/or reporting abuse
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.But those remarks are exactly why FP is so awesome!
Yeah, it's hard, but it's rather interesting and exquisite.
As FP is generally a rather niche programming paradigm ( FP languages, not FP elements like higher-order functions, currying and other examples that are commonly found nowadays in most programming languages ), I think one should strive to learn more about the delicacies of the paradigm.
It shouldn't be niche, and I think people treating it as such is part of why it's adoption is limited. The fundmanetal points of functional programming, such as immutable data, first class functions, and pure functions, are immensely useful when combined with other paradigms.
Every coder should understand the paradigm, even if they never touch one of the traditionally functional languages.
Oh I agree. I have enjoyed learning the more advanced topics. But those are often intimidating to beginners. And you really don't need to know about them to get started and get real value from the paradigm. They make for really pleasant surprises later. And FP languages make those gems more noticeable sooner. For example, I don't think I ever would have embraced functional error handling in C#, because the language makes it too much work. (And I did try.)
I agree with this. I think the advanced topics present tremendous value down the road. But are hardly of value in the beginning of someones journey. Think, explaining generics to a new C# developer. The best analogy from life I can think of is teaching how to play a card game to someone and whilst explaining the rules, you introduce strategies. The strategies are incredibly useful. But only serve to muddle the learning process. Possibly to the point of quitting.