Blog #6: All about R
Posted by Sarah Leichty
R: A Language for Data Analysis and Graphics
I was not aware of the fact that R was born out of the S and Scheme languages. Combining the appealing aspects of different languages is a simple yet dynamic idea. I’m not familiar with Scheme, but using this language as a template and then systematically changing the code to mirror the structure of S is an impressive feat. I particularly love the line about the creators retaining their interest in computers after spending an enormous amount of time crafting R. This gave the piece a more informal feel by bringing an emotional detail that only the authors could divulge. Another concept I learned was the main difference between S and Scheme, which is the varying use of environmental frames. In Scheme, these frames only are defined if they are near the fuction as opposed to S’s “global frames” that are constant over the code. This paper cleared up a lot of confusion with its section on why arrows such as <- are used as assignment operators instead of =. While using a = seems more straightforward, it would actually be very confusing to the program since it wouldn’t know which value you wanted: either the first formal argument or otherwise. Another factor in the development of R that I hadn’t considered was how to manage the data in the computer’s memory. I hadn’t realized that the entire functionality of the program was built on this essential layer. I was surprised when the article mentioned bad memory-management systems in which programs are allowed to take up more memory than is feasible with a fixed amount of memory on a computer. I was impressed when the issue of possibly needing to upgrade R’s memory-management program in the future was brought up. This demonstrates the creators’ goals of continuing to tweak and revise parts of R as time progresses and needs change. I had not thought about how challenging it would be to measure how efficient a program such as R is compared to its parent program such as S. I would have imagined that a study comparing how many seconds to complete a task would be sufficient, but the paper pointed out that the speed of R as a program depends on the quantity of memory ready for use. I appreciated the authors’ honesty when they pointed out a downside to R’s way of storing data internally instead of on disks. I also liked the way that the article ended with a heading about future developments to hightlight the need to continue making improvements and extensions as technology changes. All in all, a very informative and intriguing article that gave me a better understanding behind R and its quirks.
