I don't know Erlang, so I might be missing something key here.
"I am thinking more and more that if would be nice to have all functions in a key_value database with unique names."
Yeah, sure... Sounds good, right. Until you have naming conflicts.
So then the patch is "oh, let's just add another column to make it more unique", without realizing that you've just, in essence, created a "module" of sorts except it's stored in some sort of giant key/value database.
And then you've come full-circle back to the dilemma the author complains of which is that he doesn't know where to put a function that seems to belong in two modules.
Eventually, I'd say this is a general failing of modules that could potentially solved by some sort of inheritance. Maybe even a tagging mechanism if you really want to be "patch-work joe" about it.
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.
Comments
I don't know Erlang, so I might be missing something key here.
"I am thinking more and more that if would be nice to have all functions in a key_value database with unique names."
Yeah, sure... Sounds good, right. Until you have naming conflicts.
So then the patch is "oh, let's just add another column to make it more unique", without realizing that you've just, in essence, created a "module" of sorts except it's stored in some sort of giant key/value database.
And then you've come full-circle back to the dilemma the author complains of which is that he doesn't know where to put a function that seems to belong in two modules.
Eventually, I'd say this is a general failing of modules that could potentially solved by some sort of inheritance. Maybe even a tagging mechanism if you really want to be "patch-work joe" about it.
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.
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.
In a third module, where else?