How are the conceptual pairs Abstract/Concrete, Generic/Specific, and Complex/Simple related to one another in software architecture?

Question

(= 2 (+ 1 1))

take the above. The requirement of the '=' predicate is that its arguments be comparable. Any two structures are comparable in this case, and so the contract/requirement is pretty generic. The '+' predicate requires that its arguments be numbers. That's more specific.

(socket domain type protocol)

the arguments here are much more specific (even though the arguments are still just numbers and the function itself returns a file descriptor, which is itself an int), but the arguments are more abstract, and the implementation is built up from other functions whose abstractions are less abstract, which are themselves built from less and less abstract abstractions. To the point where the requirements are something like move from one location to another, observe whether the switch at that location is on or off, turn the switch on or off, or leave it the same, etc.

But are functions also less and less complex the less abstract they are? And is there a relationship between the number and range of arguments of a function and the complexity of its implementation, as you go from more abstract to less abstract, and vice versa?

(= 2 (+ 1 1) 2r10)

the '=' predicate is more generic than the '+' predicate, and thus could be more complex in its implementation. The '+' predicate's contract is less generic, and so could be less complex in its implementation. Is this even a little correct? What about the 'socket' function? Each of those arguments is a number of some kind. What they represent, though, is something more elaborate. It also returns a number (just like the others do), which is also a representation of something conceptually much more elaborate than a number.

To boil it down, I'm asking if there is a relationship between the following dimensions, and why:

1. Abstract/Concrete
2. Complex/Simple
3. Generic/Specific

And more specifically, do different configurations of these dimensions have a specific, measurable impact on the number and range of the arguments (i.e., the contract) of a function?

Answer 1

Generic/Specific and Abstract/Concrete are the same axes. They're synonymous, just different terms - when you make something generic, you're making it non-concrete, rather abstract. When you make something specific, you're making it non-abstract, rather concrete.

Complex/Simple is an unrelated axes to the above one you describe. You can show that they do not track together by simply drawing the quadrant of the two axes and fill it in to display the constraints that a relationship would confer.

            Abstract/Generic
                    |
                    |
          Possible  |  Possible
                    |
Complex_____________|______________Simple
                    |
          Possible  |  Possible
                    |
                    |
            Concrete/Specific

All four quadrants are possible and therefore unconstrained. These axes profer no constraints upon eachother, therefore there's no relation.

---

And more specifically, do different configurations of these dimensions have a specific, measurable impact on the number and range of the arguments (i.e., the contract) of a function?

My experience tells me that individually these axes effect the design of any given bit of code, as such to say in combination they also effect the design is pretty clear. As for what precisely that impact is? Well it impacts how the code lays on these axes for one, so you can measure that I guess if you can come up with a measurement system for it.

That said, I really don't think you'll get any description of how these dimensions effect code, I've no knowledge of studies that talk about these necessarily. Though subjective opinions are a plenty, you likely can't get any objective info on how these subjective axes objectively effect code.