In my experience it wasn’t any specific capability that’s missing (although it might be possible as well) – just that I find “regular” plotting approach more fitting in the vast majority of scenarios. Not specific to algebraofgraphics library, but to “grammar of graphics” concept.
Makie.jl is generally well-designed, and occasional minor unneccessary-painful things can typically be solved without adopting a whole different plotting paradigm – see MakieExtra.jl for my take on it.
5 Likes
I would say that grammar of graphics or AlgebraOfGraphics’s version of it is a very “symmetric” way of plotting. You need to have your data sources formatted in a couple of allowed ways and you only may do a limited set of facet plot configurations, namely corresponding to either one or two categorical variables. Basically all the functionality is built on the idea of grouping and this is particularly annoying to do manually I find. So this approach can save a lot of time for many use cases because of the boilerplate construction work that it does on its own. On the other hand it only covers a small part of the possibility space that Makie offers, it’s just that it’s a very common and useful part.
10 Likes
Actually I do find AoG a reasonable choice for “the rest of us”, too. Herewith I mean, there is what I would call
- “observational sciences”, which typically involves a lot of statistics,
- modelling, and
- “experimental sciences and hands-on engineering” - this is the “rest of us” here.
The last group is underrepresented among the Julia users (because the first two are overrepresented), but it it would be nice if you, the majority, be kind to us, the minority, 
, and keep our needs and perspectives in mind, too.
And in this my perspective, as I wrote here above, one generally needs just three plot types, and preferably an easy way to produce them. AoG mostly can do it (sure, even just with Scatter / Line / BarPlot there would be a lot of special requests for special cases not covered directly by AoG).
The problems are IMO - first, documentation. There are a few post above saying “I struggled”, “plotting is generally difficult” etc. Actually I do not think AoG concepts are intrinsically difficult (I found them quite logical after all), and I do not think making a simple plot must necessarily be difficult. Therefore my suggestion is to add something like this TLDR chapter to the manual. @jules what is your opinion on this?
And second - dual axes, which is “our” very common need. IMO, it would be highly beneficial to have native support for dual axes in AoG, but if not, there are workarounds.
1 Like
Dual axes are somewhat in disrepute for a variety of reasons. It’s almost always better to normalize. But for work in a field where they are the norm (P.I.), you’re stuck, I guess.
What can be considered as “almost always”, depends strongly on one’s perspective.
Specifically, concerning usage of double axes, I argue about it in the parallel topic.
1 Like
One could probably add dual axes because the scale mechanism already allows multiple x/y. Currently, there’s only special logic for having separate x/y scales across separate facets and things error if multiple separate ones land in the same facet. But this could be changed such that one of the scales is marked “secondary” (or even more, in principle). Then one would have to adjust the axis grid machinery to not assume a single axis per grid position (as the secondary axis needs a full Axis to support separate linking etc). And this would throw a wrench into the current facet keywords as those suddenly would need to support multiple sets of facet options as you could in theory link the secondary axis differently from the first. This also applies to the spanning axis labels, might give some layout problems.
All in all, I’m not against secondary axes per se, I see their uses in certain cases. But I don’t need them myself and they sound like a rabbit hole of complexity, so I’m not going to touch that, personally.
3 Likes