Raptor's Nest

The topic of this post was mentioned in a tangential rant featured in my previous post , and I thought I might as well expand on this a bit. I'm not going to talk about programming language model or anything like that since I'm not a programmer - rather, I will treat this more like a tutorial or a "Pro-tip" kind of post. I will be focusing on an aspect of R that is often taken for granted and maybe not well known by entry-level users. That is, R is an object-oriented programming language. If you already know this, then this blog post is not for you. First, I'll list out a few interesting/useful features of R: R is interpretable R is based on vectors R can utilise functions (e.g. functional programming) R utilises objects (object-oriented programming) Like I've already mentioned, this post will focus on point 4, that R is an object-oriented programming language (or simply that R can be object-oriented if you don't want to call R a program

I'm all for open access. I'm all for open source. I'm all for reproducible science. I'm all for replicable studies. So I like that data are shared. I like that protocols are shared. I also really appreciate it when code is shared - but only when it is appropriate. Times that I think are appropriate to share code are, for instance, when there's an entirely new method introduced - then I think it is important to release the code/script as source code, package, program etc so that it enables other scientists to reproduce your work or use it in their own analyses. However, I've noticed that, often times, shared code/script are nothing more than just the authors' workflows - in which case I don't want to see it. Everyone has a different workflow and I don't want to have to get into the heads of other people to figure out exactly what I'm looking at and what the code is doing - because commonly associated with shared workflow are uncommented