update on package names that begin with an acronym .. following much
discussion, the rule which a strong preponderance of participants favor:
the acronym is to be uppercased and the following words camelcased, no
separator.
so: CSSscripts, HTMLlinks, XMLparser.
This does not match the current docs:
the acronym is to be uppercased and the second word is to be
capitalized, no separator.
so: CSSScripts, HTMLLinks, XMLParser
The reasoning I found most persuasive is that the current docs' rule
undermines Julia's developing reputation for expressive clarity.
On Friday, October 14, 2016 at 3:15:44 PM UTC-4, Jeffrey Sarnoff wrote:
>
> 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.
>>>>>
>>>>
