1. 2

    My work was essentially finished, the final application was very small, only a few screens of code. I was instructed to write unit tests for it just so managers could check a box; I resisted because the project was too small to have any units and tearing it apart to add these silly tests would mean destabilizing work that had already passed all tests and was ready to release.

    Reading this opening paragraph made me take everything after these first few lines, i.e. the entire article, with a grain of salt. “Tearing apart a project and destabilizing work already passed all tests” suggests the author writes highly coupled code with high cyclomatic complexity that could easily be destabilized. It also suggests the author lacks a nuanced perspective about what functions should be tested and how.

    Part of me sympathizes with the author – exclusively writing unit tests with testing frameworks like JUnit or the like makes me go crazy due to silly, repetitive, and often unreadable test framework structure/organization. But using a BDD framework like rSpec to TDD I find is useful and can help drive forward development of challenging features.

    1. 1

      Mostly cool, but GAH! Don’t suggest monkey-patching!!! Just because you can doesn’t mean you should! Also, what are the tradeoffs of using some of these “features and tricks”?

      1. 1

        Hm a bit of a broad question. All of them are useful in particular situations. Maybe with the exception of is.na(x) <- x > 5 which is just alternative function.

        Which of the listed examples would you consider to be “monkey-patching” ?

        1. 1

          that’s fair pushback :)

          I could be mistaken, but I was under the impression that cbind and rbind are less efficient than other methods to instantiate matrices in R, for example. My experience with vanilla R is that some of the more efficient operations are not very readable as software, which is part of the inspiration/adoption of tidyverse.

          Redefining the dollar operator’s API/what it returns feels pretty close to monkey-patching, imho. You do note it in the footnotes, but it seems like a dangerous thing to suggest unless there’s a really good reason to do so… I’m also not sure what dependency collision issues might arise if that redefinition is hidden in a library that is published and used. Maybe this is me just being overly paranoid, but my spidey-sense started ringing like crazy when I read that.

          1. 2

            rbind and cbind are slower if you call them iteratively (like building a matrix within a for loop and adding rows or columns one by one). But if you provide all the arguments to them directly, they shouldn’t be slow. Anyway, they are pretty well known so I mainly included them along for completeness in that section…

            Regarding the dollar operator - the primary role of $.class and .DollarNames.class methods is to provide a getter mechanism for your own custom-made classes. So the default data.frame dollar operators should not be overloaded. Instead, you should only consider them when creating a new class. BioConductor has a lot of classes that use this method. For example SerializedExperiment class is using it

            Also I think I get what you are trying to say. There might be a slight misconception about the intention of the article. My provided examples are there just to illustrate the functionality. They should not be taken as suggestions. So for example when I provide an example of *<- function - it is not a suggestion to go and do it. Just to show case what is possible in a simple way. The whole post is really a list of features I found useful while working on my own R packages. For example: operator assignment functions are used in inops, dollar method along with DollarName completion is used in annmatrix, all the matrix operations are used in matrixTests, and plotting hooks and palettes are used within basetheme. I have another similar post for discovered R bugs and inconsistencies.

            Basically - the function of the article is not to teach how to do something, but to showcase some corners of R that readers should then explore themselves. Also I expect the article to be more useful to people who are developing code in R, and probably less useful to someone who is just using R in their work (like maybe the users of tidyverse).

            BTW - it’s nice to find someone on lobsers that cares about R :) When posting this article I was not sure what kind of reaction I will get (if any).

            1. 1

              ower if you call them iteratively (like building a matrix within a for loop and adding rows or columns one by one). But if you provide all the arguments to them directly, they shouldn’t be slow. Anyway, they are pretty well known so I mainly included them along for completeness in that section…

              TIL!

              Regarding the dollar operator - the primary role of $.class and .DollarNames.class methods is to provide a getter mechanism for your own custom-made classes. So the default data.frame dollar operators should not be overloaded. Instead, you should only consider them when creating a new class. BioConductor has a lot of classes that use this method. For example SerializedExperiment class is using it

              Makes a lot of sense – good clarification.

              Also I think I get what you are trying to say. There might be a slight misconception about the intention of the article. My provided examples are there just to illustrate the functionality. They should not be taken as suggestions. So for example when I provide an example of *<- function - it is not a suggestion to go and do it. Just to show case what is possible in a simple way. The whole post is really a list of features I found useful while working on my own R packages. For example: operator assignment functions are used in inops, dollar method along with DollarName completion is used in annmatrix, all the matrix operations are used in matrixTests, and plotting hooks and palettes are used within basetheme. I have another similar post for discovered R bugs and inconsistencies.

              Another great clarification – I initially read it as “hey, checkout these cool shortcuts I regularly use in R”. The usecase is much clearer now.

              Basically - the function of the article is not to teach how to do something, but to showcase some corners of R that readers should then explore themselves. Also I expect the article to be more useful to people who are developing code in R, and probably less useful to someone who is just using R in their work (like maybe the users of tidyverse).

              Makes sense – I’ve turned to tidyverse as I’ve ramped up, but learning a language in its vanilla forms has a lot of benefits too.

              BTW - it’s nice to find someone on lobsers that cares about R :) When posting this article I was not sure what kind of reaction I will get (if any).

              I recently changed careers to back towards data analysis side of things and have had to learn R, but don’t want to sacrifice the hard-earned programming knowledge I’ve gotten along the way! Nice to see articles treating R like a real language and reasoning about it like professional programmers might, too. Thanks for posting and I look forward to future posts!

        1. 2

          This is a great succinct write up :) Thanks for sharing, definitely puts into words many of the thoughts I’ve been having since the whitepaper dropped.

        1. 2

          This isn’t about whether Facebook would do a good job at it. It’s about one company having control over you as an individual, and large groups as collectives. Control by way of information/data, and now control by way of having their “hands” on your money.

          1. 3

            Definitely. The broader implications to me, at least, are that while “likes” are a powerful signal at scale, money transactions contain more signal because they’re a reflection of an tangible action you’ve taken rather than an opinion you’ve expressed. We tend to cede control of this information to governments who use the data as a barometer of health in a number of domains, but if a profit driven corporation gets their hands on those data…I cringe at the broad implications.

            1. 1

              I’d like to point out that you don’t have to bank with facebook. Large parts of Europe still use cash on a daily basis. Not because you can’t pay digitally, but because we don’t want to.

              1. 5

                Large parts of Europe still use cash on a daily basis. Not because you can’t pay digitally, but because we don’t want to.

                I’d suggest that the Western world is not really the target market for this, but rather developing countries that remain almost entirely unbanked, many of which use facebook as their main method to access the internet. This is the bit that scares me.

                1. 3

                  Smaller parts of Europe (Sweden) is almost cash-less already.

                  But the same applies there - why should I get ZuckBucks on FB when I can just use Swish to send money to anyone with a mobile phone?

                  1. 1

                    Cross-border transactions?

                    1. 1

                      I’m not going to deny that Libra can be a success, and there’ll be lots of use cases for lots of people that I can’t imagine (but I bet FB can). My point in my comment was to offer another viewpoint about cash use in Europe. Sweden is so cashless that the authorities are legitimately worried about the effect of a long-time net outage or cyberattack on the economy.

                      For my personal use cases Libra doesn’t offer anything new though. I use PayPal to send money overseas.