4 ms·

Wikipedia is probably the most prominent example of a flat namespace that works at scale. But those names are pretty long, particularly when they need to disamb

Wikipedia is probably the most prominent example of a flat namespace that works at scale. But those names are pretty long, particularly when they need to disambiguate. Also, it's an encyclopedia where article editors are forced to collaborate, and it's leveraging large vocabularies that already exist. (One for each language.) For programming languages, even with a flat module namespace, you get a land rush where good names get taken early by packages that might end up unpopular or abandoned. Leveraging DNS seems like the answer. Java did it badly, but Go's approach seems fine, perhaps because it leverages GitHub's namespace too (for most modules).

PaulDavisThe1st 3y ago
What's the difference between /Wheel of Time /TV Series/Wheel of Time /Video Game/Wheel of Time and /Wheel of Time /Wheel of Time (TV Series) /Wheel of Time (Video Game)
- Terr_ 3y ago
  Yeah, the non-flat hierarchy/tagging may be informal, but it still exists. (And for good reason.)
- dgb23 3y ago
  I like the second one better. In programming, it’s useful to have namespaces for overall organization and conflict resolution. But it’s a trade off: you are nudged into a hierarchical ontology, with all the implied issues. Wikipedia titles are free text (more or less). So they can afford not to introduce hierarchical naming and still have nice, easily addressable names without conflicts. This avoids all sorts of problems. Most things simply can’t be categorized in a strict, hierarchical manner.
- aragonite 3y ago
  I'd argue that "mental anguish" is probably less of a problem on the latter design, since the additional parenthetical material is used pure for disambiguation (and so is optional), not for categorization. So, on the latter design we can have: /Francis Bacon /Francis Bacon (artist) without having to answer anguish-inducing questions that would be raised by /Francis Bacon /artist/Francis Bacon e.g. questions such as: 1. "Maybe we should put Lord Bacon under a category also, maybe `philosopher/Francis Bacon`" 2. "But he's also a statesman ... what about `statesman/Francis Bacon`? Is he more of a philosopher or a statesman"? 3. What about ordinary people (who happen to be involved in historical events) that have wikipedia entries, like George Floyd? Should he be assigned something like `person/George Floyd`? If so, should the two Francis Bacons be assigned `person/philosopher/Francis Bacon` and `person/artist/Francis Bacon` instead? And so on
  - dgb23 3y ago
    That’s exactly right. And this is not just a “mental anguish” or “skill issue”. It’s a fundamental issue: Hierarchical naming and categorization sucks. In 95% of the cases, you want sets or even graphs rather than trees. You _might_ be getting away with trees, because you didn’t encounter a case where the hierarchy breaks. But you’re being fooled by happenstance. In the 5% of cases where trees are fine, you could also use sets or graphs. This issue comes up all the time with all sorts of things, including urls and file structure. The trick is to have a general “/type/name” format and to be as liberal and general as possible with what “type” means.
- ttctciyf 3y ago
  Practically speaking, when you want to link to the latter in a markdown that already utilises parens, you encounter more friction - cutting and pasting a url with parens from the address bar needs manual correction if used to create a link in (say) reddit's markdown syntax. I realise this is somewhat tangential to your point, but shows how easy it is for innocent looking choices to end up creating annoyances.
tsimionescu 3y ago
> Leveraging DNS seems like the answer. Java did it badly, but Go's approach seems fine, perhaps because it leverages GitHub's namespace too (for most modules). O the contrary, Go's approach will lead to lots of problems while Java's is actually simpler and safer. The fact that you depend on the current status of DNS every time you build your code, for each and every one of your dependencies, including transitive ones, is completely nuts. Even Google realized this, and they solved it Google style: they added another automated system on top to try to add some stability (the Go proxy). And then they had to add holes to that system, because it turns out not all dependencies are public and so they can't solve this from on high (GOPRIVATE). And still, if one of your dependencies decides to switch hosting provider for their source code, or loses their domain name, you have to make (small) changes in every code file that referenced that dependency. Maven's solution is much simpler for everyone involved: DNS is only involved in registering a new module, it only serves as a form of authentication. After the initial registration, the module name is allocated to your Maven Central account, and it won't be revoked if you later lose that domain. If someone gets access to your domain, they don't also automatically become able to push malware to people who used your module for years, neither retroactively (which Go also handles) nor when they next upgrade (which Go will happily allow).
- MrBuddyCasino 3y ago
  Been trying to make this point several times now, they always doubt that this problem has been solved, and by Maven of all places. The NIH syndrome is for some reason rampant among package managers/registries.
