Comment by danso | Hacker News Reader

Comment by danso | Hacker News Reader

As someone who's switched from Ruby to Python (for now, because the latter is far easier to teach, IMO) and also put significant time into learning R, because of how strong ggplot2 is...I was really surprised at the lack of Google results for "switching from python to r" -- or similarly phrased queries to find guides on how to go from Python to R...in fact, that particular query will bring up more results for R -> Python than the other way around (e.g. "Python Displacing R as The Programming Language For Data")...Talk of R is so ubiquitous in academia (and in the wild, ggplot2 tends to wow nearly on the same level as D3) that I had just assumed there was a fair number of developers who have tried jumping into R...but there aren't...I think minimaxir's guides are the most and only comprehensive how-to-do-R-as-written-by-an-outsider things I've seen on the web [1]. But by and far the common scenario is that of the author's: "Well, I guess it’s no big secret that I was an R person once"

That said, one of the things I've appreciated about R is how it "just works"...I usually go through Homebrew, but RStudio works just as well. I can see why that's a huge appeal for both beginners and people who want to do computation but not necessarily become developers.

Also, I used to hate how `<-` was used for assignment...but now, that's one of the things I miss most about using R...I've grown up with single-equals-sign assignment in every other language I've learned, but after having to teach some programming...the difference between `==` and `=` is a common and often hugely stumping error for beginners. Not only that, they have trouble remembering how assignment even works, even for basic variable assignment...I've come to realize that I've programmed so long that I immediately recognize the pattern, but that can't possibly be the case for novices, who if they've taken general math classes, have never seen the equals sign that way. The `<-` operator makes a lot more sense...though I would've never thought that if hadn't read Hadley Wickham's style guide [2]

[1] http://minimaxir.com/2015/02/ggplot-tutorial/

[2] http://adv-r.had.co.nz/Style.html

As a predominantly Python-focused engineer, I've spent considerable time teaching myself R and there is a lot to like about R. For boutique statistical libraries especially. For instance, the enjoyment of using PySTAN is nowhere near as high as simply using STAN directly from R.

However, when you dig into the R internals, and you learn about its generic function model of OO, and about the mangled history of S3 and S4 classes, it becomes very frustrating.

R mostly "just works" if you stick to the libraries. But if you want to really understand e.g. polymorphic dispatching and how you can design your own tools to use it, it's a deal-breaker pain in the ass in R. It just simply is not suited for real computer science situations when you need to design the software, rather than just making scripts that treat libraries as APIs.

Since the times when you need "just scripting" are about 0.00001% of real-world cases, it unfortunately means that as nice as R is, it's just not a good enough tool to standardize into a real-world workflow. You're way better off using Python, even if you have to give up easy access to certain libraries, re-write your own implementations, or kludge them on with tools like rpy2.

>Since the times when you need "just scripting" are about 0.00001% of real-world cases

I would argue the opposite is true.

Most of the time an analyst builds regression trees in the mktg department for a retailer. Or similar situations like this.

That is in fact an exact situation I've been in, where it had previously been organized as a bunch do ad hoc scripts, and it caused huge problems.

It is exactly all of these fractured cases where you're running analyses in some bespoke corner of a business that it is most critical that the analysis tool is productionized and unified.

Plenty of businesses don't do it this way, but their reliance on manual scripts, manual environment and dependency management, manually tracking which versions of code produced which results, and manually calibrating on historic test data, it all adds up to incredible problems that eventually require re-writes focusing on a systematic architecture.

Vendors are standardizing on R, so I don't think the situation is as severe as you make it out to be.

Vendors tend to standardize on crap. How many vending machines do you see with salad or tofu instead of Doritos or soda?

Big multinational IT vendors are even worse than the vending machine example. They cater to situations where a firm has some internal power struggle over IT and the struggle is won by one side who gets the certified approval of a statusy external vendor.

