IPython vs knitr, or Python vs R | /en/2012/11/ipython-vs-knitr/

Guest *Karthik Ram* @ 2012-11-27 19:25:29 originally posted:

Great blog post, Yihui! I met with Fernando recently and we discussed several of these issues. You're absolutely right that python has the advantage of a huge community of non-academic users and developers that R lacks. I also agree that R isn't going away anytime soon. While tools like pandas will definitely serve the purpose as a general purpose toolbox for most users, R will still be key for many domain specific applications.

Guest *Fernando Perez* @ 2012-11-27 20:30:35 originally posted:

Hi Yihui, thanks for the kind words about IPython! I have to admit that my knowledge of R is small, so I have only seen knitr and related tools 'from the outside', but I love the fact that the R community is taking such a serious look at issues of worfklow and reproducibility, coming from multiple angles. I recall seeing the program for the last R user meeting in Tennessee, and there were a ton of interesting abstracts on the matter.

I hope we'll have a productive dialog over the years across both communities and that we can learn/copy/steal a lot of good ideas from each other :)

With the caveat that, as I acknowledge above, I know R only superficially, I do slightly disagree with you on how much R is a 'general purpose language'. While technically yes, one can do any general purpose task in basically any Turing complete language, my impression is that R is really so strongly designed around statistical data analysis and linear modeling that it is a somewhat awkward fit for modern software engineering. Again, I may be wrong, but my superficial impression seems supported by an in-depth analysis of the language (summary, full paper).

And that's where we've seen Python shine: the fact that it is first and foremost a general purpose language gives us scientists a huge army of software developers who build all kinds of non-scientific tools that are ready for us when we need them. And since, as I outline in this slide of my talk, scientific computing is rapidly spreading beyond number crunching into all manner of other needs, this is proving to be a great asset for us.

As I told Karthik yesterday, I think if anything Julia is a very interesting tool to look at for modernizing R: the Julia folks are extremely talented, knowledgeable and a great bunch to work with. They are really trying to unify the best of tools like Python and Ruby with the needs of high-level scientific computing, and I think they are doing a very good job overall (even if I wouldn't have followed the matlab syntax so slavishly).

But in any case, it's great to see these ideas coming from the R world, and I look forward to learning a lot more from what your community is producing!

Guest *Software Carpentry* @ 2012-12-01 17:49:56 originally posted:

Thanks for your post, Yihui. We're starting to run R-based workshops through Software Carpentry as well as Python-based; if you or anyone else in the R community would like to get involved, please give us a shout (info@software-carpentry.org). In particular, we're shifting our Python teaching over to the IPython Notebook, and since it supports R as well...

Guest *Ihui* @ 2014-08-30 17:59:33 originally posted:

IPython notebook is just what the name says, a notebook. Some people are arguing it is nice for "reproducible" research... it is nothing like that. It is just a playground for running python interactively in really awkward way. You can't even compare this with kntir, which IS a nice tool for reproducible research.

RStudio + Rmarkdown + kntir + packrat (or similar packages) is an unparalleled powerful IDE for dynamic exploration of data and reproducibility, and there isn't anything like that in python.

How would you write a package + an academic paper with lots of projects together in an "environment" like IPython notebook? You just don't.

Guest *Ihui* @ 2014-08-30 18:05:12 originally posted:

Just to emphasize. The workflow with iPython notebook is terrible. It is not an IDE. The closest thing Python has to a scientific IDE is spyder, which looks last century software when compared to RStudio + Rmarkdown + knitr + shiny etc.

Guest *Ihui Abraao* @ 2014-08-30 18:21:00 originally posted:

Not to mention Rcpp and RStudio integration which is now more elegant than ever.

Guest *Yuxiang Wang* @ 2014-11-11 02:56:59 originally posted:

Great post Yihui! :)
In my research I used matlab -> python, and then I decided to learn some statistics and that's when I learned R. I don't think python is going to eat R or the other way around, just like excel is never totally replaced by VBA... I feel that R is much more script-based, and people see the result real-time, as they type the code. Scipy is more suitable for serially-connect large projects (e.g. I am doing solid mechanics and it'd be hard to apply R here since it's a mechanistic model with too many serial components, that one module build on another). Python is better for re-usable customize code, but that is at the cost of less one-liners for the most common statistical functions.
I guess at the end of the day, each user-base has their niche. C, Python, R, Excel... Each has their purpose. Just my thoughts after reading the post :)

Guest *Sergei Petrov* @ 2017-02-06 10:01:21 originally posted:

R + Python + ...more...
org-mode + babel ( http://orgmode.org/worg/org-contrib/babel/ )