7 ms·

I've been co-teaching a class in computing for statisticians this semester (some details on the previous iteration here https://www.refsmmat.com/posts/2016-01-2

I've been co-teaching a class in computing for statisticians this semester (some details on the previous iteration here https://www.refsmmat.com/posts/2016-01-22-stat-computing.html https://www.refsmmat.com/posts/2016-01-22-stat-computing.htm...) and have mixed feelings about RStudio. Most of our students use RStudio for their work. It's convenient and easy. For developing standalone scripts or functions, rather than notebooks or R Markdown files, the typical workflow is to write code in a file, then run it in the current R session by selecting pieces and hitting "Run". But this encourages terrible practices. After a few iterations, the current environment does not reflect what's written in the file. If students write tests in a separate file, they neglect to source in their functions, because they're already in the workspace and so the tests run fine. Datasets that were loaded in the R console are used in code without being explicitly loaded there. Code gets changed without being run, or variable definitions are changed but old copies in the workspace accidentally used instead. We end up getting many homework submissions that simply don't run if you start them in a new R session. Pieces are missing, code is out of order, tests only run if you manually select the test code and run it. It only worked in the R session of the original author. R Markdown is a decent step, since rendering the HTML should start a session from scratch, but when we're asking them to write well-tested and modular algorithmic code, using R Markdown doesn't really fit. I've begun to appreciate DrRacket's approach, where there is a "Definitions" pane and an "Interactions" window. When you Run the definitions, the current workspace is blown away and everything is defined from scratch from the Definitions, so there's no lingering state from REPL interactions. (Unfortunately your REPL history is lost, which can be annoying.) You can't run into the same inconsistent state as RStudio actively encourages.

yihui 10y ago
Isn't this a simple instruction you give students in the very first class like "before you submit your homework, restart R session, and make sure your submission runs in the new session"? This only requires them to click a menu item (Restart R session), and a button (Knit or Source or something). Not really a burden for them, but will save your life as the instructor. As someone who had been a student in statistics for more than 10 years, I confess I had never written a single test for my homework. Frankly I just didn't have the time or interest (too much homework, and becoming a professional software engineer was not the goal of the homework assignments). That said, when I put on my software engineer hat now at work, I'd definitely do what you advertise here and write tests carefully. If you want your students to enjoy the benefits of both R packages and R Markdown, I wrote some thoughts here a couple of years ago: http://yihui.name/rlp/ http://yihui.name/rlp/ Don't get me wrong. I'll all for teaching students good practice of software engineering. I just want to speak from my own memories and experience as a student. Sometimes I feel teachers are like parents: they want kids to learn all possible right things, no matter if they are practically able to swallow all the good stuff (sometimes this has bad psychological consequences, like rebellious children). If I were an instructor in statistics, I'd only require students to submit an R Markdown document. Other things like tests can earn extra credits but not required.
- munificent 10y ago
  > Isn't this a simple instruction you give students in the very first class like "before you submit your homework, restart R session, and make sure your submission runs in the new session"? This only requires them to click a menu item (Restart R session), and a button (Knit or Source or something). It's the nature of learners to make mistakes. The more things they have to remember to do, the less cognitive power they'll have to focus on what they're trying to learn.
  - minimaxir 10y ago
    That demand is the equivalent of pressing two buttons. (and yes, in my stats course as an undergrad I was also requested to reload and rerun R sessions to ensure code was correct)
  - cheriot 10y ago
    That's a good point, though in this case the thing they need to remember is a key part of doing the job. Seeing a line of code run correctly once does not mean it's correct. It's one of those concepts that comes up in many forms. Perhaps one way to make a teachable moment of it is to help them set up a baby CI environment. Then every time it catches something the value of good practices is driven home.
