R 3.0.0 Released 75
DaBombDotCom writes "R, a popular software environment for statistical computing and graphics, version 3.0.0 codename "Masked Marvel" was released. From the announcement: 'Major R releases have not previously marked great landslides in terms of new features. Rather, they represent that the codebase has developed to a new level of maturity. This is not going to be an exception to the rule. Version 3.0.0, as of this writing, contains only [one] really major new feature: The inclusion of long vectors (containing more than 2^31-1 elements!). More changes are likely to make it into the final release, but the main reason for having it as a new major release is that R over the last 8.5 years has reached a new level: we now have 64 bit support on all platforms, support for parallel processing, the Matrix package, and much more.'"
Re:Congratulations R Team (Score:5, Insightful)
It also feels more appropriate, somehow, to do research code in R: It's supposed to be shareable and reproducible, and using an expensive and proprietary language kind of defeats the purpose. Besides, CRAN and Bioconductor have rather a lot of useful stuff...
This is how it should be done ... (Score:5, Insightful)
As in: when they release it, you can trust it to work.
Hence they didn't mess around with major reconstruction of R's guts until they could release something that's finished (and well-tested !) and bumped the version number to 3.0.0 when they did in order to properly differentiate it from previous versions.
This is one of the differences between amateur OSS offerings (like for example KDE with its miriad half-baked Kxxx packages, sundry horrible OSS games, etc.) and genuine production-quality OSS (like R, Lapack, Octave, Libre Office, PostgressQL, MySQL, GRASS GIS, QGIS, Maria DB, GNU CC, the Linux kernel etc.)
This is very gratifying as R happens to see widespread use in academia, government and business when it comes to data analysis and statistics.
If R has a weakness, it is that uses an in-memory approach to data-processing, unlike e.g. SPSS, which keeps almost nothing in memory and simply makes passes through datafiles whenever it needs something. R is also a bit memory-hungry, so the need for genuine 64-bit implementations should be clear.
Apart from sporting about 4000 useful and ready-to-run statistical applications packages, R has convenient and efficient integration with C code and has what's probably a contender for the best support for data-graphics anywhere.
For those who didn't know, even packages like SPSS and SAS have incorporated R interfaces to tap into the wealth of application packages that R offers. Can't think of a more significant compliment right now.
Re:How modern! (Score:5, Insightful)
I recently switched my scientific programming from R to Python with NumPy and Matplotlib, as I couldn't bear programming in such a misdesigned and underdocumented language any more. R is fine as a statistical analysis system, i.e. as a command line interface to the many ready-made packages available in CRAN, but for programming it's a perfect example of how not to design and implement a programming language. It's also unusably slow unless you vectorise your code or have a tiny amount of data. Unfortunately, vectorisation is not always possible (i.e. the algorithm may be inherently serial), and even when it is, it tends to yield utterly unreadable code. Then there is the disfunctional memory management system which leads you to run out of memory long before you should, and documentation even of the core library that leaves you no choice but to program by coincidence [pragprog.com].
As an example of a fundamental problem, here's an R add-on package [r-project.org] that has as its goal to be "[..] a set of simple wrappers that make R's string functions more consistent, simpler and easier to use. It does this by ensuring that: function and argument names (and positions) are consistent, all functions deal with NA's and zero length character appropriately, and the output data structures from each function matches the input data structures of other functions.". Needless to say that there is absolutely no excuse for having such problems in the first place; if you can't write consistent interfaces, you have no business designing the core API of any programming language, period.
Python has its issues as well, but it's overall much nicer to work with. It has sane containers including dictionaries (R's lists are interface-wise equivalent to Python's dictionaries, but the complexity of the various operations is...mysterious.) and with NumPy all the array computation features I need. Furthermore it has at least a rudimentary OOP system (speaking of Python 2 here, I understand they've overhauled it in 3, but I haven't looked into that) and much better performance than R. On the other hand, for statistics you'd probably be much better off with R than with Python. I haven't looked at available libraries much, but I don't think the Python world is anywhere near R in that respect.
Anyway, for doing statistics I don't really think there's anything more extensive out there than R, proprietary or not, although some proprietary packages have easier to learn GUIs. In that field, R is not going to go anywhere in the foreseeable future. For programming, almost anything is better than R, and I agree that those improvements you mention are not doing much to improve Rs competitiveness in that area.
Re:Congratulations R Team (Score:5, Insightful)
Times are changing. There are many forces at work here:
1. Cutbacks in funding is making lead scientists look for ways to save money.
2. The proprietary vendors upgrading their software and charging license fees for each version (one particular vendor licenses specific minor versions).
3. The desire to share work and non-proprietary methods are the best way to do it.
4. New postdocs are familiar with python (they like working in iPython in particular) and its libraries.
5. R is gaining ground with the older scientists due to its features and price.
Re:Congratulations R Team (Score:5, Insightful)
Drives me crazy. At least with statisticians, R is by far the dominant package now. But in science, it's Matlab Matlab Matlab.
Python + Numpy/Scipy is such a better alternative now it's not even funny. It's actually a real language, and has loads of packages. And unlike Matlab, you don't have to pay extra money for additional packages (or any money).
The use of closed source software in science is a waste of scarce resources, and it hurts openness. Another thing is that every numerical type class I've had has used Matlab. It's really unfair to expect students to purchase a copy. I use Octave when I have to deal with this, but it is not perfectly compatible.