On potentially expanding or pruning the standard library

I 100% agree with this, its largely the reason behind this post and my other post that talks about trying to simplify adding third party packages (by adding an entire org’s production packages).

With Python, there’s at least the idea ingrained in Pythonista’s that

“if you want numerical computing, simply install NumPy. If you want scientific computing solutions, simply install SciPy.”

Whereas with Julia it’s more like:

“if you want numerical computing, add Polynomials.jl, Roots.jl, Interpolations.jl, Bessels.jl, SpecialFunctions.jl, Richardson.jl, QuadGK.jl, FFTW.jl, Combinatorics.jl, NFFT.jl, Cubature.jl, FastChebInterp.jl, HCubature.jl, FunctionZeros.jl, KahanSummation.jl, RealDot.jl, Calculus.jl, IterativeSolvers.jl, LinearMaps.jl, Arpack.jl, Preconditioners.jl, AlgebraicMultigrid.jl, BenchmarkTools.jl, etc., etc.,”

And I just think that this has at least some deleterious impact for new users of Julia. If instead Julia users’ hive-mind had the thought of “Oh, with Julia if you want to do numerical computing add JuliaMath and JuliaLinearAlgebra” then we probably have a solution that doesn’t require expanding the standard library, though maybe we could prune LinearAlgebra to the care of the JuliaLinearAlgebra organization?.

6 Likes