Design of everyday functions

Transcript

1. The DESIGN 

   of EVERYDAY 

   FUNCTIONS
   Hadley Wickham

   @hadleywickham

   RStudio
   September 2018
   

   View Slide

2. Practitioner Programmer
   

   View Slide

3. Interactive
   Easily detect & resolve problems
   Packaged
   In production
   You hear your code Things break and
   people at you
   Practitioner Programmer
   

   View Slide

4. Notebook IDE
   https://yihui.name/en/2018/09/notebook-war/
   The First Notebook War
   Data analyst Engineer
   

   View Slide

5. Me
   You
   Practitioner Programmer
   

   View Slide

6. Code is a conversation
   Ambiguity can be tolerated
   early and often
   Practitioner Programmer
   Implicit Explicit
   

   View Slide

7. Practitioner Programmer
   Implicit Explicit
   

   View Slide

8. What makes a
   good door?
   https://99percentinvisible.org/article/norman-doors
   

   View Slide

9. View Slide

10. “When you have trouble with things—whether
    it’s figuring out whether to push or pull a door or
    the arbitrary vagaries of the modern computer
    and electronics industries—it’s not your fault.
    Don't blame yourself: blame the designer...”
    — Donald A. Norman
    

    View Slide

11. https://twitter.com/irismwang/status/994349937944158208
    

    View Slide

12. https://twitter.com/BrockTibert/status/1009543843690278920
    

    View Slide

13. https://twitter.com/mattfrost/status/768078660200898560
    

    View Slide

14. https://twitter.com/gshotwell/status/675344503566417921
    

    View Slide

15. https://twitter.com/PetrelStation/status/1038043993387552768
    

    View Slide

16. https://twitter.com/NateApathy/status/1030263775205707776
    

    View Slide

17. https://twitter.com/scottmccain5/status/986275394692272129
    

    View Slide

18. “Rule of thumb: if you think
    something is clever and
    sophisticated, beware — it is
    probably self-indulgence.”
    — Donald A. Norman
    

    View Slide

19. WAT makes a bad
    function?
    https://www.destroyallsoftware.com/talks/wat
    

    View Slide

20. c(factor("a"), factor("b"))
    What happens when you combine two factors?
    

    View Slide

21. c(factor("a"), factor("b"))
    #> [1] 1 1
    What happens when you combine two factors?
    WAT!
    

    View Slide

22. today <- as.Date("2018-09-18")
    lunch <- as.POSIXct("2018-09-18 12:00",
    tz = "Europe/Belgrade")
    c(today, lunch)
    What happens when you combine a date and a date-time?
    

    View Slide

23. today <- as.Date("2018-09-18")
    lunch <- as.POSIXct("2018-09-18 12:00",
    tz = "Europe/Belgrade")
    c(today, lunch)
    #> [1] "2018-09-18"
    #> [2] "4210927-01-24"
    What happens when you combine a date and a date time?
    WAT!
    

    View Slide

24. today <- as.Date("2018-09-18")
    lunch <- as.POSIXct("2018-09-18 12:00",
    tz = "Europe/Belgrade")
    c(lunch, today)
    What happens when you combine a date and a date-time?
    

    View Slide

25. today <- as.Date("2018-09-18")
    lunch <- as.POSIXct("2018-09-18 12:00",
    tz = "Europe/Belgrade")
    c(lunch, today)
    #> [1] "2018-09-18 12:00:00 CDT"
    #> [2] "1969-12-31 22:56:32 CST"
    What happens if you touch a date-time the wrong way?
    WAT!
    

    View Slide

26. lunch <- as.POSIXct("2018-09-18 12:00",
    tz = "Europe/Belgrade")
    lunch
    #> [1] "2018-09-18 12:00:00 CEST"
    c(lunch)
    c(NULL, lunch)
    What happens if you look at a date-time the wrong way?
    

    View Slide

27. lunch <- as.POSIXct("2018-09-18 12:00",
    tz = "Europe/Belgrade")
    lunch
    #> [1] "2018-09-18 12:00:00 CEST"
    c(lunch)
    #> [1] "2018-09-18 05:00:00 CDT"
    c(NULL, lunch)
    #> [1] 1537264800
    What happens if you look at a date-time the wrong way?
    WAT!
    WAT!!
    

    View Slide

28. What makes a good
    function?
    one aspect of
    ^
    

    View Slide

29. c(, ) ->
    c(>) ->
    c(NULL, >) ->
    Types can give us a high-level overview of a function
    I’ll put types in angle brackets to make
    clear that this is not real R code
    

    View Slide

30. To do that we need to review some foundations
    Atomic
    Numeric
    Logical Integer Double Character
    

    View Slide

31. c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    c(, ) ->
    For atomic vectors, the rules are simple
    

    View Slide

32. For atomic vectors, the rules are simple
    Logical Integer Double Character
    Logical logical integer double character
    Integer integer integer double character
    Double double double double character
    Character character character character character
    

    View Slide

33. For atomic vectors, the rules are simple
    Logical
    Integer
    Double
    Character
    Even if you’re never explicitly
    learned this, I think you
    internalise it quickly.
    

    View Slide

34. Unfortunately c() breaks down when we get to S3 vectors
    Atomic
    Numeric
    Logical Integer Double Character
    factor POSIXct Date
    S3 vectors
    

    View Slide

35. Figuring out the rules is the goal of the vctrs package
    http://vctrs.r-lib.org
    

    View Slide

36. mutate() ->
    filter() ->
    select() ->
    arrange() ->
    summarise() ->
    group_by() ->
    The types of the primary dplyr functions are simple
    

    View Slide

37. if_else(, , ) ->
    if_else(, , ) ->
    if_else(, , ) -> ???
    if_else(, , ) -> ???
    if_else(, , ) -> ???
    if_else(, , ) -> ???
    But there are a few that are more complex
    

    View Slide

38. x <- runif(6)
    if_else(x > 0.5, x, NA)
    #> Error: `false` must be type double,
    #> not logical
    Which leads to this annoyance
    

    View Slide

39. x <- runif(6)
    if_else(x > 0.5, x, NA)
    #> Error: `false` must be type double,
    #> not logical
    if_else(x > 5, x, NA_real_)
    #> [1] NA 0.700 0.557 NA NA NA
    Which leads to this annoyance
    You’re currently forced to learn
    about the “typed” NAs
    

    View Slide

40. if_else(, , ) ->
    vec_c(, ) ->
    
    if_else(, , ) ->
    vec_c(, ) ->
    
    I think I'm starting to see the principles
    

    View Slide

41. Fin
    

    View Slide

42. Practitioner Programmer
    Implicit Explicit
    Interactive
    Easily detect & resolve problems
    Packaged
    In production
    Code is a conversation
    Ambiguity can be tolerated early and often
    

    View Slide

43. https://adv-r.hadley.nz/vectors-chap.html
    http://vctrs.r-lib.org
    https://www.destroyallsoftware.com/talks/wat
    https://99percentinvisible.org/article/norman-doors
    WAT!
    http://bit.ly/everyday-functions
    

    View Slide