This article is fantastic and helped improve my understanding of the topic. Something that I struggle with understanding is what level of abstraction crosses the line from “imperative” to “declarative”. I think the bar for “declarative” vs “imperative” will change as programming languages continue to improve their levels of abstraction.

When C first came out, I am sure writing something like:

int addNumbers(int a, int b)
{
    int sum = a + b;
    return sum;
}

Felt very declarative next to the corresponding assembly code:

.section __TEXT,__text,regular,pure_instructions
 .macosx_version_min 10, 11
 .globl _addNumbers
 .align 4, 0x90
_addNumbers: ## @addNumbers
 .cfi_startproc
## BB#0:
 pushq %rbp
Ltmp0:
 .cfi_def_cfa_offset 16
Ltmp1:
 .cfi_offset %rbp, -16
 movq %rsp, %rbp
Ltmp2:
 .cfi_def_cfa_register %rbp
 movl %edi, -4(%rbp)
 movl %esi, -8(%rbp)
 movl -4(%rbp), %esi
 addl -8(%rbp), %esi
 movl %esi, -12(%rbp)
 movl -12(%rbp), %eax
 popq %rbp
 retq
 .cfi_endproc
.subsections_via_symbols

And I am sure the assembly code even feels declarative to the people writing machine code. Indeed assembly code allows us to target multiple processors because its an abstraction over machine which is another form of how.

I think what is “declarative” is truly expression of the person authoring the code.

Indeed to me, writing out:

function double (arr) {
  let results = []
  for (let i = 0; i < arr.length; i++){
    results.push(arr[i] * 2)
  }
  return results
}

Is terribly imperative, but to the chaps implementing the underlying browser engine, parsing this into a syntax tree, this can very quickly start to be the “what” not the “how” as they turn them into underlying instructions.

Since there is such a wide range of developers and we are all working at different layers of abstraction I think what is declarative changes based on context. What I consider declarative, to another is imperative and… we would both be speaking truly and correctly. This is what makes this topic so difficult for me to wrap my head around.