3 ms·
That's unfair to to the pig. I mean, unfair to Perl. In the past I've done lots of programming in Perl, and am currently doing lots of programming in R. I wo
by nkurz 11y ago
That's unfair to to the pig. I mean, unfair to Perl. In the past I've done lots of programming in Perl, and am currently doing lots of programming in R. I would say without reservation that Perl is a much better designed language, with good documentation, and a coherent philosophy. Perl has some issues, but has a solid core.
R has some nice individual packages, and some bright people involved, but the core is rotten. While it is possible to write high performance R, and possible to write easy-to-read R, I don't think it's possible to do both at the same time. It's easy to drop to C or C++ to speed up the critical sections, but often the glue between the pieces is so slow that it's not worth bothering.
I'm not recommending that you use Perl for statistics (Python or Julia would be better choices), but I think a language written by a linguist for sysadmins is a much better choice than a language written by statisticians for statisticians. Although maybe that's because I'm a programmer and not a statistician?
- nkurz 11y agoAs evidence for my position, and as evidence that I'm doing my best to fix these issues rather than idly carping, here's a bug report I submitted today: https://stat.ethz.ch/pipermail/r-devel/2015-September/071744.html https://stat.ethz.ch/pipermail/r-devel/2015-September/071744... Some of my sampling code was running much slower than I thought made sense (even for R), and the strange part was that larger samples were sometimes 1000x faster than smaller samples. The answer was that R (wisely) uses two algorithms for sampling without replacement, but the cutoff between them is based on a fixed sample size of 1e7, rather than the percentage of population sampled. Perhaps there's a good reason?