As every, Chris speaks beautifully about something close to my heart :) I really hope something like this can get some traction. I am of the Matlab/Mathematica camp. I want all the science goodies :)
I wonder what peoples experience is with `.rc` like solutions. I have heart palpitations thinking about people in R changing how read.table works (to make it more sane, but still makes sharing code a pain), similarly with Maple where it became hard to share code because everyone had so many customization to the environment that it became really hard to use anything without replacing their `.rc` as part of the package. I also think the Standard part of the standard library needs to be extremely important, micro distributions for a science stack can be really painful for collaboration (across labs for example, or trying out stuff from stackexchange etc). anyway +100 to this idea!!!! On Tuesday, September 13, 2016 at 2:39:15 AM UTC-6, Chris Rackauckas wrote: > I think one major point of contention when talking about what should be > included in Base due to competing factors: > > > 1. Some people would like a "lean Base" for things like embedded > installs or other low memory applications > 2. Some people want a MATLAB-like "bells and whistles" approach. This > way all the functions they use are just there: no extra packages to > find/import. > 3. Some people like having things in Base because it "standardizes" > things. > 4. Putting things in Base constrains their release schedule. > 5. Putting things in packages outside of JuliaLang helps free up > Travis. > > > The last two concerns have been why things like JuliaMath have sprung up > to move things out of Base. However, I think there is some credibility to > having some form of standardization. I think this can be achieved through > some kind of standard library. This would entail a set of packages which > are installed when Julia is installed, and a set of packages which add > their using statement to the .juliarc. To most users this would be > seamless: they would install automatically, and every time you open Julia, > they would import automatically. There are a few issues there: > > > 1. This wouldn't work with building from source. This idea works > better for binaries (this is no biggie since these users are likely more > experienced anyways) > 2. Julia would have to pick winners and losers. > > That second part is big: what goes into the standard library? Would all of > the MATLAB functions like linspace, find, etc. go there? Would the sparse > matrix library be included? > > I think one way to circumvent the second issue would be to allow for Julia > Distributions. A distribution would be defined by: > > > 1. A Julia version > 2. A List of packages to install (with versions?) > 3. A build script > 4. A .juliarc > > The ideal would be for one to be able to make an executable from those > parts which would install the Julia version with the specified packages, > build the packages (and maybe modify some environment variables / > defaults), and add a .juliarc that would automatically import some packages > / maybe define some constants or checkout branches. JuliaLang could then > provide a lean distribution and a "standard distribution" where the > standard distribution is a more curated library which people can fight > about, but it's not as big of a deal if anyone can make their own. This has > many upsides: > > > 1. Julia wouldn't have to come with what you don't want. > 2. Other than some edge cases where the advantages of Base come into > play (I don't know of a good example, but I know there are some things > which can't be defined outside of Base really well, like BigFloats? I'm > not > the expert on this.), most things could spawn out to packages without the > standard user ever noticing. > 3. There would still be a large set of standard functions you can > assume most people will have. > 4. You can share Julia setups: for example, with my lab I would share > a distribution that would have all of the JuliaDiffEq packages installed, > along with Plots.jl and some backends, so that way it would be "in the box > solve differential equations and plot" setup like what MATLAB provides. I > could pick packages/versions that I know work well together, > and guarantee their install will work. > 5. You could write tutorials / run workshops which use a distribution, > knowing that a given set of packages will be available. > 6. Anyone could make their setup match yours by looking at the > distribution setup scripts (maybe just make a base function which runs > that > install since it would all be in Julia). This would be nice for some work > in progress projects which require checking out master on 3 different > packages, and getting some weird branch for another 5. I would give you a > succinct and standardized way to specify an install to get there. > > > Side notes: > > [An interesting distribution would be that JuliaGPU could provide a full > distribution for which CUDAnative works (since it requires a different > Julia install)] > > [A "Data Science Distribution" would be a cool idea: you'd never want to > include all of the plotting and statistical things inside of Base, but > someone pointing out what all of the "good" packages are that play nice > with each other would be very helpful.] > > [What if the build script could specify a library path, so that way it can > install a setup which doesn't interfere with a standard Julia install?] > > This is not without downsides. Indeed, one place where you can look is > Python. Python has distributions, but one problem with them is that > packages don't tend to play nice with all distributions. This leads to > fragmenting in the package sphere. Also, since it's not explicit on where > the packages come from, it may be harder to find documentation (however, > maybe Documenter.jl automatically adding links to the documentation in > docstrings could fix this?). Also, there's a good reason to ask "why fuss > with distributions when anyone could just add the packages and add the > import statements to their .juliarc?" (though its target audience is for > people who don't know details like the .juliarc, but also want Julia to > work seamlessly like MATLAB). > > This could be a terrible idea, I don't know. But sharing an idea with the > internet is a great way to find out. But I think at least the idea is a > step in the right direction, if not in details. >
