The problem with trees is that the are a dimensional reduction, an aggregation; taking a problem without directionality and applying a useful/functional hierarchy.
So a tree is a way to take a high dimensionality graph and make it usefully lower dimensionality, but, given the aforementioned proof, that reduction is going to go from being a lossless compression to a heuristic. So any interesting problem (at least, any problem interesting to me) is only going to be aided (read: not solved exhaustively) by that hierarchy.
I'm okay with this. Being okay with this has been one of the most freeing things over the last 20 years of my career. Accept inaccuracy, and find usefulness in your data structures.
I think all three problems are really one problem under the hood:
Are these two things actually the same thing, or they separate?
tikhonj 2 hours ago [-]
Reminds me of my favorite math essay: "When is one thing equal to some other thing?"
It's a great question, much deeper and more interesting than it seems. The essay suggests thinking in terms of isomorphisms (relative to the structure you care about) rather than equality in some absolute sense, and I've found a fuzzy version of that to be a really useful perspective even in areas that can't be fully formalized.
I jumped to a similar conclusion right away and popped over here to comment only to find you have beaten me to the punch. I use to keep a work wiki page of common problems the team encounters over and over again.
Years ago, I stumbled upon the "idea" was already debated in other fields long before programming. Lumpers and Splitters.
Wow, thanks for that, TIL! I’m definitely a code lumper.
hexasquid 60 minutes ago [-]
"Ambiguity is the enemy", as a rule of thumb, has helped me
aleksiy123 2 hours ago [-]
Or non binary. How much are these the same and how.
tonetheman 2 hours ago [-]
[dead]
petersumskas 19 minutes ago [-]
There are only two hard problems in computer programming:
1. Naming things
2. Cache invalidation
3. off-by-one errors
sprayk 16 minutes ago [-]
there are actually 10 problems: naming things, cache invalidation, base conversions, off by one errors, and cache invalidation
QuaternionsBhop 11 minutes ago [-]
Base conversions are easy, but which off by one is it? base 4 or base 6?
2 hours ago [-]
mcphage 3 hours ago [-]
I thought the two hard problems were naming things, cache invalidation, and off-by-one errors?
rectang 2 hours ago [-]
At least the title “The Third Hard Problem” is still appropriate regardless of whether you get the joke right.
fragmede 3 hours ago [-]
Don't race forget conditions!
cheschire 2 hours ago [-]
His message was submitted before the memory recall completed execution.
ToniDoni 3 hours ago [-]
I thought it was timezones.
kator 2 hours ago [-]
I wonder whether the author deliberately avoided ontology? That's what comes to mind when I read this. The age-old debate between taxonomy and ontology.
jeffbee 1 hours ago [-]
The first chapter of this waves away the fact that hierarchical filesystems are now useless, but it is still a fact. There is no more reason to organize your files than there is to drive around in a chariot. It is hard to map one domain to the other, but it is also not necessary. With AI indexing and recall it's less necessary than it has ever been.
g8oz 1 hours ago [-]
This seems optimistic.
Svoka 2 hours ago [-]
Putting object into trees is basically a caching problem.
recursivecaveat 2 hours ago [-]
I was thinking it's a naming problem haha, a file path can be seen as a global/fully-qualified name really.
aleksiy123 2 hours ago [-]
Use multiple trees.
adampunk 3 hours ago [-]
This is more true as stated than people want to give credit for, usually.
Rendered at 02:45:07 GMT+0000 (Coordinated Universal Time) with Vercel.
And that's a problem because Aggregability is NP-Hard: https://dl.acm.org/doi/abs/10.1145/1165555.1165556
So a tree is a way to take a high dimensionality graph and make it usefully lower dimensionality, but, given the aforementioned proof, that reduction is going to go from being a lossless compression to a heuristic. So any interesting problem (at least, any problem interesting to me) is only going to be aided (read: not solved exhaustively) by that hierarchy.
I'm okay with this. Being okay with this has been one of the most freeing things over the last 20 years of my career. Accept inaccuracy, and find usefulness in your data structures.
Are these two things actually the same thing, or they separate?
It's a great question, much deeper and more interesting than it seems. The essay suggests thinking in terms of isomorphisms (relative to the structure you care about) rather than equality in some absolute sense, and I've found a fuzzy version of that to be a really useful perspective even in areas that can't be fully formalized.
https://people.math.osu.edu/cogdell.1/6112-Mazur-www.pdf
Years ago, I stumbled upon the "idea" was already debated in other fields long before programming. Lumpers and Splitters.
https://en.wikipedia.org/wiki/Lumpers_and_splitters
1. Naming things 2. Cache invalidation 3. off-by-one errors