[amelius]

I don't understand why people would want to do mathematics in imperative languages.

(Yes, I understand imperative languages are faster, but why not just keep the imperative parts for the "inner loops", nicely isolated, and a functional core for everything else?)

[Mikeb85]

> I don't understand why people would want to do mathematics in imperative languages.

R isn't exactly what I'd call your typical imperative language. It's more like the love child of APL and Scheme, with random bits thrown in by a bunch of statisticians.

Loops are almost never used in R, since pretty much everything is a vector (or some sort of data structure made of vectors), you simply apply functions to vectors and it maps over the whole thing.

Of course, the C, C++ and Fortran bits are 'imperative', which is kind of the structure you describe anyway (functional, vectorized R language which calls down to a bunch of C/Fortran functions).

[louden]

R does support functional programming. In fact, it was based on Scheme (see discussion for comparison: https://stat.ethz.ch/pipermail/r-help/2008-December/181982.h...).

[tormeh]

They're easier and faster to develop in. Remember that the scripts usually only need to be run once - maintainability is irrelevant.

I don't think this all of the difficulty is intrinsic to FP, but FP language designers don't usually care about newbie-friendliness. The closest thing to a user-friendly FP language I know about is Scala, and it, too, has lots and lots of arbitrary symbols and hideously complicated function signatures.

Remember, the typical scientist has no patience for monads, currying, inscrutable value names or functions-as-arguments and compiler complaints about function signatures are more likely to instill deep hatred than anything else.

I know it's an extreme example, but a statistician will never try to understand what something like "def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That" means, he'll just move on to a language that's easier.

[dagw]

R is, at its core, a functional language with a bunch of largely optional imperative bits bolted on.

[sooheon]

One of R's great current evangelists, Hadley Wickham, is taking it back to its functional roots[1](http://cran.rstudio.com/web/packages/dplyr/vignettes/introdu...) as well.

[hadley]

See also http://github.com/hadley/purrr

[dbaupp]

Unfortunately, the R language isn't fast, especially not the imperative features (loops). A language like Julia is a better bet in that respect.

The drawcard of R is the breadth of specialised statistical packages. (Often with inner loops written in C for performance.)

[baldfat]

in R loops are generally frown upon due to this issue.

BUT R is not slow when it comes to parallel processing or using Revolution Anayltics also has speed ups if you need it. R also has dplyr is speedy and the data.tables is even faster. I think the original Julia speed claims were a little biased to Julia and well there is plenty of awesome things about R, but "slow" isn't a far statement. There is a reason why R has grown so much.

Interesting argument for R usage: https://matloff.wordpress.com/2014/05/21/r-beats-python-r-be...

[grayclhn]

"R is slow" refers to the main implementation of the language --- to code written in R --- and is completely fair. The packages you're talking about are mostly written in C or C++ with nice R interfaces. So R as a statistical package or R from a user's perspective is often quite fast, but that's because it is relatively easy to interface with C and C++.

(This comes up often, and I'm not sure why I'm compelled to reply today, but there it is.)

[baldfat]

But MANY programming languages work this way. I would say that coding in R it doesn't matter if it is C or Fortan why say programming in R is slow even though in practice it really isn't with some new solutions?

[grayclhn]

Many languages are slow. (Or, more concretely, many languages have only slow implementations.) If C or Fortran interfaces are easy, speeding up the language shouldn't necessarily be a priority. But that doesn't make the language itself fast.

As for why this can matter: a big part of my job is designing and prototyping new statistical estimators. "Prototyping" means running them through lots of simulations to explore their properties in small samples. My two options in R are:

1. Program up the estimator in pure R, in which case the simulations can take days to weeks to complete.

2. Program up the estimator in C and write an R interface, in which case the simulations will run 10 to 100 times faster. (Depending on the exact operations used.) The code will take much longer to adjust if I need to change the estimator, which happens frequently, and debugging will take longer.

3. Program up the estimator and simulations in pure C, making it still faster but much more brittle.

This is a fairly iterative process -- I'll typically discover errors in the math as I run the simulations or after I've run them, or the simulations will reveal unappealing properties that need to be fixed. But once I have "good" estimator and "good" simulations, I write it up in a paper and am done with it. (Gross simplification of my actual job, but accurate enough.)

So the distinction between "R's speed" and "C's speed" very much matters, and if R were actually as fast as C it would make my life much easier.

Of course, for people who are "coding in R" by running data analysis in a script the distinction doesn't matter. But I already said that in the comment you're replying to.

[baldfat]

Thank you for actually replying and clarifying your statement, I enjoy learning different ways of thinking. I guess I am changing my word for R to "Fast Enough for Me." I can run my scripts in under 20 seconds, but a few years ago it could be 2 or 3 minutes.

[Mikeb85]

R is slow if you try to use it like an imperative language. If you use it idiomatically, it's quite fast. If all the intensive data-processing calls functions written in C/Fortran, it's very fast. And of course, you can use R for parallel processing, or in a cluster...

Julia as a language is faster, but I'm not sure it's actually faster than R to process data if you're using R as most people do...