<div dir="ltr">Yesterday Taylor Russ asked<div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">  What it the proper citation for the lme4 package and the Bates' book?</span><br>
</div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)"> Also, can lme4 datasets (e.g., Pastes, ScotsSec, InstEval etc.) be
 used for illustration in publications?  Can the authors grant
 permission or is the permission from the source needed?

 Many thanks for the package and the book.  When can I hold a
non-digital copy in my hands?
</pre></div><div>I inadvertently deleted the message and so must respond without maintaining the thread.</div></div><div><br></div><div>The data sets can be used in other publications.  At least my understanding is that the data themselves cannot be copyright (despite the "Microsoft Patents 1's, 0's" headline in The Onion many years ago - for those of you who don't know that The Onion is a satirical newspaper, that didn't really occur).  It is only the representation of the data, such as a table in a copyright publication, that can be copyright.  I suppose I should provide the usual caveat, "I am (thankfully) not a lawyer".<br>
</div><div><br></div><div>The other lme4 authors may be able to respond to the question of citing the lme4 package.  I regret to say that I don't know of a good way of citing the book and that there won't be non-digital copies.</div>
<div><br></div><div>Partly this can be attributed to my personality - I'm good at starting projects but not so good at finishing them.  However, finishing the book would involve spending time maintaining and developing the lme4 package for CRAN and I have completely lost my enthusiasm for doing so.</div>
<div><br></div><div>As many of you know, I am doing most of my work in the Julia language (<a href="http://www.julialang.org">www.julialang.org</a>) now.  R is wonderful and I enjoyed most of my time working on R and R packages but there are inherent limitations to R, particularly when trying to achieve good performance on fitting complex models to large data sets, that make this difficult.  It would be attractive to have a "pure R" implementation of mixed-models but I don't see a way of making it run quickly and without using a lot of memory.  In Julia I can build a package that achieves good performance without the need to interface to code written in C, C++ or Fortran - in the sense that my package doesn't need to require compilation of code outside of that provided by the language itself.</div>
<div><br></div><div>It is not surprising that the design of R is starting to show its age.  Although R has only been around for 15-18 years, its syntax and much of the semantics are based on the design of "S3" which is 25-30 years old.</div>
<div><br></div><div>R packages can include code to be compiled along with the interface code and there are many wonderful tools to facilitate this - such as the Rcpp package, the devtools package and RStudio support for these packages.  I used these in the compiled code underlying lme4_1.0.</div>
<div><br></div><div>But even though Dirk would describe the use of Rcpp as "seamless", in my experience it is not, especially if you wish to have your package available on CRAN.</div><div><br></div><div>Maintaining an Rcpp-based package on CRAN these days is a case of "no good deed shall go unpunished" and "the flogging will continue until morale improves".  I am the maintainer of the RcppEigen package which apparently also makes me the maintainer of an Eigen port to Solaris.  When compilers on Solaris report errors in code from Eigen I am supposed to fix them.  This is difficult in that I don't have access to any computers running Solaris, which is a proprietary operating system as far as I can tell, and Eigen is a complex code base using what is called "template meta-programming" in C++.  Making modifications to such code can be difficult.  I can't claim to fully understand all the details in Eigen and in Rcpp.  I am a user of these code bases, not a developer. The Eigen authors themselves don't test their code under Solaris because they don't have access to Solaris systems either and they don't regard Solaris as an important platform for numerical computing.  The CRAN maintainers feel differently, which puts me in a box.</div>
<div><br></div><div>There are days when I am tempted to say, "okay, if RcppEigen is not suitable for CRAN then remove it" which would result in removal of all the packages that depend on it, including lme4.  That may seem childish of me but I really don't know what else to do.</div>
<div><br></div><div>So I have reached the point of saying "goodbye" to R, Rcpp and lme4 and switching all of my development effort to Julia.  I'm sorry but others are going to need to determine how to maintain lme4 to the satisfaction of the CRAN maintainers or whether there should be an alternative distribution mechanism for R packages.</div>
<div><br></div><div><br></div></div>