Live data from Hacker News

The Third Hard Problem

mmapped.blog

61–70 of 70 posts

Re: The Third Hard Problem

#61
post #38
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 .…

Tag Clouds were sticky tasty web goodness a few years back.

I've got a legacy tag cloud curation tool for random collections (each collection gets its own id) of URLs. It IFRAMEs each URL to present it; no whining. I've used it for classifying technical docs, photo libraries (then I used the tags to train an image classifier), and to present an analysis of a customer's web site.

It's written in Perl, and (still) runs on modern Perl. Make friends and maybe I'll toss the code your way and help you with your project.

Re: The Third Hard Problem

#62
post #49
post #32

Earlier quoted context omitted.

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)

Off-by-two is a subset of all possible off-by-one errors.

All off-by-one errors can be reproduced by producing an off-by-one error of some other off-by-one error.

Re: The Third Hard Problem

#63
post #48

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.

I'd agree if POSIX provided something like an open() flag which made the changes visible atomically, but as it stands, the rename() idiom is the mainstream way of durable file writing, so it is commonly used. Practical example using busybox sed: (GNU sed detects this case and refuses to overwrite)

  / # stat /dev/null
    File: /dev/null
    Size: 0          Blocks: 0          IO Block: 4096   character special file
    ...
  / # sed -i 's/foo/bar/' /dev/null
  / # stat /dev/null
    File: /dev/null
    Size: 0          Blocks: 0          IO Block: 4096   regular empty file
    ...

Re: The Third Hard Problem

#64

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…

Here is my take using the city as a metaphor.

All physical things have to be arranged in a linear fashion, this is pauli exclusion principle writ large.

A type of mereological nihilism is true, so hierarchy is real but in a weak emergence sense.

When I am standing on a street corner in a city, I can walk into a building and then navigate into a room inside that building and pick up a piece of paper inside.

Or I can walk down the street and as I pass landmarks, I will pass things in order, this is also a perceived hierarchy, because my starting position and movement are bound by time, I will always have a fixed order of experiences from any x,y coordinate.

So everything bounded by time and space acts as an emergent hierarchy via movement for a specific loci.

The paper can be moved however, and that same piece of paper sitting in the drawer at an attorneys office means something very different than when its sitting in the approved licenses cabinet in an offical government building.

Semantic meaning is first class but its an entirely different dimension than other types of meaning and due to pointers it isn't bound by pauli exclusion.

When people start thinking about the semantics of objects in computer programs they often become confused, because the semantic representation of the object follows semantic ontology laws not physical object ontology.

People can fuck this up in either direction and think physical laws apply to semantic meaning or physical meaning applies to semantics.

Re: The Third Hard Problem

#65
post #14

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

Another interesting type of tree is the multitree. Try this very readable paper:

https://interactivity.ucsd.edu/articles/In_Process/MultiTree...

Re: The Third Hard Problem

#66

There 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.

My favorite version of this but is like "An engineer has one problem he decides to solve with multi-threading. Now problems. has two he"

Re: The Third Hard Problem

#67

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…

Here is my take using the city as a metaphor. All physical things have to be arranged in a linear fashion, this is pauli exclusion principle writ large. A type of mereological nihilism is true, so hierarchy is real but in a weak emergence sense. When I am standing on a street corner in a city, I can walk into a building and then navigate into a room inside that building and pick up a piece of paper inside. Or I can w…

Yeah, that's part of it. But I'd argue that once you look at a city, you look at constructions administratively designed by men, with their preference for hierarchies. Try to hierarchically describe to someone instructions to pick a random leaf in a dense tree (ironically, we use them as a metaphor for hierarchical organisation) and see how far you could go in the same way you could point them out to pick a paper in the city.

Not in a position to argue about physics, but I could think of quite a few things that are better described as web-like phenomena rather than hierarchical ones, electricity in a complex circuit comes to mind.

Re: The Third Hard Problem

#68
post #38
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 .…

There's some prior work on the codebase thing:

[Unison](https://www.unison-lang.org/docs/the-big-idea/) content addresses every definition. Kinda interesting.

A [Code Property Graph](https://en.wikipedia.org/wiki/Code_property_graph) takes a codebase and turns it into three graph representations: it's AST, a Control Flow Graph, and Program Dependence Graphs. These graphs are overlaid and shoved into a single property graph. It's a structure mainly used by some static analysis tools like [Joern](https://joern.io/)

---

This has been a topic of a lot of interest and research for me. I've been experimenting with figuring out a system inspired by these ideas, among others, to apply the same idea (shoving multiple graph representations together) to a broader set of information

Re: The Third Hard Problem

#70
post #7
post #5

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

Yes, I found the same and was very pleasantly surprised when I first learned about the ideas of cubical type theory.
Post reply on HN