This article has been sitting on my desktop for quite some time. I try to reason that the procrastination was because schoolwork suddenly became overwhelming when holiday was over. Well, that's probably not true. Maybe I just didn't want it to end.
What I have done
When the project actually started, I realized some problems with the approach, and wrote my first lengthy explanationn on why I chose to create a wrapper for Vega, instead of D3 directly.
Over the three months, I have learned a great deal of things, and even "rewrote" Plotrb at least twice. So, have I achieved the goal I set back in June? Yes. Plortb now has its own set of (simple) grammar, that allows you to create Vega specifications in Ruby with relatively small amount of code.
However, am I satisfied with what I have accomplished and where Plotrb currently stands? Honestly, no and no.
Therefore, tonight I forced myself to sit down in front of this article, not trying to boast what a wonderful thing I've done or how much it would benefit the Ruby community, but rather to tell people who care to read this, that I see problems, and I'm still seeking solutions.
1. Where does (should) Plortb fit in?
When I read scientific papers and see plots created by ggplot2 or matplotlib, I would nod and say "Hmm this looks very professional." But when I play with the interactive data visualization created by Mike Bostock on The New York Times, I'm like "Man, that's some kickass cool stuff!"
This is a problem we can't avoid. From its current stand, it seems Plotrb has run into a field that Ruby is not particularly good at.
2. Didn't I choose Vega precisely because of that?
However, this solution is still far from perfect. Vega itself is a new library, even during the course of Plotrb's development, Vega has had a few major updates with new components (such as Legends that is not in Plotrb yet because it came out very recently). The specification does not have a formal standard (such as JSON schema) for reference. Many of the rules seem quite arbitrary and inconsistent, and they caused a lot of pain in the last few weeks of developing Plotrb. I have to hack Plotrb to workaround these inconsistency of Vega, and this considerably reduced the maintainability of Plotrb.
This is still just an idea not yet clear enough to be actionable. But my hunch tells me it is the way to go.
3. Why plotting tools are hard to design, and especially so for Ruby?
The following paragraphs are very opinionated. Please take with a grain of salt.
Creating a plotting tool is very hard, because it just seems impossible to cover both ends of the spectrum. People use it for all kinds of things, from plotting a few sets of experiment data, to visualizing enormous DNA sequence in a single graph. A tool catered for the former would be almost useless for the later; and a tool that is powerful enough for the later would be a huge overkill for the former.
You simply don't know what kind of plots the user is expecting to produce with the tool, so it's really difficult, if not impossible, to design a grammar that works for both ends.
Why is it especially hard to do in Ruby? Because I think Ruby developers are the most artistic among all. No other programming language community emphasizes on the elegance of code as much as we do. This leads to the harder question - how to design a plotting grammar/DSL that is succinct, elegant, and yet flexible enough to handle more than trivial use cases?
Just a few days back, I came across ggplot for python. I think it's a brilliant attempt to use ggplot2's grammar based on matplotlib, and I'm sure many people, especially if they are familiar with R, would love it.
But look at the code,
from ggplot import * ggplot(aes(x='date', y='beef'), data=meat) + \ geom_point(color='lightblue') + \ geom_line(alpha=0.25) + \ stat_smooth(span=.05, color='black') + \ ggtitle("Beef: It's What's for Dinner") + \ xlab("Date") + \ ylab("Head of Cattle Slaughtered")
Is it just me or are those brackets, pluses and backslashes really, really, really, frustratingly ugly?
It's already 4 am and I should probably stop. I'm not sure if it's a proper endnote for this year's GSoC. As I said, I see problems, and I won't stop searching for answers. So in that sense, it is not the end, no, far from it.Tweet
comments powered by Disqus