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 <javascript:void(0)>. 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."
