| My point behind the keras/ TF comment is that the libraries have front ends in both python and R, so its mix mox/ dealers choice on what you like to work in (since the backends of both are identical). The primary reason to moving these to python is due to convenience/ the community. Most new work is published in python. If we find a new/ interesting model we want to implement, its probably written in python. Rather than reskin the thing in its entirety, its easier here to work in python. A couple disclaimers: my group works primarily in geospatial data, and principally in LiDAR and multispectral imagery. The coarse division I see between R/ Python, is that if you come from a research/ academic background (non-engineering), you probably learned to program in R. If you were an engineer, you probably learned matlab. If you are self taught/ coursera/ youtube, you probably learned in python. R libraries are generally more geared towards academic research, and specifically, working within existing frameworks (handling geospatial data as geospatial data rather then turning them into a numpy arrays). Working in python, there is far more re-invention of the wheel, and its always a pain the ass to get things back into the structures they came in as. Python has huge utility and is an important tool for certain work. But its really really not faster than R (it def used to be, this isnt the case any more). R has better support for more scientific programming than python. |
Not as a point of argument, just additional information: R's support for keras and TF is a wrapper around the Python interface to those libraries.