It may be worth looking at the guidelines for naming packages, which tend to favor explicit names.
Edit: This topic was spun off [ANN] Shrike.jl: Julia beats optimized C++ (Fast accurate approximate nearest neighbor search) - #2
Look at the list of top packages at https://juliaobserver.com/packages and you’ll see that Shrike.jl fits right in.
Yeah but look at other pages. https://juliaobserver.com/packages?page=4
I think the explicit naming convention is a good one. It makes the package easier to find and makes code that uses it more readable. If there is already another package in the space, like Plots.jl, then another name may be needed, like AbstractPlotting.jl (as mentioned in the guidelines).
This is a matter of taste. For example, I prefer the name Makie over Plots. Pedestrian, dull, explicit names. Or flamboyant, memorable names. At least leave room for both.
5 Likes
I guess my taste is to follow the guidelines 
Anyway, maybe someone else has more useful feedback than I do. Mods feel free to split this tangent off.
This doesn’t seem to violate the the guidelines at all, which mention, for example, Gadfly and Winston as fine names.
3 Likes
A less systematic name may suit a package that implements one of several possible approaches to its domain.
This is such a generic constraint that it can be used to exclude any package from the explicit-name guideline, if so desired. That’s not my preferred interpretation because then we end up with an unintelligible set of package names.
I feel it is important to remember that the name of the base language is Julia, not Sometimes Faster Than Fortran But Hope You Run Things Atleast Twice And Read The Docs Programming Language.
I think the name is fine and the package looks sweet! Bravo
13 Likes
Agree!
It seems that people like marketing their packages with flamboyant DDRAM-style names like
I think this is against the spirit and letter of the guidelines whose first line is
Package names should be sensible to most Julia users, even to those who are not domain experts.
It is helpful to consider the guidelines as applying to most packages. If the guidelines don’t apply to anything, we might as well delete them.
What’s the advantage of NinjaRifleKiller.jl over ApproximateNearestNeighbors.jl? Maybe it’s a more fun name. But this practice makes the Julia ecosystem less discoverable and inclusive to outsiders, which generally should trump the idiosyncrasies of personal taste.
Explicit names also require the developer to do a bit of literature review, to create a name that situates the package in the context of existing packages. For example, Graphs.jl was followed by LightGraphs.jl, which is lighter.
Conforming in this way can be annoying for the developer, but this is why we have guidelines: to constrain our individual preferences in favor of a common objective.
3 Likes
Great packages and software emerge as they shine. Do Armadillo or Blitz++ have anything to do with Linear Algebra? Can you tell Flask is a web framework from its name?
1 Like
At the time, in the then-smaller Python community it was released into, maybe I could: Flask was an April Fool’s joke based on Bottle, another web framework. Nowadays, it’s a big brand-name framework with over a million daily downloads, so it doesn’t need name-based discoverability.
But for most packages and most users, bad names hinder discoverability and inclusiveness.
No, and I’m arguing that’s a problem. Or it would be in Julia, which composes many more packages than C++.