To the contrary @jamshark70 has suggested that agreeing on “standard” usage (in terms of docs and guiding new users) would bring more focus to the core. The quarks will still be there for all those excited by the expressive possibilities and dialects that SC has.
On the question of breaking compatibility: If we want to do something about the long-standing complaint of “too many ways to do things,” I suppose that a gradual approach might be best.
First, identify areas where there are “too many ways,” and decide what should be the standard way going forward.
…
Then, document recommended approaches and make the user community aware of that.
…
Then start chopping. I’m not sure if it would be better to do this all at once (one big set of changes for everyone), or to do it incrementally.
Both Scott and Nathan have explained well that “officially supported” quarks (dev-maintained) are not at odds with a smaller core, rather, it’s part of the solution.
I think doing these things would be a HUGE step forward for SuperCollider - among other things, it would open the door to moving core library functionality like JITLib to properly versioned quarks, and manage separately from the “core” classes where there’s a MUCH higher bar for backwards compatibility. Note that moving core functionality to a quark does NOT mean removing it from the default install
There’s some conflation going on in this thread between modularity of SuperCollider and easy user interface for installation. This conversation started as the first concern, and is getting sidetracked by the latter. These are separate concerns, and I want to assure people: it’s not a tradeoff at all!
In the above post Scott has given the road map of how to do it. Lucile has even made a pretty picture (in addition to a great explication of the problem!).
I mention this because unless the nuance is embraced, a false dichotomy will keep us chasing our tails. The solutions are there, what remains is a lot of legwork…