Here’s what I think we should do with plotting in Julia:
I don’t think we need a default plotting package - because how do you guarantee your one chosen package is the preferred one? R tried that, but it’s not the one everybody is using, and the reason it even works with that is that everybody has accepted Wickham’s packages as a standard library.
I also think the current understanding, of a cohort of several different plotting packages that compete with each other to be the preferred plotting package is profoundly mistaken. It creates an uneasy feeling about plotting. And it misses the promise of a nicely integrated plotting functionality, though plotting is at least as central to a scientific computing language as is something like data representation.
What we need instead is a modular plotting structure with good support in a shared base package, based on interfaces. This has not been tried before to my knowledge, but represents a unique chance for julia. I don’t think we’ve yet begun to unpack the potential there is in applying an interface model to julia’s plotting ecosystem. The collaborative nature of Julia’s package ecosystem (yet) makes this possible.
What we need instead of a default plotting functionality is a default plotting specification, which should allow package authors to define visualizations for their types in a package-independent way – this is a line, this is red, these are the values, etc. The reason we need this is that Julia is based around user types and dispatch on those types. This means that any package is able to define plot methods for any types it specifies. The role of plotting, after all, is not to create pictures - it’s to generate insight. This has such great potential in terms of data analysis: instead of building diagnostic plots, you can pass any object you call to plot and get visual insights. To me, being able to define user objects in packages, and being able to define visualizations for these objects are intimately intertwined.
One way this is currently suggested to be done is with glue packages. So you make a ConvexHullsGadfly package, a ConvexHullsGR package, an OpenStreetMapGR package etc. The issue is that you get a crazy number of packages, some packages may be missing (eg. what you only have a ConvexHullsGR and OpenStreetMapPyPlot packages but want to combine those in plots). It also becomes unclear who should maintain the packages in the face of updates. A plotting specification living in the package that defines the type is clear, transparent, and easy to maintain.
The rest should be done with interfaces. If you think of the differences, from a user perspective, between different plotting packages, they are two things: 1) the plotting interface – how are plots defined and called; and 2) the aesthetics / looks and output types of the plot. There is no reason these two should go together. One can find Gadfly beautiful but not have a taste for the grammar of graphics, or the other way around. And something like Plots is really both 1) an interface aiming for concise plotting commands, and 2) a plotting implementation (though the backends take care of some of this). But using e.g. GGPlots.jl (unmaintained at the moment) it is 100% possible to use a Grammar of Graphics interface instead, with the same functionality.
I thus suggest this model:
ChosenInterfacePackage-> BasePlotSpecification->ChosenOutputPackage
Plots is not this, at the moment – but it is attempting to implement some of this vision. And RecipesBase takes an important step towards being a broad plotting specification. It currently lies fairly close to the Plots syntax, but there’s really no reason it has to. Unfortunately, in the current perception that plotting packages are competing entities, there isn’t an understanding that something like RecipesBase or a related package is an attempt to unite plotting functionality; instead it is sometimes viewed as competing with plotting packages that don’t support a shared interface. What we need is some core people in julia to identify this as a priority, then agree on a common specification that isn’t perceived to advantage certain plotting packages. A good first step would be for all of us involved in Julia’s plotting ecosystem to sit down together and talk this through.
We can then build a plotting ecosystem based on picking your favourite interface, your favourite output format. In principle, all the other functionality in a plotting package, related to ticks and axes and colors etc, could be implemented in a Utils package that was shared among platforms. This would ensure efficiency, but also continuity, as you wouldn’t to the same degree get the current problem with a plotting package being left by the wayside after a few years when the original author runs out of steam (a huge problem for this ecosystem).
This would ensure ease-of-access, full pluralism of choice regarding interface and output, full integration of the ecosystem, and basic support for visualization across the broader package ecosystem. We just need to decide to do it, rather than believing that plotting must be a competition between small packages.