| No misunderstanding on my part, no worries. And apologies for the misunderstanding due to my terseness, which is partly due to me having written about this in great depth on a number of occasions, here are two examples: - Why Architecture-Oriented Programming Matters[1] - Can Programmers Escape the Gentle Tyranny of call/return?[2] The basic point is that we are so used to programming simply being call/return (and functional is a subset of that), that it is very hard for us to conceive of programming being anything else. And one consequence of that is that we try to map every problem onto a call/return (incl. FP) solution, no matter how inappropriate the mapping, and the mapping very often is inappropriate, leading to architectural mismatch. [3][4] We do this partly because we really don't know better, but also partly because there are tangible benefits, primarily that once we have done that mapping, we can then express whatever we arrived at pretty directly in our languages, because our languages effectively only allow call/return based abstraction. It's a bit of a conundrum. [1] https://blog.metaobject.com/2019/02/why-architecture-oriente... [2] https://2020.programming-conference.org/details/salon-2020-p... [3] https://repository.upenn.edu/library_papers/68/ [4] https://rd.springer.com/content/pdf/10.1007/978-3-540-92698-... |