I think I've always called this "Ontology is hard". It's genuinely useful when it's used as a tool for clarification. It's constraining when it's used as a tool for modeling.
The Third Hard Problem
31–40 of 70 posts
Re: The Third Hard Problem
#32Earlier quoted context omitted.
there are actually 10 problems: naming things, cache invalidation, base conversions, off by one errors, and cache invalidation
Base conversions are easy, but which off by one is it? base 4 or base 6?
10 base 2 is 2 base 10. i gave four unique hard problems. and now typing this out i see that I was off by 1 (or two)
Re: The Third Hard Problem
#33Well elucidated. This problem has irked me for years in the form of multiple inheritance. When it's disallowed (like Java, unfortunately), trying to reduce a directed graph structure to a single dominant hierarchy is quite the bothersome choice.
Re: The Third Hard Problem
#34I have a deep distrust of hierarchies, because they keep you trapped into a single model that keeps extending its authority, usuall without anyone explicitly deciding that it should do so. For example, the file system: once it was deemed hierarchy is the main metaphor for navigation, the structure persisted and was reused for organisation, ownership, access control and governance. And it became infrastructure we cann…
IMO hard links are underused in filesystems. You can have the same file / dir appear in different places under different names. Once linked, app doesn't have to care and runtime cost is zero.
Re: The Third Hard Problem
#35Every few years I watch, with amusement, our management restructuring the organizational hierarchy, allegedly because the old one didn't work.
Maybe allegedly so but in reality it worked once again, given there’s still management to be reorganised.
Re: The Third Hard Problem
#36For me, the canonical example is organising images in folders vs tags.
Re: The Third Hard Problem
#37I doubt there would exist a perfect taxonomy for everything. Taxonomies are subjective to individuals but somehow can be (ahem! AI) mapped relative to someone else’s preference taxonomy. What efficiency and meaning each individual (or organization or community) yields would be completely different.
Re: The Third Hard Problem
#38I have always called this the “one true taxonomy” problem, because whenever you sit with multiple stakeholders in a room talking about a taxonomy, you can never get to agreement, because there is no such thing as the “one true taxonomy”. Any hierarchical taxonomy classifies on one dimension at each taxonomic level. Invariably someone wants to classify on one criteria when someone else wants to classify on another. Ta…
> Then, I go back to the implementers and tell them to design in a tagging system, which is a DIY taxonomy, and except in ridiculous use cases, I can make indexes make it fast enough to let everyone overlay their own classification system.
This 100x! I wish this were more common.
The key property of a tree is that there a unique path (address) for each element, which is a useful property in the implementation layer. But forcing that on users is a horribly leaky abstraction.
Ideally separate the low-level implementation from the interface, and allow users their own way to address content. I imagine object storage (with UUIDs or whatever) is often good enough for the lower layer. For the interface layer, tags are an improvement on categories (tree structure), but I think there's also room for more innovation (fuzzy matching, AI-driven interfaces, etc) that start by allowing trading-off precision for recall but then allow regaining precision by adding more approximate qualifiers to the filtering.
----
PS: Pushing this approach to 11/10...
An intriguing (crazy?) application of this idea would be: what if we did this to the concept of a codebase? Make it a database (with all the corresponding improvements over a filesystem) -- it's no longer a tree of files, and allow users to query code like "that foo which accepts a bar, frobnicates its internal state, and emits a mutated baz". Note that this might also solve the "naming things" problem.
This setup seems like a powerful abstraction for AI coding agents. All that back-end power (database >> filesystem) is something they can easily leverage, and they can also be built to robustly resolve your fuzzy queries into precise addresses, and then update the code based on your desired outcome.
Re: The Third Hard Problem
#39There are only two hard problems in computer programming: 1. Naming things 2. Cache invalidation 3. off-by-one errors
Length 3 lists always feel better, and my favorite formulation of this is,
There are only three hard problems in computer science:
1. Naming things
2. Cache invalidation
3. Off-by4. Multi-threading
-one errors.Re: The Third Hard Problem
#40I have a deep distrust of hierarchies, because they keep you trapped into a single model that keeps extending its authority, usuall without anyone explicitly deciding that it should do so. For example, the file system: once it was deemed hierarchy is the main metaphor for navigation, the structure persisted and was reused for organisation, ownership, access control and governance. And it became infrastructure we cann…
> before we could even question if it was right or not
But we could. Early filesystems didn't have heirachy. They'd sometimes support a single level of organization by treating a prefix of the filename as directory, but nothing below that. We looked at that and considered heirarchy better.
What you lament is that we stopped with heirarchy. You wish for something more general, and that you have received. With hardlinks and ACL the filesystem is freed from its shackles of heirarchy. Most people don't need that most of the the time.
The strict heirarchy sits as the third step of a complexity ladder. The reason we stopped there, in most cases, is that it's enough complexity.