Okay, let's try to not shit all over new ideas here. If we take what Joe-from-2011 means instead of hallucinating him to be incompetent...
Let's re-word "all functions in a database" as "a revision control system in a database."
So, let's make a revision control system. All contents, branches, tags are kept in a database.
Sounds good, right. Until you have naming conflicts.
No, no, no. There are no naming conflicts. The names humans will use are just pointers to the most recently updated underlying contents. The _actual_ names are garbage hash identifiers. The _usable_ names are human names bound to underlying contents.
So, if master is commit A and you make commit B, there is no naming conflict on the name "master," you just re-point it to commit B.
a function that seems to belong in two modules.
That's the problem with explicit hierarchy and why the world now runs on tagging-based crowdsourced folksonomies.
"A revision control system in a database"? A revision control system is a database. I think what you and the author are trying to get at is some sort of "docker, but for functions" type of thing. And we all know what a mess that is when it comes to public docker images.
"No, no, no. There are no naming conflicts. The names humans will use are just pointers to the most recently updated underlying contents. The _actual_ names are garbage hash identifiers. The _usable_ names are human names bound to underlying contents.
So, if master is commit A and you make commit B, there is no naming conflict on the name "master," you just re-point it to commit B."
"Master" is the actual name that is going to be conflicting, if I understand your example.
> "Master" is the actual name that is going to be conflicting...
Yes, but... Just like in git, "master" points to one and only one commit, but the pointed-to commit might be different in the future. The name of each commit is a guaranteed-unique-for-the-forseeable-future hash of the contents of each commit. That name never, ever changes.
If you want a particular commit, you use its unique, non-human-friendly name. If you just want a particular branch and don't care too much about any particular commit, you use its collision-prone human-friendly name. Naming of branches and/or projects is still going to be "hard". Naming of particular releases/versions of code is not.
Let's re-word "all functions in a database" as "a revision control system in a database."
So, let's make a revision control system. All contents, branches, tags are kept in a database.
Sounds good, right. Until you have naming conflicts.
No, no, no. There are no naming conflicts. The names humans will use are just pointers to the most recently updated underlying contents. The _actual_ names are garbage hash identifiers. The _usable_ names are human names bound to underlying contents.
So, if master is commit A and you make commit B, there is no naming conflict on the name "master," you just re-point it to commit B.
a function that seems to belong in two modules.
That's the problem with explicit hierarchy and why the world now runs on tagging-based crowdsourced folksonomies.