This type of complexity is a common problem in object oriented programming. "This" type has a method that accepts a "that" type, and it works well until there are too many combinations of types. Any time a new "that" is created, the original code needs to be updated. This is where OOP reaches for interfaces, so the "that" type can be anything that claims to be a "that". This works well for even longer, but it still tends to fail at scale. Any time a new behavior is require, the interface changes and now every implementation needs to be updated.
I have a soft spot for old systems, and one of them is Common Lisp. CL was standardized before OOP, and one of the ways it deals with this is multiple dispatch. Instead of "this" type of object having a method operating on "that" type, the function is declared abstractly in a namespace. "Intersect" would be a function that finds the intersecting parts of its arguments.
Now when someone makes a new "that", they include code that knows how to intersect "that" with as many "this" types as they find useful. No original code needs to be changed. Later, someone working on "other thing" needs to intersect two types that no one has written intersection code for, so they write their own implementation that is applied to these two other pieces of code, and neither of them needs to be updated.
Complexity can quickly get out of hand, but it's also something that we've been thinking about for a long time. The more we learn about history, the more opportunities we have to find good solutions to new problems.
ynniv /
npub12a…x6fdh
2024-08-27 20:19:26
in reply to nevent1q…rxa2
Author Public Key
npub12akj8hpakgzk6gygf9rzlm343nulpue3pgkx8jmvyeayh86cfrus4x6fdhPublished at
2024-08-27 20:19:26Event JSON
{
"id": "5514e17736385eef90fcb3ab34457f798af1094bd3cc2e9d253e674cd06521cb",
"pubkey": "576d23dc3db2056d208849462fee358cf9f0f3310a2c63cb6c267a4b9f5848f9",
"created_at": 1724789966,
"kind": 1,
"tags": [
[
"e",
"65caebd5da15402977ab5704800248910b0950fa56489d35b15522d5fd47ce46",
"wss://theforest.nostr1.com/",
"root"
],
[
"e",
"3205c52926e84320f8f0d9217f7a0d88cb7f5d7fb7ef073681e6b059672b01d7",
"",
"reply"
],
[
"p",
"70122128273bdc07af9be7725fa5c4bc0fc146866bec38d44360dc4bc6cc18b9"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
]
],
"content": "This type of complexity is a common problem in object oriented programming. \"This\" type has a method that accepts a \"that\" type, and it works well until there are too many combinations of types. Any time a new \"that\" is created, the original code needs to be updated. This is where OOP reaches for interfaces, so the \"that\" type can be anything that claims to be a \"that\". This works well for even longer, but it still tends to fail at scale. Any time a new behavior is require, the interface changes and now every implementation needs to be updated. \n\nI have a soft spot for old systems, and one of them is Common Lisp. CL was standardized before OOP, and one of the ways it deals with this is multiple dispatch. Instead of \"this\" type of object having a method operating on \"that\" type, the function is declared abstractly in a namespace. \"Intersect\" would be a function that finds the intersecting parts of its arguments. \n\nNow when someone makes a new \"that\", they include code that knows how to intersect \"that\" with as many \"this\" types as they find useful. No original code needs to be changed. Later, someone working on \"other thing\" needs to intersect two types that no one has written intersection code for, so they write their own implementation that is applied to these two other pieces of code, and neither of them needs to be updated. \n\nComplexity can quickly get out of hand, but it's also something that we've been thinking about for a long time. The more we learn about history, the more opportunities we have to find good solutions to new problems.",
"sig": "f324c99e2ea942d938a0880af28023f7aedfdd1aa9f146ebea231b62da35c088048f03f342d8f173db66255e7b8ad2880467e9618117bc28df508b00baec8de5"
}