One nice tool for analyzing maps as a tree is as a dominator trees. I wrote a bit about it here: https://neugierig.org/software/blog/2023/07/dominator.html
Thank you for sharing, first I've heard of this tree type.
The Third Hard Problem
41–50 of 70 posts
Re: The Third Hard Problem
#42I think all three problems are really one problem under the hood: Are these two things actually the same thing, or they separate?
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. http…
Mathematics is all just explanations for why this is really that. If it didn't have to respect its human audience, and their failure to grasp similarities, the whole edifice could be one implicit statement. (After all, since this is really that, there is no this or that.) So mathematics is about people.
Re: The Third Hard Problem
#43This is good diagnosis of the problem. I found that often the right solution is to ditch the hierarchy and use flat structure. I wrote about this some time ago: https://yoyo-code.com/embrace-flatness/
Big insight in that article is also from https://matklad.github.io/2021/08/22/large-rust-workspaces.h... about structuring large rust workspaces as a flat list.
Re: The Third Hard Problem
#44John Ousterhout has also written about this in A Philosophy of Software Design:
The most fundamental problem in computer science is problem decomposition: how to take a complex problem and divide it up into pieces that can be solved independently.
Re: The Third Hard Problem
#45Every 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.
Well, tell that to my management, that it's a pointless endeavor. The structure of (required) social relations in the workplace is a graph; so there will always be some flaw when trying to conform this into a tree.
Re: The Third Hard Problem
#46I 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…
More than once I encountered a project lead (often a higher-up) spend a half day after the project kick-off to create an elaborate folder structure for the team.
Younger me wondered: "Don't they have more important things to do? Why do they never delegate such a menial and boring task, especially when the structure is kind of obvious"
Today it makes total sense to me. Even if it looks obvious no one has the exact same hierarchy in mind. It was fast for them to materialize the hierarchy themselves than to convince anyone about it in every detail. Some things just can't be delegated.
Re: The Third Hard Problem
#47I 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.
Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results.
This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used rename-style writing on /dev/null)
Re: The Third Hard Problem
#48Earlier quoted context omitted.
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.
Hard links suffer from the general issue of there being two styles of writing to a file - open(2)/write(2) vs rename(2). Depending on the internals of each program you use to update the file, you will get very different results. This is one of the ugliest parts of POSIX design, making idioms like -o /dev/null and file attributes unpredictable (I've had a server run out of disk space because a root-owned process used…
That was breakdown on a different level: your server process had no business of renaming stuff and it still did that. POSIX had nothing to do with this.
Re: The Third Hard Problem
#49Re: The Third Hard Problem
#50Use multiple trees.
The tree node on the UI should not only expand downwards but sideways and in-out of the screen.