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.
>

Advertising

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."