I have created a new Organization on github: *JuliaPraxis.* Everyone who has added to this thread will get an invitation to join, and so contribute. I will set up the site and let you know how do include your wor(l)d views.
Anyone else is welcome to post to this thread, and I will send an invitation. On Saturday, October 8, 2016 at 6:59:51 AM UTC-4, Chris Rackauckas wrote: > > Conventions would have to be arrived at before this is possible. > > On Saturday, October 8, 2016 at 3:39:55 AM UTC-7, Traktor Toni wrote: >> >> 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. >>> >>
