IPython vs knitr, or Python vs R
Yihui Xie / 2012-11-23
I watched this video by Fernando Pérez a few days ago when I was reading a comment by James Correia Jr on Simply Statistics:
This is absolutely a fantastic talk that I recommend everybody to watch (it is good in both the form and content). Not surprisingly, I started thinking ipython vs knitr. Corey Chivers said we could learn a lot from each other, and that is definitely true on my side, since ipython is so powerful now.
ipython and knitr
I did not take a close look at ipython when I was designing knitr because I’m still at the “hello-world” level in Python, and I did not realize until I watched the video that we ended up with some common features like:
- support to Markdown/MathJax (to be fair, MathJax is RStudio and markdown instead of knitr’s contribution), not to mention HTML and LaTeX
- multi-language integration:
*magicin ipython (rmagic, octavemagic, …) vs
enginesin knitr (python, ruby, bash, C++, …)
- support to D3 (knitr example; I did not find a live example with ipython at the moment)
Obviously knitr is still much weaker than ipython in many aspects, but some aspects do not really hurt; for example, the user interface. IPython enables one to write in the browser, which looks cool and is indeed useful. We (Carlos, Simon and I) had a similar attempt called RCloud in the summer this year when I was doing intern at AT&T Labs, which was a combination of Rserve, FastRWeb, knitr, Markdown and a bunch of JS libraries. The user interface is pretty much like ipython; in fact, it was inspired by ipython.
The RCloud project is not completely done yet, but I believe RStudio has done a fair amount of work to make the user interface more friendly, so I’m not terribly worried.
That being said, I felt overwhelmed when I saw the Emacs client for ipython in the talk. On one hand,
(I wrote that by Google translation; not sure if it is accurate; I mean in terms of nationality, Japanese programmers have surprised me most; examples include the Ruby language, Kohske Takahashi and kaz_yos)
On the other hand, the R community is still too small compared to Python. I have been looking forward to the R Markdown support in Emacs/ESS. The infrastructure on R’s side has been ready for quite a while. ESS developers have been working hard, but we just need more force to spin R to a higher level in a more timely fashion (embrace the web server, EC2, D3, web sockets, Julia and all the cool stuff; not only generalized linear models).
Small as it is, the R community is also moving to interesting directions. I especially agree with Jeff Horner on his recent post Innovation in Statistical Computing that RStudio has been making remarkable and innovative contributions to the R community. I think one thing important is that RStudio developers are not statisticians like R core. The R community absolutely needs this kind of fresh power: good sense of user interface, good knowledge of modern computing technologies and most important of all, good project/product managers.
The shiny package is yet another example besides what were mentioned in Jeff’s post. I think it is interesting to compare shiny with Rserve, FastRWeb, gWidgetsWWW(2), rApache, Rook and older packages like CGIwithR. From the technical point of view, each package in the latter group may be more complicated than shiny (Simon, Jeff and John are extremely smart guys), but apparently shiny has become the Gangam style of R web apps. Most users will not, nor do they, care about the technology behind the package. A developer may feel unfair that the user only sees the nice twitter bootstrap style, without noticing the websockets, but that is just the fact.
When I saw the 3D barplot in the talk, I feel R graphics will be able to survive longer for a while.