Yes! And that other 5% seems to be the biggest hurdle because it can be a significant shift in thinking. I've been telling the devs, a huge chunk of the battle is just two things:
Asking yourself if your functions truly have a single responsibility, or whether you've let side-effects creep in, and,
Using well-named variables.
A great example is redirect. Per our React/React Router standards, we don't use history.push. Instead we use React Router's <Redirect> component. That much they got pretty easily, but they started declaring a state variable called "redirect" and assigning an href to it. It was a lot harder to get them to understand that it's better to name the variable after the REASON for the redirect (e.g. userClickedCancel or whatever) and then writing conditions that check it right in the render return. They're still getting used to that aspect of it.
Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
You make good points, and I completely agree, but let me be a bit pedantic on what I meant.
I meant that the "aha" moment for me was when I completely disregarded the "how" and "what", and instead saw declarative programming as a higher level of abstraction to work with.
It's good to separate concerns and abstract where possible, and functional programming takes that to the extreme. It encourages extremely tiny unit functions with no logic duplication.
That's what 95% of declarative programming is (in my opinion). Abstract / extract everything you can, so instead of 10 lines with a for loop, you've got a single line with a map. Heck, if you could abstract the map away, do that as well. As another example, point-free seems the same to me. Is there any reason for point-free other than not creating the exact same function with points repeated? It just seems like extreme abstraction and separation of concerns.
The "how" and "what" are the consequence of that. Afterwards, keeping the concepts of "how" and "what" in mind is an optional cherry on top.
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.
Yes! And that other 5% seems to be the biggest hurdle because it can be a significant shift in thinking. I've been telling the devs, a huge chunk of the battle is just two things:
A great example is redirect. Per our React/React Router standards, we don't use history.push. Instead we use React Router's <Redirect> component. That much they got pretty easily, but they started declaring a state variable called "redirect" and assigning an href to it. It was a lot harder to get them to understand that it's better to name the variable after the REASON for the redirect (e.g. userClickedCancel or whatever) and then writing conditions that check it right in the render return. They're still getting used to that aspect of it.
You make good points, and I completely agree, but let me be a bit pedantic on what I meant.
I meant that the "aha" moment for me was when I completely disregarded the "how" and "what", and instead saw declarative programming as a higher level of abstraction to work with.
It's good to separate concerns and abstract where possible, and functional programming takes that to the extreme. It encourages extremely tiny unit functions with no logic duplication.
That's what 95% of declarative programming is (in my opinion). Abstract / extract everything you can, so instead of 10 lines with a
forloop, you've got a single line with amap. Heck, if you could abstract themapaway, do that as well. As another example, point-free seems the same to me. Is there any reason for point-free other than not creating the exact same function with points repeated? It just seems like extreme abstraction and separation of concerns.The "how" and "what" are the consequence of that. Afterwards, keeping the concepts of "how" and "what" in mind is an optional cherry on top.