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.
My brother - wise in the ways - once said "programmers are obsessed with trees".
It's true.
Spare yourself - when you find your mind has been taken over and you have become obsessed by some sort of tree problem/challenge, snap out of it, go do something useful that will make you much happier than the "I kinda got it to do what I wanted", but knowing in your heart it never worked as nicely as you would have hoped outcome.
When another programmer starts talking about trees and becoming obsessed with some tree thing, show compassion much as you would to a very ill friend - be understanding and gentle and know they cannot help it - it is a disease of the mind and with care and rest their tree obsessed project will pass and they will return to real programming.
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.
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.
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.
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.
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.
It's true.
Spare yourself - when you find your mind has been taken over and you have become obsessed by some sort of tree problem/challenge, snap out of it, go do something useful that will make you much happier than the "I kinda got it to do what I wanted", but knowing in your heart it never worked as nicely as you would have hoped outcome.
When another programmer starts talking about trees and becoming obsessed with some tree thing, show compassion much as you would to a very ill friend - be understanding and gentle and know they cannot help it - it is a disease of the mind and with care and rest their tree obsessed project will pass and they will return to real programming.
Are these two things actually the same thing, or they separate?
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
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