Actually, all is good. The current docs do not take a stand on the use of case following an acronym.
On Monday, October 24, 2016 at 1:38:39 PM UTC-4, Jeffrey Sarnoff wrote: > > 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. >>>>>> >>>>>