For instance, most big, showy technology re-orgs around Hadoop are unequivocally bullshit. Most firms do not face data problems that are appropriate for Hadoop, not even when their primary enterprise data store approaches the raw size at which Hadoop becomes plausible, because the types of analytical workflows still tend to involve much smaller data.

These firms hardly adopt Hadoop for pragmatic engineering reasons, and engineers may even resist the re-org and offer compelling evidence that it is a waste of money, yet are ignored.

Vendor offerings are much more about catering to the CTO or some other manager level employees, and focusing on b.s. on-paper "milestones" that the product can help them achieve. Many times, merely just the installation and integration of these tools can result in a multi-hundred-thousand dollar bonus, or more, for people high up the IT food chain -- even before anyone has seen whether it will bear any fruit or even come close to being cost effective.

Vendors will do this with anything they can, so it's not surprising they would do it with R technology and they also absolutely do it with Scala, Python, Spark, etc. Big vendors peddling all of that truly are the hotel lobby snack machines of the software world.

I'm not saying it's bad to have R as part of a professional computing environment. R is a great tool. I'm saying that for most business situations, people who tend to make the assumptions necessary to justify using R are often very wrong, and the clunky and inconvenient support for professional computer science and software design in R bites them, making Python a much more pragmatic choice.

Whatever vendors do is pretty irrelevant to this.

I guess we have to agree to disagree.

R is indeed quite weird when you get to internals. What's the problem you have with S3 though? It has it's limitations, but since I've first seen it, I thought it was by far the single most convenient and intuitive OO system out there... But yes, can't use it for everything. S4 is a bit ugly but still kinda workable -- the real problems for me start when you need to deal with environments and expressions and such, but is it really so often necessary to go there when you are designing your own tools (which I guess is what you're doing?)

As for the real-world percentage, it varies depending on the job -- R is primarily designed for the people who spend most of their time looking and thinking about the data, rather than the code.

It sounds a lot like perl5 back in the day. let's fuze sed grep awk and bash into one thing. It's got a great deal of whipupitude, you can make amazing stuff in an afternoon.

The reason is that it's more common for a statistician to encounter a problem that needs switching to Python (either because there are Python tools for it, or because of a need to interact with non-statisticians who are using Python), than it is for a software engineer to get into statistical research.

It is quite telling that a lot of people here mention packages such as ggplot2 as the advantage of R -- ggplot2 is really quite awesome, but I can see it being similarly powerful had it been done for Python (maybe with a bit more unwieldy syntax, but that stuff is really subjective).

R really shines when you are doing actual data analysis -- things like the data.frame object, first-class missing values, proper attention paid to inference (something I quite often see missing from stuff written in Python or even Matlab), model syntax, estimation objects with actually useful pretty-printed summary, huge variety of statistical plots, everything designed to be convenient to use in the REPL, etc. -- and since these things are expected, you will usually find them in CRAN packages as well. Python (and Matlab) are IMO much less consistent in that regard.

But if your task is primarily to implement a particular type of analysis, put it in production to be easily repeated in the future, and go to next problem, R indeed offers little benefit over Python unless you rely on a specific package (which, btw, you should only do if you understand exactly what it does, because most R packages are written by statisticians, and as a result have very little fool-proofing).

You know, I remember when I was trying my first language other than BASIC (VB6, perhaps? or maybe 1995 era JS?) and it bugged me that "x = y" wasn't the same as "y = x". Remembering it as "LET x = y" was helpful.

I've also seen this confused with folks who are just learning their first language and = is a common assignment operator in typical 'first languages' these days.

People have been upset about that since at least the 1950s. A lot of people who make programming languages use the := for the assignment operator instead.

Helps when you prounounce the assignment operator as "becomes" rather than "equals", too.

> it bugged me that "x = y" wasn't the same as "y = x"

it is in Prolog

Heh, that brings me back to when I was a kid, thinking, "x = x + 1? No it doesn't."

Reply on news.ycombinator.com