In my opinion the solutions to this are very clear, or would be:
1. make a mandatory linter for all julia code
2. julia IDEs should offer good intellisense
Am Freitag, 7. Oktober 2016 17:35:46 UTC+2 schrieb Gabriel Gellner:
>
> 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.
>
