Just clarifying: For a two part package name that begins with an acronym 
and ends in a word   
the present guidance:   
     the acronym is to be uppercased and the second word is to be 
capitalized, no separator.  
     so: CSSScripts, HTMLLinks  

the desired guidance (from 24hrs of feedback):   
     the acronym is to be titlecased and the second word is to be 
capitalized, no separator.   
     so: CssScripts, HtmlLinks

What is behind the present guidance?

On Saturday, October 8, 2016 at 8:42:05 AM UTC-4, Jeffrey Sarnoff wrote:
> 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.

Reply via email to