The best, most obvious for an Elm GraphQL package is elm-graphql. I agree that there exists a second-best name that is not quite as good, but still descriptive. Also a third-best, and so on. A long tail.
If the naming policy is “come up with a name that is short, descriptive, and has never been used before” then the first person to ever publish an Elm GraphQL package gets elm-graphql and everyone else after that has a harder job - come up with a name that’s still short and descriptive, but which none of the N package authors who came before thought of - and the end result is still a less descriptive name than elm-graphql.
What a thankless, unrewarding job, compared to having it be okay to choose elm-graphql!
To be maximally successful in a naming system like that, you have to be first to publish. (When I realized elm was not taken on npm I told Evan he needed to grab it immediately before someone else took it, even though there was no installer to publish yet.) This very directly rewards work that’s done quickly over work that’s done carefully, which is a really damaging incentive to create for an ecosystem.
Given this, it’s no wonder people throw up their hands and start using animal names! If you can’t win on clarity because others already took the best names, optimize for personal gratification instead. It seems to me that the ineveitable result of a “come up with a short, unique, descriptive name” policy is packages with names that have no relation to what they do. The incentives push package authors toward that outcome.
What happened in npm will happen in Elm unless we take steps (like the “choose obvious names” policy) to avoid it.
The leftpad problem was that an author unpublished a package, breaking everything that depended on it.
The leftpad problem was that an author unpublished a package, breaking everything that depended on it.
What does that have to do with naming?
The uniform naming policy relies on usernames forming canonical package names, and the leftpad situation was caused by similarly coupling packages to npm user accounts. The point is that neither usernames or user accounts should be treated as fixed or immutable; users should be able to change both, given that it’s tied to their idenity, but a package manager should also give a guarantee that dependencies will continue working. This guarantee is not possible with Elm’s current package system, and the uniform naming policy is predicated on the current system.
The uniform naming policy exacerbates the problem of lack of dependency guarantees by making it harder to get rid of the username namespaces, and it also exacerbates the other major problem of the current system, which is potential module name conflicts.
One more unaddressed concern is the relation of harder to type usernames and typosquatting by malicious packages. It’s a serious problem at npm’s scale, arguably much more so than undescriptive package names.
The whole discussion whether it’s more valuable to memorize package branding or author branding is a distraction in light of technical problems, but names like elm-graphql aren’t even that descriptive, much less perfect; I mean, some of the libraries with that name are query builders, others are code generators, and the name would also apply to utility libraries with an even more different scope.
You contradict yourself with the example of Elm; there isn’t a perfect but taken descriptive name that the name Elm would have been chosen in lieu of. A lot of projects don’t have obvious names, and a lot of random names are random just for stylistic reasons. It’s a silly just-so story that names like “axios” would be about perfect names being already taken instead of the authors, for instance, thinking that “axios” sounds cool, just like how Elm was ostensibly named.
Naming policy can’t move the needle on typosquatting. Good solutions give users indicators besides name as to the reliability of the package. (For example, which other packages are using it, download counts, etc.)
elm-graphql seems like a descriptive name for a package that lets you use GrahpQL in Elm!
Yes, and the OP in this thread is Evan’s explanation for why we shouldn’t do that in Elm.
This is a thread about naming.
If you’d prefer to discuss other things, I’d suggest starting a new thread!
Not sure what’s supposed to be inaccurate; npm allowed one way for users to break depedencies, but Elm currently allows the same way and more. It doesn’t matter how it’s done; a dependency author should not be able to simply break even projects pinned to a specific version. Go uses the same approach as Elm and recently had a prominent example of a user deleting their account, causing widespread breakage, and the username being taken over by a different user, raising obvious security concerns.
Naming policy can’t move the needle on typosquatting.
This is an unsupported assertion; making it easier to have typos makes it easier to typosquat.
elm-graphql seems like a descriptive name for a package that lets you use GrahpQL in Elm!
Not less so than a name like Graphqelm, and less so than a name that actually would describe the different scopes covered by “using”, such as code generation vs. query building vs. utility functions like dumping the schema.
Yes, and the OP in this thread is Evan’s explanation for why we shouldn’t do that in Elm.
The point was that there are other explanations to non-descriptive naming than descriptive names being taken; the latter arguably isn’t even that likely, since perfect or obvious names are a contrived idea.
This is a thread about naming.
If you’d prefer to discuss other things, I’d suggest starting a new thread!
It’s a thread about a naming policy predicated on the current flawed package management system, so the flaws are directly pertinent.
I quoted the inaccurate thing, said what was inaccurate about it, and linked to an article on what actually happened. I don’t know how I could be any clearer, sorry!
Agreed! It is currently possible for this to happen in elm-package today because we don’t have our own dedicated infrastructure yet; we are currently piggybacking off GitHub’s infrastructure, and GitHub allows renaming repos.
If we hosted packages on our own servers, this would no longer be a concern (unlike npm in the left-pad situation, there has never been an elm-package unpublish command) but of course building that infrastructure is a serious undertaking. Elm 0.19 lays some of the foundation for that project.
One thing I like about here, and the reason I prefer it to /r/elm, is that a lot of posters here have user ids that are their real names (well, I assume they are, maybe you all just made up fake names). On /r/elm people tend to use pseudonyms, took me quite a while to work out that Evan was ‘wheatbread’ or something like that.
So you could take this whole literal names concept further and say, publish packages under your real name, and create an identity on here with your real name. Who you literally are.
I’ve never said that leftpad wasn’t caused by unpublishing, and I’ve explained that the pertinent part of the comparison is dependencies not being guaranteed.
There’s a reason why sites like GitHub allow accounts to be deleted and usernames to be changed; it’s because people and their circumstances change, and they should be allowed to control their public identity. It’s not a package repo’s place to tell someone what they should be called. People might get divorced and not want to see their old name, or marry, or transition, or just grow out of a name, or need to hide, etc.
It seems to me there are arguments for both sides of this topic.
People may want to change their GitHub username for various reasons and want their packages to follow, sure, and they are free to do so. If dependencies need to be updated due to a change a package publisher wanted to make, be it the API, the name of it, or its accessibility, are all potential bi-products of relying on open source software in general right?
I think Evan understands that, and has chosen the route of literal naming to take advantage of the benefits he mentioned in his post, and one of the costs of that approach is relying on the stability of the package author.
As I read through the continued discussion, I think for me the real issue is that the Literal Names Policy is trying to apply a universal solution where it doesn’t necessarily need to. I can see cases where username/literal-package-name makes the most sense. I can also see case where a more branded package name makes more sense. Does there need to be a one-size-fits-all solution for this?
And as someone with a very common name, I wish I didn’t have to. I would
like to see whatever solution we end up with in the long run allow you to
choose the name you want, even if it is the same as someone else’s, much
like we currently allow for package names.
Please forgive the uninitiated first time post. I don’t understand what the problem is— people can create whatever github accounts they want, including organizations. I’m no github wizard, so apologies if I’m missing some obvious institutional knowledge.
That said, I was recently disappointed to see that Ian Mackenzie is in the process of shifting his opensolid/elm-geometry repo to his personal account. The opensolid naming is memorable, and is both easy to comprehend and is inviting to contributors and users to think big. This change also resulted in a dependency problem for at least one person, which resonates with me re. the aforementioned leftpad situation. I understand that he made this change based on discussion on this forum, so please remind yourselves of the real effect of this discussion; it’s not just bike-shedding.
“Literal names policy” is not an accurate name itself, since the focus of the policy is on uniformity, which is being conflated with literal or descriptive names; for example, the name Graphqelm is comparably descriptive to the prescribed elm-graphql.
The policy smacks of trying to dictate tastes; to highlight this, see this issue opened by @rtfeldman. Even though the stated goals are putting the focus on author reputation and code quality, the actual reason given for following the names policy is is that a non-uniform name would suggest a beginner author and not be worth looking at. In other words, it’s still judging packages by their name, but based on a policy instead of personal tastes, except that the policy seems to coincide with certain personal tastes.
It should also be pointed out that uniform names take away a chance for new packages to stand out by branding. It’s less of an issue when there’s a handful of packages, but if the scale of Elm packages would grow, no one would individually evaluate every package out of dozens or hundreds, especially not packages with little adoption, so a way to stand out by branding would be helpful.
Is this literal naming policy intended to be hard and fast, i.e. strict? I definitely see the advantages to it-- not so much for finding packages, but more when having a look at an unfamiliar project’s elm-package.json or perusing its code. At the same time, branding can be really nice. There should be a way to get the best of both worlds.
It seems to me that the issue of author recognition could be solved by utilizing github’s api to scrape top contributers for each repo and list them for each package on elm’s package site. A nice parametric search on the package site paired with an author/contributor statistics page would give people the tools they need to easily find the packages that best suits them, while giving authors the exposure they deserve.
The quality of branding, like everything, is a function of effort; it’s one more way for package authors to signal that work has been put into a package. These heuristics become more important at scale, where it’s infeasible to look at each package individually. Taking away branding just means putting more weight on other heuristics like adoption or author recognition, which disadvantages new authors, who in turn are important for a healthy growing ecosystem.
Choosing dependencies is a chore; no one wants to spend more time than necessary on it. There’s no reason to think that taking away branding will cause more attention to be paid when choosing dependencies; instead, it will shift attention to other heuristics. Bringing up code quality is a red herring; even @rtfeldman talks about negative heuristics when trying to get projects to conform, and this is when there still are just a few packages, so it’s feasible to look at them all. Elm itself is not being renamed to evancz/functional-frontend-language; just trying to think of an “obvious” name for Elm shows that the notion doesn’t make sense.
Same goes for the issue of memorability; usernames are not very memorable, and the more likely effect of this policy is just more packages being forgotten, not users training their memory for usernames.
I agree branding quality can be an indicator of package quality / utility, but I am not sure it is a very reliable correlation. Particularly here where we are simply talking about branding by way of package naming. There is plenty of opportunity to brand through associated web content, documentation, tutorials, support etc. That to me is where ‘branding’ if you want to call it that, gives useful clues when contemplating using a package.
And let’s not forget that github allows ‘organizations’ as ways of grouping and branding individual user accounts. These can be incorporated into the ‘author’ part of an elm package name, which is what I have done with elm-vega. This allows a degree of branding, keeps to the utilitarian elm naming convention and importantly, allows for multi-author contributions to elm-packages.
Does anyone know of a community other than Elm that is trying to follow a policy like this?
None of the communities I’m involved with do this (except Elm). I would like to research and learn from their experience.
It seems healthy for package users to choose reputable packages by default.
If someone develops a breakthrough novel approach, it won’t need branding to stand out. It’ll make a name for itself through early adopters sharing their experiences!
As a lifelong lover of experimentation, I have confidence that my fellow experimenters won’t be discouraged by the prospect of having to earn a reputation on the merits of our work.
That’s the goal, yeah! Heursitics like reputation in the short term, and longer term, heuristics we don’t have the infrastructure to offer yet - e.g. which other packages depend on them, usage statistics, etc.
How about some experimentation with the package website? Several concepts are conflated in this discussion— package name comprehension, ease of package discovery, package memorability, and author credibility and due credit. These things could easily be addressed separately via better presentation on elm’s package site.
