In my opinion syntactic expression (be it imperative or functional) is almost pure coincidence wrt "what" and "how". While I can see some analogy with mathematical equations (an equation to be solved is "what" and solution of the equation is "how"): In common sense people understand it, "what" is nearer the problem and "how" is nearer the solution, the "what" and "how" lies in the relation to the knowledge of the problem domain as well as the possibility to process that knowledge.

The difference is similar to the geographic map. The map itself depicts a network of roads and is the "what". Pathfinder, given two points, can give you "how" you can drive from A to B. That knowledge is already in the map, so for repeated tasks it's more valuable to have a map than specific route descriptions. If one knows how to "read" the map.

It is probably incorrect to ask if your Haskell function is "what" or "how" as it's just a small fragment of the road and can be both a path and a map. To talk about "whats" and "hows" makes sense only having some information system. Then we will clearly see that declarative knowledge (an ontology) plus some generic algorithm (imperative or otherwise) makes the system more valuable because "what" is more generic, and can potentially solve much more problems in the domain.

An alternative is to have almost everything expressed as "how", which most probably is not flexible enough and usually not that valuable.

In other words, expressing knowledge as "what" can make it more useful, but it also assumes the system has a "how" part: Some interpreter, rule engine, logical inferencer, etc, which "understands" how to deal with "what". The win comes at bigger volumes: It is easy to add more "what" as declarations are rarely described in sophisticated programming language, and ideally the interpreter part remains the same.

According to that, the Haskell snippet looks like "how" unless you have a system, which operates on it. It's code-data duality.

In my opinion syntactic expression (be it imperative or functional) is almost pure coincidence wrt "what" and "how". While I can see some analogy with mathematical equations (an equation to be solved is "what" and solution of the equation is "how"): In common sense people understand it, "what" is nearer the problem and "how" is nearer the solution, the "what" and "how" lies in the relation to the knowledge of the problem domain as well as the possibility to process that knowledge.

The difference is similar to the geographic map. The map itself depicts a network of roads and is the "what". Pathfinder, given two points, can give you "how" you can drive from A to B. That knowledge is already in the map, so for repeated tasks it's more valuable to have a map than specific route descriptions. If one knows how to "read" the map.

It is probably incorrect to ask if your Haskell function is "what" or "how" as it's just a small fragment of the road and can be both a path and a map. To talk about "whats" and "hows" makes sense only having some information system. Then we will clearly see that declarative knowledge (an ontology) plus some generic algorithm (imperative or otherwise) makes the system more valuable because "what" is more generic, and can potentially solve much more problems in the domain.

An alternative is to have almost everything expressed as "how", which most probably is not flexible enough and usually not that valuable.

In other words, expressing knowledge as "what" can make it more useful, but it also assumes the system has a "how" part: Some interpreter, rule engine, logical inferencer, etc, which "understands" how to deal with "what". The win comes at bigger volumes: It is easy to add more "what" as declarations are rarely described in sophisticated programming language, and ideally the interpreter part remains the same.

According to that, the Haskell snippet looks like "how" unless you have a system, which operates on it (NB: not just executes it). It's code-data duality.