I’ve read a lot of opinions about what should be default for Julia to make it more accessible. Some conflicting but a lot of it is in alignment. Some of it is breaking to be in Base. Some of it is a matter of network/community issues (re: too many Chaining packages).
Has anyone attempted to make an OpinionatedJulia.jl that installs things in the global env (Revise, Infiltrator…), adds nice things to startup.jl, has its own version of Pkg.generate()/PkgTemplates for fleshing out how the sensible basics of new project (maybe even installing certain packages based on the user’s domain),etc. And then has very opinionated docs about what packages you should use and some no nonsense docs for the recommended packages?
If not, what would you have in a project like this? I’m especially interested in the experiences of teachers and students here as you have a closer view of the Novice’s Eye.
I’m not a teacher or student, but I remember that the first package that I ever installed was Plots, so some plotting package would be an obvious thing to have. DataFrames could be another, I avoided it for a long time because it was not in the standard library, but realistically, I should probably use it a lot more as it is one of those really popular packages. I also agree with Revise.
Other than this, anything that is in the standard libraries of other important languages (e.g. C, C++, Java, R, Python, Matlab) could be considered. This would include things like Nettle, TimeZones, database & HTML stuff among others. It could probably also be good to have some machine learning stuff.
Yeah, I’ve been following your progress and have improved my own workflow already! I do think though that the “s” in “workflows” is part of what made me think about this. For a certain segment of users, a menu of options to read through is overwhelming/not worth the time. I’m reacting to the “just give me the best and don’t bother me with the details” kinda feeling. I’m also thinking about people who need to focus their mental energy on learning how to program on the first place. A student is probably not going to be reading “Modern Workflows” but could still benefit from some sensible defaults.
I also considered this, and maybe that’s how it could be sold, but as far as implementation is concerned, the work of keeping a distribution in sync with main Julia, maintaining builds, etc. seems like more trouble than it’s worth when a package is fully capable of doing the work I’m describing (installing packages, manipulating startup.jl, adding some convenience functions).
I totally agree on your idea of an opinionated default workflow for beginners.
The choice between different workflows, plotting packages, IDEs, editors is important for advanced users but a real pain for beginners (e.g. should I complete a long comparison study before choosing between different plot options).
I would go one step further by proposing a default workflow including the IDE choice (vscode (Revise)), the plotting choice (Makie)… A vscode button to create a new project (based on PkgTemplates) and so on…
A beginner experience closer to what Matlab or R studio users would expect.
I do not think that Emacs power-user (those with 30 fingers) would be annoyed by this basic entry point in Julia’s development world . Would they even notice ?
Yeees, I feel ill-equipped to contribute to the extension GUI., But I echo all your thoughts there. I feel confident in my ability to write command line UI, so that’s where I’d start. But I’d absolutely be open to integrating the extension if someone would like to collaborate.
I realize it is probably counter-productive to propose additional action that I can’t contribute to your actionable proposal. Apologies.
Nevertheless, I still wonder if such an addition to the Julia’s vscode extension (package creation button and installation of default choice for major packages) would really be a game changer feature for Julia’s adoption by beginners or not.
Imagine that the Julia’s vscode extension includes juliaup and could install Julia on the machine and the opinionated list of basic packages.
What makes make me think so is the example of Revise.jl being install by default in vscode. It is a super cool feature (to me) while being much less controversial (as far as I can tell) compared to add Revise.jl to Base.
If there is a strong consensus on the interest on such a feature, then it may motivate the super charged developers (@davidanthoff; @pfitzseb,…) to go for it. (Look at what the Genie team achieved in there closed source extensions).
Reading @Keno’s new thread there could also be a “create app button” (creating the proper form of main function) in the future.
I think that idea is at least partially orthogonal to what I’m considering in this post. I think Revise is uncontroversial as a “default” package, so that could easily be installed by the extension, but I’d like to be quite a bit more aggressive about defaults to the point where I think it would be inappropriate for the Official VSCode extension to be quite so opinionated.
The Linux kernel doesn’t distribute Gnome, it’s up to distributions to make those kind of decisions to return to @mkitti analogy
Update: I’ve been working to make this more opinionated, explicitly separating the basic packages from more advanced tricks thanks to a color code. I believe the first page is almost complete, feel free to give feedback!