This is something that I've spent a lot of time and energy thinking and discussing, as part of both Plots and JuliaML. I think the situation can be improved in a big way, but this is not something with a "magic solution". It takes time, effort, and a constant desire to collaborate and design with care for the greater community. As soon as people get lazy, it starts to get unwieldy. So I think the "solution" is just to keep at it... keep trying to collaborate... keep trying to agree on common conventions... and always look to find common ground. Use Base as a guide, whenever possible, and if there are different conventions in place across packages, then spend the time to agree on shared conventions. And if people refuse to collaborate, give them crap about it.
On Fri, Oct 7, 2016 at 12:02 PM, David Anthoff <anth...@berkeley.edu> wrote: > I don’t have a solution, but I completely agree with the problem > description. > > > > I guess one small step would be that package authors should follow the > patterns in base, if there are any. > > > > *From:* julia-users@googlegroups.com [mailto:julia-users@googlegroups.com] > *On Behalf Of *Gabriel Gellner > *Sent:* Friday, October 7, 2016 8:36 AM > *To:* julia-users <julia-users@googlegroups.com> > *Subject:* [julia-users] Julia and the Tower of Babel > > > > Something that I have been noticing, as I convert more of my research code > over to Julia, is how the super easy to use package manager (which I love), > coupled with the talent base of the Julia community seems to have a > detrimental effect on the API consistency of the many “micro” packages that > cover what I would consider the de-facto standard library. > > What I mean is that whereas a commercial package like Matlab/Mathematica > etc., being written under one large umbrella, will largely (clearly not > always) choose consistent names for similar API keyword arguments, and have > similar calling conventions for master function like tools (`optimize` > versus `lbfgs`, etc), which I am starting to realize is one of the great > selling points of these packages as an end user. I can usually guess what a > keyword will be in Mathematica, whereas even after a year of using Julia > almost exclusively I find I have to look at the documentation (or the > source code depending on the documentation ...) to figure out the keyword > names in many common packages. > > Similarly, in my experience with open source tools, due to the complexity > of the package management, we get large “batteries included” distributions > that cover a lot of the standard stuff for doing science, like python’s > numpy + scipy combination. Whereas in Julia the equivalent of scipy is > split over many, separately developed packages (Base, Optim.jl, NLopt.jl, > Roots.jl, NLsolve.jl, ODE.jl/DifferentialEquations.jl). Many of these > packages are stupid awesome, but they can have dramatically different > naming conventions and calling behavior, for essential equivalent behavior. > Recently I noticed that tolerances, for example, are named as `atol/rtol` > versus `abstol/reltol` versus `abs_tol/rel_tol`, which means is extremely > easy to have a piece of scientific code that will need to use all three > conventions across different calls to seemingly similar libraries. > > Having brought this up I find that the community is largely sympathetic > and, in general, would support a common convention, the issue I have slowly > realized is that it is rarely that straightforward. In the above example > the abstol/reltol versus abs_tol/rel_tol seems like an easy example of what > can be tidied up, but the latter underscored name is consistent with > similar naming conventions from Optim.jl for other tolerances, so that > community is reluctant to change the convention. Similarly, I think there > would be little interest in changing abstol/reltol to the underscored > version in packages like Base, ODE.jl etc as this feels consistent with > each of these code bases. Hence I have started to think that the problem is > the micro-packaging. It is much easier to look for consistency within a > package then across similar packages, and since Julia seems to distribute > so many of the essential tools in very narrow boundaries of functionality I > am not sure that this kind of naming convention will ever be able to reach > something like a Scipy, or the even higher standard of commercial packages > like Matlab/Mathematica. (I am sure there are many more examples like using > maxiter, versus iterations for describing stopping criteria in iterative > solvers ...) > > Even further I have noticed that even when packages try to find > consistency across packages, for example Optim.jl <-> Roots.jl <-> > NLsolve.jl, when one package changes how they do things (Optim.jl moving to > delegation on types for method choice) then again the consistency fractures > quickly, where we now have a common divide of using either Typed dispatch > keywords versus :method symbol names across the previous packages (not to > mention the whole inplace versus not-inplace for function arguments …) > > Do people, with more experience in scientific packages ecosystems, feel > this is solvable? Or do micro distributions just lead to many, many varying > degrees of API conventions that need to be learned by end users? Is this > common in communities that use C++ etc? I ask as I wonder how much this > kind of thing can be worried about when making small packages is so easy. >
