The topic of the interplay between the "expected" and "emergent" behavior of the system, reminds me a lot of Dijkstra's famous GOTO essay. The point he made in that essay was that GOTO was harmful because it prevented you from making inferences about the dynamic behavior of the program from its static syntax, whereas structured programming allowed you to relate the dynamic state of the system to a "coordinate system" derived from the control structures. I think that appeals to human intuition are often misplaced when it comes to this aspect of code specifically, because code complexity experiences exponential blowup. No matter how well you represent a boolean expression in terms of naming, code formatting, or organization, for instance, there is the fundamental fact that boolean satisfiability is NP-complete; at some point your brain will be unable to scale that cliff. This remark doesn't apply to code that isn't of an NP-complete flavor, like say a flat list of drawing instructions. I think "composability" is what is important for code, but "composability" is a somewhat vague word. More precisely, there should be a way to determine specific properties of the system by systematic logical deduction from the components of the system, and without simulating the whole dynamic trace of the system's execution. Composability can only be defined relative to the properties you are interested in: SQL is "composable" if you want to know if an element is in the relation defined by the SQL statement, but is not so "composable" if you want to know how long the statement will take to run.

“The principle of compositionality has been the subject of intense debate. Indeed, there is no general agreement as to how the principle is to be interpreted, although there have been several attempts to provide formal definitions of it. (Szabó, 2012)“ — https://en.wikipedia.org/wiki/Principle_of_compositionality 😄 This also seems useful: https://plato.stanford.edu/entries/compositionality

Have always liked that essay. The problem we have now as I see it is that structured step-by-step plans aren't a good model for many programs.

I really like this:

Composability can only be defined relative to the properties you are interested in: SQL is "composable" if you want to know if an element is in the relation defined by the SQL statement, but is not so "composable" if you want to know how long the statement will take to run.

Functional programming is quite good for reasoning about eqautional properties of values but not as much runtime

@stevekrouse are you saying this because functions opaque in the sense that the same function can be defined in two ways which may have different runtime characteristics?

Yes. The way I'd put it is: you can reason informally (or prove if you had the time and inclination) that two functions (or expressions) are equivalent in some mathematical/denoational sense but their runtime characteristics can be very different. For example, various definitions of fibbonacci. I'm also interested in what it would look like for performance characteristics to be composible, if that'd even make sense. So that you could reason about performance of an expression by it's constituent parts and their combining forms. Maybe like this https://granule-project.github.io/index.html

In general terms for "same in some ways but different in others" questions, I find a categorical mindset helpful. I guess in the verbiage of Granule, you use different type-systems to pull out different information. The trick (and I think it's absolutely on their radar) is constructing the type-systems as to accommodate composition and refinement.