- capnrefsmmat 10y ago
  Well, it doesn't just require them to click a menu item and hit a button -- then they have to fix all the problems that arose because RStudio encouraged a hackish development style. There's a workaround, but RStudio still actively encourages your workspace to get out of sync from your script. Compare that to DrRacket, where the code is labeled the "Definitions" window, and every time you reload the definitions, your workspace starts from scratch. You can't accidentally interact with deleted code. This would be a problem in a straight-line script where you're doing a bunch of data munging and analysis, since reloading from scratch might mean redoing expensive computations. But if you're building clean, reusable functions to implement interesting algorithms -- building a package and not a script -- then it's exactly the behavior you want. Our course very much focuses on software engineering. Major topics include writing modular code, object-oriented design, thorough testing, and version control. We don't cover statistics concepts in the class -- it's computing for statisticians, not computational methods in statistics. We believe that teaching statisticians to compute like software engineers will, in the long term, dramatically improve their work, since they'll have a stable base of robust, modular, well-tested, reusable code. One recent project, for example, required students to write a pipeline of scripts: one script takes the name of a CSV file as a command-line argument, processes and filters the data, and dumps it on STDOUT so the next script can read from STDIN and load the data into PostgreSQL, so another script (an R Markdown document) can do some queries and generate an automated report on the new batch of data. The processing and analysis stages have to be written as functions, not just top-level scripts, so they can be thoroughly tested. A future project will involve using dual k-d trees for fast approximate kernel density estimation, or building R trees to efficiently query spatial data. These are definitely more like packages than scripts.
huac 10y ago
I've required my students to turn in knitted pdf's from their R Markdown code. This course is more of an applied stats class, rather than stat computing, which I guess might make more sense. But it does ensure reproducibility (mostly, once we do away with working directories!). My difficulty is more that for most of these students, this is their first time using R or a real programming language. I had hoped that R Markdown would make the process simpler and more sensible. But the tendency of a student is to try different things, and not have a strong understanding of the logic behind those processes. So they create R Markdown files, and then gripe about how the code works in their IDE, but doesn't knit, and so knitr must be broken!
Homunculiheaded 10y ago
If you really want them to write "well-tested and modular algorithmic code" then you should teach them how to write packages in RStudio. Then require everything submitted to be in RMarkdown. I mentor learning data scientists and my advice is always to start using RMarkdown as soon they're remotely comfortable with RStudio. Not only does it avoid issues with an easily polluted global namespace, but more importantly encourages literate programming from the early stages. In stats/data science literate programming is vital to having any idea what you were working on a few months ago. It also makes writing reports much, much easier. RStudio makes it pretty easy to put together R packages, and the package structure for R does a great job of enforcing proper documentation and testing. Sourcing R files should primarily be used to quickly play around with ideas, or for exploratory data analysis that doesn't fit well inside an RMarkdown document. Any code you intended on reusing between projects should end up in a local package. I do think it's a problem that R has no intermediate method of organizing code like simple modules in Python. But this means if you're serious about writing clean R, you just have to bite the bullet and teach students to write packages.
willis77 10y ago
It feels like you are pinning a problem on RStudio that isn't RStudio's fault? A hammer is not a bad tool because it allows you to drive a nail into your own foot.
IndianAstronaut 10y ago
This is the same problem with Ipython notebooks as well. Lots of very segmented code that won't run as a block. But in general you really should run it from the top from time to time and learn best practices for error handling and such.
apathy 10y ago
have them write packages and turn in the vignette. problem solved
progman 10y ago
In Common Lisp you could take a snapshot of the current session with "save-image". Doesn't Racket provide something like that? http://stackoverflow.com/questions/480083/what-is-a-lisp-image http://stackoverflow.com/questions/480083/what-is-a-lisp-ima...

yihui 10y ago

Isn't this a simple instruction you give students in the very first class like "before you submit your homework, restart R session, and make sure your submission runs in the new session"? This only requires them to click a menu item (Restart R session), and a button (Knit or Source or something). Not really a burden for them, but will save your life as the instructor. As someone who had been a student in statistics for more than 10 years, I confess I had never written a single test for my homework. Frankly I just didn't have the time or interest (too much homework, and becoming a professional software engineer was not the goal of the homework assignments). That said, when I put on my software engineer hat now at work, I'd definitely do what you advertise here and write tests carefully. If you want your students to enjoy the benefits of both R packages and R Markdown, I wrote some thoughts here a couple of years ago: http://yihui.name/rlp/ http://yihui.name/rlp/ Don't get me wrong. I'll all for teaching students good practice of software engineering. I just want to speak from my own memories and experience as a student. Sometimes I feel teachers are like parents: they want kids to learn all possible right things, no matter if they are practically able to swallow all the good stuff (sometimes this has bad psychological consequences, like rebellious children). If I were an instructor in statistics, I'd only require students to submit an R Markdown document. Other things like tests can earn extra credits but not required.

