Why R Doesn't Suck
paulbutler.org
paulbutler.org
1. it is extremely slow for numerics. slower than MATLAB. slower than python (with numpy). after talking to several stats people, it seems pretty much everyone ends up writing most of their code in C when using R. (in contrast, i didn't find this necessary in python or MATLAB for similar projects.)
2. its syntax is quite clunky. want to concatenate two strings? paste(string_a, string_b, sep=''). radford neal has a series of blog posts on R's design flaws: http://radfordneal.wordpress.com/2008/09/21/design-flaws-in-...
3. uninformative error reporting. by default, the stack trace isn't printed. even if it is, often the errors don't really tell you what went wrong.
i don't see any advantage to R over python. yield makes a nice replacement for the lazy evaluation of R.
Anyway, you're right with respect to the lack of standard way. One thing I personally find most annoying is function naming. Some functions use the dot convention (do.this), some use camel case (doThis), some use underscores (do_this) etc. And what is most annyoing: this is even true for novel functions that were just introduced in recent releases.
we use sage (http://www.sagemath.org/) which includes a lot of the common python numerics: numpy, scipy, matplotlib, networkx. it provides nice interfaces to R and gp/pari. i also use mayavi2 for 3d plots (something i could never get R to do well under linux...) enthought have a lot of nice things for python and scientific computing. there's also pymc which i've not used (i just write the MCMC code directly).
Not to me. Consider a parallel example:
Visual Basic (pre-.NET, think ~3.0) opened up programming for GUIs to a much much broader audience (because Hypercard was made for a far less popular system). VBmade embedding hugely powerful applications within your own, remote object calls simple, etc. It was the most popular programming language.
It was incredibly successful, useful, and powerful. None of that could change the fact that it fundamentally sucked though.
It sucked so much though that Microsoft killed it. They killed their most popular programming product ever. They killed the product that was used to make most of the applications for their platform, their office suite, their web server, their database server, etc. In the transition to .NET they apparently they felt its foundations were so fundamentally flawed that they had to redesign the language.
Maybe a better term for powerful would be "power to weight ratio".
Side-note: Most of my work in the past year has been done in R.
Hmmm, I prefer the explanation that they just lost their Raymond Chen style backwards compatibility religion. Note that they did the same with Windows right after the release of XP. Joel has a lot more to say about this: http://www.joelonsoftware.com/articles/APIWar.html
As far as I could tell, VB.NET wasn't an upgrade to VB6, it was a product introduced to smooth the transition to C#... like Lotus 1-2-3 shortcut compatibility in Excel. VB.NET simply couldn't do what I was using VB for.
It's like if you went to the hardware store and they told you that instead of selling hammers, now they sell screwdrivers. They're better because they're easier to get out, they hold better, etc. That's all fine and good.. unless you've got a truck full of nails and the roofing contract calls for the shingles to be nailed in.
This is awesome. This is probably one of those things that I should have known but didn't. It strikes me as being very useful in combination with the 'apply' functions.
It's very useful with higher-order functions in general. Even more so because most of the languages with operators simply being (binary) infix function calls also default to curried functions[1], which you can easily partially apply.
Haskell also has the reverse operation (MLs probably have it as well) of being able to use a binary function as an operator: "a `foo` b" is equivalent to "foo a b", but sometimes reads much better.
The neat thing about R is that it supports the functional paradigm, but it doesn't bash you on the head with it. My fellow programmers who are not familiar with lazy evaluation, continuations, list iterators (is that the right word? such as map / filter / fold) can still use it without feeling like they're missing an arm.
Higher-order functions, or "combinators" if you want to sound all math-y. They're not really list iterators, because it makes just as much sense to map or fold over trees, arrays, matrices, etc. Whether you need structure-specific versions like maplist, maptree, etc. is just an implementation detail.
i'm not really sure about far superior for 2D: http://matplotlib.sourceforge.net/users/screenshots.html vs. http://had.co.nz/ggplot2/
Also, frequently the person writing the library is the guy who invented the estimator in the first place. To me this counts for something.
I'd really like to switch to Python+numpy/scipy, but I haven't been able to find an equivalent of a data.frame, or some numeric+string data structure that allows for easy slicing on both.
Does anybody have any suggestions?
http://www.scipy.org/RecordArrays
It doesn't quite have first-class status in the library the way data.frame does in R, but it does let you index an array using strings.