I really like your way of framing abstractions as “parametrizations” of the choice function. Another way to think of this is that you want your ontology of things in the world to consist of abstractions with loose coupling.
For example:
Let’s say you’re considering eating something, and you have both “eating an apple” and “eating a blueberry muffin” as options.
Also assume that you don’t have a class for “food” that includes a reference to “satiation” such that “if satiated, then food is low expected utility”. Instead, that rule is encoded into every class of food separately.
Then you’d have to run both “eating an apple” and “eating a blueberry muffin” into the choice function separately in order to figure out that they are low EV. If instead you had a reasonable abstraction for “food”, you could just run the choice function once and not have to bother evaluating subclasses.
Not only does loose coupling help with efficient computation, it also helps with increasing modularity and thereby reducing design debt.
If base-level abstractions are loosely connected, then even if you build your model of the world on top of them, they still have a limited number of dependencies to other abstractions.
Thus, if one of the base-level abstractions has a flaw, you can switch it out without having to refactor large parts of your entire model of the world.
A loosely coupled ontology also allows for further specialisation of each abstraction, without having to pay costs of compromise for when abstractions have to serve many different functions.
This is good stuff!
I really like your way of framing abstractions as “parametrizations” of the choice function. Another way to think of this is that you want your ontology of things in the world to consist of abstractions with loose coupling.
For example:
Let’s say you’re considering eating something, and you have both “eating an apple” and “eating a blueberry muffin” as options.
Also assume that you don’t have a class for “food” that includes a reference to “satiation” such that “if satiated, then food is low expected utility”. Instead, that rule is encoded into every class of food separately.
Then you’d have to run both “eating an apple” and “eating a blueberry muffin” into the choice function separately in order to figure out that they are low EV. If instead you had a reasonable abstraction for “food”, you could just run the choice function once and not have to bother evaluating subclasses.
Not only does loose coupling help with efficient computation, it also helps with increasing modularity and thereby reducing design debt.
If base-level abstractions are loosely connected, then even if you build your model of the world on top of them, they still have a limited number of dependencies to other abstractions.
Thus, if one of the base-level abstractions has a flaw, you can switch it out without having to refactor large parts of your entire model of the world.
A loosely coupled ontology also allows for further specialisation of each abstraction, without having to pay costs of compromise for when abstractions have to serve many different functions.