Hacker News Reader

Comment by bicubic | Hacker News Reader

I agree with your sentiment, but at the same time I've yet to see anyone do it better. The other popular tools like d3 have the same problems, I think some of it may just be an intrinsic cost with expressive visualization frameworks.

View on HN

I personally like the design of ggplot2. Not necessarily a design everyone will love, but it's pretty consistent and systematic in its design around the "grammar of graphics". Works especially well if you buy into the entire Hadley Wickham ecosystem of R packages: ggplot2, dplyr, reshape2.

I really like ggplot2, but I'm not sure it really competes with matplotlib or d3. It feels like, if it doesn't already support the thing you want, implementing it in ggplot is a lot harder than in mpl or d3.

For specific examples, I've looked idly at doing chord diagrams and trees in ggplot. Chord diagrams don't seem to exist, you can do them with another R package but I don't think it interacts with ggplot. There's a ggtree library that does interact with ggplot, but in kind of a weird way that I wouldn't describe as "you can now draw trees with ggplot".

(I haven't explored too closely. This was in the context of "I want to write a ggplot for python, and I'm curious whether supporting chord diagrams and trees at some point in the future is plausible".)

Spot on.

ggplot2 is much nicer than matplotlib and d3 as long as you stay on the beaten path; which is wide enough to accommodate the majority of use cases. But the second you step off that beaten path, it's hell.

It just looks like there's a fundamental tradeoff between visualization expressiveness and API complexity.

Btw, Seaborn is a framework on top of matplotlib that replicates the semantics of ggplot2 if that's what you're after.

Oh? I've looked at seaborn, but it didn't seem very ggplot-ish. No grammar going on.

There's ggpy (formerly ggplot), but that also doesn't have a grammar going on under the hood, and on top of that it pretty directly translates ggplot's API to python. ggplot's API might be fine for R, but it's wildly unpythonic. ggpy doesn't understand where it's coming from or where it's going to. Plus it's buggy and incomplete and seems abandoned.

The one I'm currently looking at is plotnine, which keeps the API but at least it also keeps the grammar.

I was working on my own library until I found plotnine, with IMO a better API (and a rudimentary CLI). Now I'm looking at building it on top of plotnine, and when I have a POC I plan to get in touch with the author of that and see if he's interested in adopting it. (I think this is a long shot, but worth trying.)

Another library to look at these days in this area is Altair (https://altair-viz.github.io/), which is based on the vega spec.

I am the author, do let me know what you are trying to do. I too have some ideas of what to add to plotnine or build on top of it.

I'll try to get in touch tomorrow. By default I'll open an issue on github, unless there's another way you'd prefer me to contact you?

Then use R's built-in "base graphics". They afford literally pixel-by-pixel control if you know what you're doing, in a 100% declarative API that isn't so hard to learn.

Building abstractions is just a matter of writing very simple imperative functions. Modifying existing abstractions is a matter of copying and pasting out of the source code for existing ones.

It can involve lots of tedious trial-and-error, and the documentation is a little terse, but it's about as close to drawing by hand as you can get.

Ggplot2 is great for prototyping, but when you want to really own your graphics, go for Base.

There's also a middle path, called Lattice. It's built on the same library as Ggplot2 (called Grid), but lets you dig down into the guts a little more easily, at the cost of your graphs looking "older", since it's based on Trellis graphs from SAS.

Base R graphics are a little like Matplotlib in being an organic API. I'd argue that Grid is a better starting point than base R, if you're planning to create a reproducible plot type.

Organic in what sense? Other than "pch" it's much less magical than matplotlib (to me), and its primitives are exposed alongside the convenience functions like hist() with ugly defaults we all love to hate.

I will agree on reproducibility and portability across graphics devices (not to mention actoss installations). Grid takes care of so much annoyance in that regard.

Yeah, the mishmash of convenience functions and pch were pretty much exactly what I was thinking about. Also, I will vehemently agree that base R graphics are still far less magical than matplotlib. So, I guess I meant "like matplotlib, but to a far less extreme degree" :-)

I definitely am not a fan of R's inconvenient convenience functions. A saner set of wrappers for R base graphics is on my long to-do list, at least something with better defaults. Someone had started a project that goes in the right direction called "compactr", but it seems abandoned: https://cran.r-project.org/package=compactr

Ggplot2 is built on Grid Graphics, which is a well thought-out low level graphics layer. Part of the reason so many extensions to ggplot2 get built, is because Grid is easy (albeit lower level) to work with.

https://cran.r-project.org/web/packages/gridGraphics/

I've said it before, but the attempts to replicate ggplot2 usually fail to implement the full stack. As a result we have somewhat incomplete implementations of surface features of ggplot2, without the depth that is afforded by the grid / ggplot2 combo.

How about gnuplot ?

Gnuplot needs to die. It is not GNU. It is not libre open source.

Reply on news.ycombinator.com