Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Third Hard Problem

mmapped.blog

Post reply on HN
Print view View original

51–60 of 70 posts

Re: The Third Hard Problem

#51

Post by gobdovan »

delusional wrote: post #40
gobdovan wrote: post #28

I 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 hardlink…

You're overfitting on the filesystem example. My point is model lock-in.

Once a system commits to one hierarchy, it becomes very hard to introduce another authoritative model. Not only you cannot have alternative models with equal authority, you do not even get a clean parallel hierarchy later; you get the first hierarchy, now ossified, plus workarounds around it. On the other hand, webs are harder to reason about and more expensive to operate, but they can produce hierarchies 'on-demand' and you can get rid of them as easily as you've established them. Ergo, a ton of different programming languages just compile to LLVM IR.

Re: The Third Hard Problem

#52

Post by designerarvid »

efitz wrote: post #30

I 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…

That’s a good name! I often resort to “there are many ways to slice a cake”, less sophisticated blunt gets the point across.

Re: The Third Hard Problem

#55

Post by frogulis »

ssivark wrote: post #38
efitz wrote: post #30

I 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 .…

> that foo which accepts a bar, frobnicates its internal state, and emits a mutated baz

Tangential, but that reminds of the Haskell "hoogle" tool which allows searching for functions _by type_ across a large database of libraries, even by abstract types. So you might wonder "hmm what's that function that has a type structure like `t a -> (a -> t b) -> t b`?" and it'll happily tell you that it's monad `bind`

Re: The Third Hard Problem

#56

Post by sdwr »

chaboud wrote: post #12

The problem with trees is that the are a dimensional reduction, an aggregation; taking a problem without directionality and applying a useful/functional hierarchy. 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…

The map is not the territory!

Re: The Third Hard Problem

#57

Post by cxr »

This is an independent riff on an argument Ted Nelson wrote down 50 years ago (and the reason why he coined the term "hypertext").

https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines>

http://link.springer.com/10.1007/978-3-319-16925-5>

Re: The Third Hard Problem

#58

Post by EGreg »

This an issue of growing ontologies and taxonomies.

I have found that the best answer I have is:

1) Gossip and use the existing ontology and add new items only if genuinely needed

2) Combine synonyms, sometimes using vector embedding and cosine similarity during search

The insight is that trees are not a storage constraint but a traversal consequence — any walk through a graph starting from a given node produces a tree as a byproduct, and different starting points or orderings produce different trees from the same underlying structure. Rather than forcing a choice of canonical hierarchy at write time (the dentist-bill-goes-in-which-folder problem), you store the graph and let the tree emerge lazily from context: whoever is querying, from wherever they enter, gets the tree that is relevant to them, and no connections are sacrificed to produce it.

In general, federated systems have this quality emerge. For example, in OpenStreetMap, one group can label Nagorno Karabakh, the other Artsakh, and no one has to fight Google etc.

Re: The Third Hard Problem

#60

Post by jmalicki »

lstodd wrote: post #48
PhilipRoman wrote: post #47

Earlier quoted context omitted.

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.

It's the fundamental idiom of how to do atomic file replacement. The sever process had better be doing that over editing a text file in a way that could leave it invalid if the process OOMs mid edit, or another process is reading it while it's being written.
Post reply on HN