Andy Hunt and Dave Thomas tell us: 'it’s critical that you write code that is readable and easy to reason about.' This seems uncontroversial; it is the rare point on which software engineers typically agree. Or do they?
Architectural layers and abstraction impedes imperative readability, since both hide the concrete implementation details.
On the other hand, declarative readability (or readability-d) uses abstractions and architectural layers to manage complexity. It seeks to answer very different types of questions:
What is the intent of this function or module?
What business rule or domain concept is this code encapsulating?
What is the end goal or output of this code, in terms of the domain?
What are the high-level policies or constraints that this code is adhering to?
… I’ve no interest in learning Scala or Closure, but damn that is an important differentiation…
from the article…
"Imperative Readability
< snip >
How does the function execute its logic?
What are the specific steps taken by the code?
Which operations are performed in what sequence?
How are state changes managed and tracked
< snip >
Declarative Readability
On the other hand, declarative readability (or readability-d) uses abstractions and architectural layers to manage complexity. It seeks to answer very different types of questions:
What is the intent of this function or module?
What business rule or domain concept is this code encapsulating?
What is the end goal or output of this code, in terms of the domain?
What are the high-level policies or constraints that this code is adhering to?
… I’ve no interest in learning Scala or Closure, but damn that is an important differentiation…