Then your conclusion is that wrapping anything in a procedure makes it declarative, making declarative code equivalent to procedural abstraction.
Being able to rearrange how list.filter(isEven).map(double) executes doesn't mean that the control flow is not explicit.
Let's rephrase your argument to be about for loops, and see that it holds true to the same degree.
"A for loop does not have an explicit description of its control flow. A runtime or compiler might run them one after the other or might lump them together in one iteration. It can do that because the construct itself is not describing step by step how the code should be evaluated. It is just describing what should happen to the data."
This claim is incorrect for a couple of reasons.
If we understand the effects of a piece of code, regardless of how it is expressed, we can replace that piece of code with another piece of code which has the same effects. This is the basis of optimizing compilation.
In javascript, list.filter(isEven).map(double) describes method calls. It is describing step by step how the code should be evaluated. It is not making declarations about how the data should be changed. In some other language this might not be the case, but we're talking about javascript.
"A piece of code doesn't become imperative programming, simply because there is one single primitive, especially when said primitive is a subroutine."
Perhaps not, but your argument hinges on "explicit control flow operations", which clearly include procedure calls.
Is your claim that "a piece of code becomes declarative, simply because it is wrapped in a procedure"? :)
Regarding flow control -- we were talking of transfer of control over the control flow, control flow is a flow, and so we can refer to this as flow control -- English is flexible, and writing out control flow control is awkward.
No, sorry, you can't change my argument and then make a rebuttal for that. That is called a strawman and is not an honest way to engage in a discussion.
Then your conclusion is that wrapping anything in a procedure makes it declarative, making declarative code equivalent to procedural abstraction.
Being able to rearrange how list.filter(isEven).map(double) executes doesn't mean that the control flow is not explicit.
Let's rephrase your argument to be about for loops, and see that it holds true to the same degree.
"A for loop does not have an explicit description of its control flow. A runtime or compiler might run them one after the other or might lump them together in one iteration. It can do that because the construct itself is not describing step by step how the code should be evaluated. It is just describing what should happen to the data."
This claim is incorrect for a couple of reasons.
If we understand the effects of a piece of code, regardless of how it is expressed, we can replace that piece of code with another piece of code which has the same effects. This is the basis of optimizing compilation.
In javascript, list.filter(isEven).map(double) describes method calls. It is describing step by step how the code should be evaluated. It is not making declarations about how the data should be changed. In some other language this might not be the case, but we're talking about javascript.
"A piece of code doesn't become imperative programming, simply because there is one single primitive, especially when said primitive is a subroutine."
Perhaps not, but your argument hinges on "explicit control flow operations", which clearly include procedure calls.
Is your claim that "a piece of code becomes declarative, simply because it is wrapped in a procedure"? :)
Regarding flow control -- we were talking of transfer of control over the control flow, control flow is a flow, and so we can refer to this as flow control -- English is flexible, and writing out control flow control is awkward.
No, sorry, you can't change my argument and then make a rebuttal for that. That is called a strawman and is not an honest way to engage in a discussion.
Which part did I change?