- skybrian 3y ago
  I'm not sure Go works that way. Are you confusing 'go get' (downloading code) with compiling code? Maven and Gradle are part of the reason I don't use Java anymore. Java seems to have gone through multiple unfortunate build systems without settling on a good one.
  - tsimionescu 3y ago
    I was thinking more of a CI pipeline build, which would probably do `go mod download`. You're right of course that `go build` itself doesn't download code itself. What is it about Maven that you think makes it not a good build system? To me, I moved from Java to Go and I still miss Maven to this day.

PaulDavisThe1st 3y ago

What's the difference between /Wheel of Time /TV Series/Wheel of Time /Video Game/Wheel of Time and /Wheel of Time /Wheel of Time (TV Series) /Wheel of Time (Video Game)

Terr_ 3y ago
Yeah, the non-flat hierarchy/tagging may be informal, but it still exists. (And for good reason.)
dgb23 3y ago
I like the second one better. In programming, it’s useful to have namespaces for overall organization and conflict resolution. But it’s a trade off: you are nudged into a hierarchical ontology, with all the implied issues. Wikipedia titles are free text (more or less). So they can afford not to introduce hierarchical naming and still have nice, easily addressable names without conflicts. This avoids all sorts of problems. Most things simply can’t be categorized in a strict, hierarchical manner.
aragonite 3y ago
I'd argue that "mental anguish" is probably less of a problem on the latter design, since the additional parenthetical material is used pure for disambiguation (and so is optional), not for categorization. So, on the latter design we can have: /Francis Bacon /Francis Bacon (artist) without having to answer anguish-inducing questions that would be raised by /Francis Bacon /artist/Francis Bacon e.g. questions such as: 1. "Maybe we should put Lord Bacon under a category also, maybe `philosopher/Francis Bacon`" 2. "But he's also a statesman ... what about `statesman/Francis Bacon`? Is he more of a philosopher or a statesman"? 3. What about ordinary people (who happen to be involved in historical events) that have wikipedia entries, like George Floyd? Should he be assigned something like `person/George Floyd`? If so, should the two Francis Bacons be assigned `person/philosopher/Francis Bacon` and `person/artist/Francis Bacon` instead? And so on
- dgb23 3y ago
  That’s exactly right. And this is not just a “mental anguish” or “skill issue”. It’s a fundamental issue: Hierarchical naming and categorization sucks. In 95% of the cases, you want sets or even graphs rather than trees. You _might_ be getting away with trees, because you didn’t encounter a case where the hierarchy breaks. But you’re being fooled by happenstance. In the 5% of cases where trees are fine, you could also use sets or graphs. This issue comes up all the time with all sorts of things, including urls and file structure. The trick is to have a general “/type/name” format and to be as liberal and general as possible with what “type” means.
ttctciyf 3y ago
Practically speaking, when you want to link to the latter in a markdown that already utilises parens, you encounter more friction - cutting and pasting a url with parens from the address bar needs manual correction if used to create a link in (say) reddit's markdown syntax. I realise this is somewhat tangential to your point, but shows how easy it is for innocent looking choices to end up creating annoyances.

tsimionescu 3y ago

> Leveraging DNS seems like the answer. Java did it badly, but Go's approach seems fine, perhaps because it leverages GitHub's namespace too (for most modules). O the contrary, Go's approach will lead to lots of problems while Java's is actually simpler and safer. The fact that you depend on the current status of DNS every time you build your code, for each and every one of your dependencies, including transitive ones, is completely nuts. Even Google realized this, and they solved it Google style: they added another automated system on top to try to add some stability (the Go proxy). And then they had to add holes to that system, because it turns out not all dependencies are public and so they can't solve this from on high (GOPRIVATE). And still, if one of your dependencies decides to switch hosting provider for their source code, or loses their domain name, you have to make (small) changes in every code file that referenced that dependency. Maven's solution is much simpler for everyone involved: DNS is only involved in registering a new module, it only serves as a form of authentication. After the initial registration, the module name is allocated to your Maven Central account, and it won't be revoked if you later lose that domain. If someone gets access to your domain, they don't also automatically become able to push malware to people who used your module for years, neither retroactively (which Go also handles) nor when they next upgrade (which Go will happily allow).

MrBuddyCasino 3y ago
Been trying to make this point several times now, they always doubt that this problem has been solved, and by Maven of all places. The NIH syndrome is for some reason rampant among package managers/registries.
skybrian 3y ago
I'm not sure Go works that way. Are you confusing 'go get' (downloading code) with compiling code? Maven and Gradle are part of the reason I don't use Java anymore. Java seems to have gone through multiple unfortunate build systems without settling on a good one.
- tsimionescu 3y ago
  I was thinking more of a CI pipeline build, which would probably do `go mod download`. You're right of course that `go build` itself doesn't download code itself. What is it about Maven that you think makes it not a good build system? To me, I moved from Java to Go and I still miss Maven to this day.