I have been using a “literal names policy” for naming everything I make in Elm. The result is:
This kind review reminded me that I haven’t talked about this policy in a while!
I wrote about it here because my goal is that the whole Elm community would use this policy as well.
When I create a package, I ask “What is this package for?” and the answer to that question is the name of the package. If I do not know what it is for, something has gone very wrong if I think it’s worth having other people review and possibly use this code!
This means we get
rtfeldman/elm-css, etc. You can immediately know what it’s for. No cute branding to sift through. The only real distinguishing feature of the name is the author. This is extremely important information! You are implicitly collaborating with the author, and it is important to trust their quality, stability, communication, etc.
Say you want to work with X. Which package for X is the best? The options should be:
alice/elm-X bob/elm-X chuck/elm-X
Rather than choosing the one with the best branding (like in JS often) you choose the author you trust most. Best track record. Best working relationship. Etc.
I think playfulness is definitely valuable in making engaging and fun packages, and a “literal names policy” means you cannot express that in the name itself. I think it is overall better if you express yourself in this way in the docs and examples. Make it fun to learn and use the package!
domino and having a fancy logo would provide some people with some instant gratification. “Wow, a neat pun!” You don’t have to think about anything too hard to appreciate it. But is the library actually any good?! The “clever” name distracts from the fact that you must review the API and docs to have any useful opinion about the package.
In other words, use playfulness to teach the library, not to distract from the technical content.