munificent 10y ago
> Isn't this a simple instruction you give students in the very first class like "before you submit your homework, restart R session, and make sure your submission runs in the new session"? This only requires them to click a menu item (Restart R session), and a button (Knit or Source or something). It's the nature of learners to make mistakes. The more things they have to remember to do, the less cognitive power they'll have to focus on what they're trying to learn.
- minimaxir 10y ago
  That demand is the equivalent of pressing two buttons. (and yes, in my stats course as an undergrad I was also requested to reload and rerun R sessions to ensure code was correct)
- cheriot 10y ago
  That's a good point, though in this case the thing they need to remember is a key part of doing the job. Seeing a line of code run correctly once does not mean it's correct. It's one of those concepts that comes up in many forms. Perhaps one way to make a teachable moment of it is to help them set up a baby CI environment. Then every time it catches something the value of good practices is driven home.
capnrefsmmat 10y ago
Well, it doesn't just require them to click a menu item and hit a button -- then they have to fix all the problems that arose because RStudio encouraged a hackish development style. There's a workaround, but RStudio still actively encourages your workspace to get out of sync from your script. Compare that to DrRacket, where the code is labeled the "Definitions" window, and every time you reload the definitions, your workspace starts from scratch. You can't accidentally interact with deleted code. This would be a problem in a straight-line script where you're doing a bunch of data munging and analysis, since reloading from scratch might mean redoing expensive computations. But if you're building clean, reusable functions to implement interesting algorithms -- building a package and not a script -- then it's exactly the behavior you want. Our course very much focuses on software engineering. Major topics include writing modular code, object-oriented design, thorough testing, and version control. We don't cover statistics concepts in the class -- it's computing for statisticians, not computational methods in statistics. We believe that teaching statisticians to compute like software engineers will, in the long term, dramatically improve their work, since they'll have a stable base of robust, modular, well-tested, reusable code. One recent project, for example, required students to write a pipeline of scripts: one script takes the name of a CSV file as a command-line argument, processes and filters the data, and dumps it on STDOUT so the next script can read from STDIN and load the data into PostgreSQL, so another script (an R Markdown document) can do some queries and generate an automated report on the new batch of data. The processing and analysis stages have to be written as functions, not just top-level scripts, so they can be thoroughly tested. A future project will involve using dual k-d trees for fast approximate kernel density estimation, or building R trees to efficiently query spatial data. These are definitely more like packages than scripts.

huac 10y ago

I've required my students to turn in knitted pdf's from their R Markdown code. This course is more of an applied stats class, rather than stat computing, which I guess might make more sense. But it does ensure reproducibility (mostly, once we do away with working directories!). My difficulty is more that for most of these students, this is their first time using R or a real programming language. I had hoped that R Markdown would make the process simpler and more sensible. But the tendency of a student is to try different things, and not have a strong understanding of the logic behind those processes. So they create R Markdown files, and then gripe about how the code works in their IDE, but doesn't knit, and so knitr must be broken!

Homunculiheaded 10y ago

If you really want them to write "well-tested and modular algorithmic code" then you should teach them how to write packages in RStudio. Then require everything submitted to be in RMarkdown. I mentor learning data scientists and my advice is always to start using RMarkdown as soon they're remotely comfortable with RStudio. Not only does it avoid issues with an easily polluted global namespace, but more importantly encourages literate programming from the early stages. In stats/data science literate programming is vital to having any idea what you were working on a few months ago. It also makes writing reports much, much easier. RStudio makes it pretty easy to put together R packages, and the package structure for R does a great job of enforcing proper documentation and testing. Sourcing R files should primarily be used to quickly play around with ideas, or for exploratory data analysis that doesn't fit well inside an RMarkdown document. Any code you intended on reusing between projects should end up in a local package. I do think it's a problem that R has no intermediate method of organizing code like simple modules in Python. But this means if you're serious about writing clean R, you just have to bite the bullet and teach students to write packages.

willis77 10y ago

It feels like you are pinning a problem on RStudio that isn't RStudio's fault? A hammer is not a bad tool because it allows you to drive a nail into your own foot.

IndianAstronaut 10y ago

This is the same problem with Ipython notebooks as well. Lots of very segmented code that won't run as a block. But in general you really should run it from the top from time to time and learn best practices for error handling and such.

apathy 10y ago

have them write packages and turn in the vignette. problem solved

progman 10y ago

In Common Lisp you could take a snapshot of the current session with "save-image". Doesn't Racket provide something like that? http://stackoverflow.com/questions/480083/what-is-a-lisp-image http://stackoverflow.com/questions/480083/what-is-a-lisp-ima...