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

Reply via email to