Declarative Programming

I've noticed that the concept developers on my teams have the most trouble understanding is declarative coding. I think I have a blog post in me about this. But more importantly, I wonder, is this just a concept that isn't really taught anywhere? If not, we need more emphasis on this very important concept.

Comments

[Spyros Argalias]

I didn't really understand what declarative programming meant for AGES. "State what you want to happen, not how"... E.g. myArray.map is more declarative than a for loop.

My confusion was because:

• Even if you use .map, you're still writing code and telling it what to do. You're still stating how, you're just stating less of the how.
• Internally, map uses a for loop anyway. So... (okay it could use recursion but that doesn't matter.)

So after learning some functional programming, I realised that declarative programming is just:

• A higher level of abstraction. That's 95% of it. Take as much code as you can and put it in a different function, so your current function can have less instructions. This is simple separation of concerns and abstraction.
• The other 5% is a mindset shift. Just ask yourself "how can I make this code sound more like what to do, rather than how to do it?".

That's it.

[Dave M]

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.

[Spyros Argalias]

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.