[Rd] Programming Tools CTV

[Max Kuhn]

On Thu, Jan 22, 2015 at 1:05 PM, Achim Zeileis <Achim.Zeileis at uibk.ac.at> wrote:
> On Thu, 22 Jan 2015, Max Kuhn wrote:
>
>> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis
>> <Achim.Zeileis at uibk.ac.at> wrote:
>>>
>>> On Thu, 22 Jan 2015, Max Kuhn wrote:
>>>
>>>> I've had a lot of requests for additions to the reproducible research
>>>> task view that fall into a grey area (to me at least).
>>>>
>>>> For example, roxygen2 is a tool that broadly enable reproducibility
>>>> but I see it more as a tool for better programming. I'm about to check
>>>> in a new version of the task view that includes packrat and
>>>> checkpoint, as they seem closer to reproducible research, but also
>>>> feel like coding tools.
>>>>
>>>> There are a few other packages that many would find useful for better
>>>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark,
>>>> pkgutils, etc.
>>>>
>>>> This might be some overlap with the HPC task view. I would think that
>>>> rJava, Rcpp and the like are better suited there but this is arguable.
>>>>
>>>> The last time I proposed something like this, Martin deftly convinced
>>>> me to be the maintainer. It is probably better for everyone if we
>>>> avoid that on this occasion.
>>>>
>>>> * Does anyone else see the need for this?
>>>>
>>>> * What other packages fit into this bin?
>>>>
>>>> * Would anyone like to volunteer?
>>>
>>>
>>>
>>> Max, thanks for the suggestion. We had a somewhat related proposal on
>>> R-help
>>> from Luca Braglia a couple of months ago, suggesting a "Package
>>> Development"
>>> task view:
>>> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html
>>>
>>> He put up some ideas on Github:
>>> https://github.com/lbraglia/PackageDevelopmentTaskView
>>>
>>> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer)
>>> for
>>> feedback off-list, I replied that it is important that task views are
>>> focused in order to be useful and maintainable. My feeling was that
>>> "PackageDevelopment" was too broad and also "ProgrammingTools" is still
>>> too
>>> board, I think. This could mean a lot of things/tools to a lot of people.
>>>
>>> But maybe it would be to factor out some aspect that is sharp and
>>> clear(er)?
>>> Or split it up into bits where there are (more or less) objectively clear
>>> criteria for what goes in and what does not?
>>
>>
>> It's funny that you said that. As I was updating the RR CTV, it
>> realized what a beast it is right now. I thought about making a github
>> project earlier today that would have more detailed examples and
>> information.
>>
>> I see two problems with that as the *sole* solution.
>>
>> First, it is divorced from CRAN CTV and that is a place that people
>> know and will look. I had no idea of Luca's work for this exact
>> reason.
>>
>> Secondly, might be intimidating for new R users who, I think, are the
>> targeted cohort for the CTVs.
>
>
> Yes, I agree. There should (an) additional task view(s) on CRAN related to
> this.
>
>> How about a relatively broad definition that is succinct in content
>> with a link to a github repos?
>
>
> I think this doesn't fit well with the existing development model and might
> require duplicating changes in the <packagelist> of the task view. In order
> to be easily installable I need the <packagelist> in the task view on CRAN
> and not just in the linked list on Github.

Many of the task views are encyclopedic and still focused. Perhaps my
issues with RR are more related to how I currently organize it. I'll
try to solve it that way.

> Therefore, I would suggest splitting up the topic into things that are
> fairly sharp and clear. (Of course, it is impossible to avoid overlap
> completely.) For example, one could add "LanguageInterfaces" or something
> like that.

Looking at Luca's page, I think he does a great job of clustering
packages. My suggestions for focused topics are:

- Package Development*
- Foreign Languages Interfaces
- Code Analysis and Debugging
- Profiling and Benchmarking
- Unit Testing

* I would define the first one to be more narrow than the original definition.

I think that most of these would encompass less than 10 packages if we
don't include all the Rcpp depends =]

> And the task views on CRAN can always include <links> to further
> documentation on Github and elsewhere. Especially when it comes to package
> development there are also clearly different preferences about what is good
> style or the right tools (say Github vs. R-Forge, knitr vs. Sweave, etc.)

Yes. The comments above would not exclude this approach, which
is/was/might be my intention for RR.

Thanks,

Max