first pass at naming guidelines https://github.com/JuliaPraxis/Naming
On Thursday, October 13, 2016 at 8:07:18 AM UTC-4, Páll Haraldsson wrote: > > On Sunday, October 9, 2016 at 9:59:12 AM UTC, Michael Borregaard wrote: >> >> >> So when I came to julia I was struck by how structured the package >> ecosystem appears to be, yet, in spite of the micropackaging. [..] I think >> there are a number of reasons for this difference, but I also believe that >> a primary reason is the reliance on github for developing the package >> ecosystem from the bottom up, and the use of organizations. >> > > Could be; my feeling is that Julia allows for better > > https://en.wikipedia.org/wiki/Separation_of_concerns [term "was probably > coined by Edsger W. Dijkstra > <https://en.wikipedia.org/wiki/Edsger_W._Dijkstra> in his 1974 paper "On > the role of scientific thought" "; synonym for "modularity"?] > > that other languages, OO (and information hiding) has been credited as > helping, but my feeling is that multiple dispatch is even better, for it. > > > That is, leads to low: > > https://en.wikipedia.org/wiki/Coupling_(computer_programming) > "Coupling is usually contrasted with cohesion. Low coupling > <https://en.wikipedia.org/wiki/Loose_coupling> often correlates with high > cohesion, and vice versa. Low coupling is often a sign of a well-structured > computer > system <https://en.wikipedia.org/wiki/Computer> and a good design" > > > https://en.wikipedia.org/wiki/Cohesion_(computer_science) > > Now, as an outsider looking in, e.g. on: > > https://en.wikipedia.org/wiki/Automatic_differentiation > > There seems to be lots of redundant packages with e.g. > > https://github.com/denizyuret/AutoGrad.jl > > > Maybe it's just my limited math skills showing, are there subtle > differences, explaining are requiring all these packages? > > Do you expect some/many packages to just die? > > One solution to many similar packages is a: > > https://en.wikipedia.org/wiki/Facade_pattern > > e.g. Plots.jl and then backends (you may care less about(?)). > > > Not sure when you use all these similar (or complementary?) packages > together.. if it applies. > > > In my other answer I misquoted (making clear original user's comment is > quoting > > Style Insensitive? > https://github.com/nim-lang/Nim/issues/521 > >Nimrod is a style-insensitive language. This means that it is not > case-sensitive and even underscores are ignored: type is a reserved word, > and so is TYPE or T_Y_P_E. The idea behind this is that this allows > programmers to use their own preferred spelling style and libraries written > by different programmers cannot use incompatible conventions. [..] > > Please *rethink* about that or at least give us an option to disable > both: case insensitive and also underscore ignored > > [another user]: > > Also a consistent style for code bases is VASTLY overrated, in fact I > almost never had the luxury of it and yet it was never a problem." >
