Aside: this seems to be exploring the question “is the grammar of graphics a good paradigm”, which is different from the previous question “does matplotlib use the grammar of graphics paradigm”. Which is fine, it’s a good question to explore, just, yeah, different.
Another aside: I think it’s worth mentioning that the “everything is pixels” end of the spectrum would also need a way for data to flow back up to the program, or it wouldn’t be as functional as matplotlib, let alone something truly interactive like d3 or vega-lite (the interactive one mentioned above). Like, matplotlib doesn’t just draw a set of pixels to a canvas and then the interactive viewer scales/crops/zooms the canvas. When you resize the interactive viewer, two pieces of text might go from overlapping to non-overlapping or vice-versa.
Another way to say this, you can’t just think of a matplotlib plot as being ultimately a list of pixels which something else will draw; a matplotlib plot is a function from canvas parameters to a list of pixels. (And maybe other inputs I forget. And this is also true of plotnine, being implemented on top of matplotlib.)
I guess I want to say this because… yes, in the end everything on the screen is pixels, but if you were to think “everything is pixels so I’ll just draw pixels” there’s a good chance you’d be missing something. Similar: everything on a standard monitor is ultimately pixels (except not really) and vector graphics have to be rendered to pixels, but vector graphics are still in some sense fundamentally more powerful than raster graphics, even though raster graphics can draw any combination of pixels.
I’ll try to respond to the substance in another comment later.
Aside: this seems to be exploring the question “is the grammar of graphics a good paradigm”, which is different from the previous question “does matplotlib use the grammar of graphics paradigm”. Which is fine, it’s a good question to explore, just, yeah, different.
Another aside: I think it’s worth mentioning that the “everything is pixels” end of the spectrum would also need a way for data to flow back up to the program, or it wouldn’t be as functional as matplotlib, let alone something truly interactive like d3 or vega-lite (the interactive one mentioned above). Like, matplotlib doesn’t just draw a set of pixels to a canvas and then the interactive viewer scales/crops/zooms the canvas. When you resize the interactive viewer, two pieces of text might go from overlapping to non-overlapping or vice-versa.
Another way to say this, you can’t just think of a matplotlib plot as being ultimately a list of pixels which something else will draw; a matplotlib plot is a function from canvas parameters to a list of pixels. (And maybe other inputs I forget. And this is also true of plotnine, being implemented on top of matplotlib.)
I guess I want to say this because… yes, in the end everything on the screen is pixels, but if you were to think “everything is pixels so I’ll just draw pixels” there’s a good chance you’d be missing something. Similar: everything on a standard monitor is ultimately pixels (except not really) and vector graphics have to be rendered to pixels, but vector graphics are still in some sense fundamentally more powerful than raster graphics, even though raster graphics can draw any combination of pixels.
I’ll try to respond to the substance in another comment later.