Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Design of everyday functions

Hadley Wickham
September 18, 2018

Design of everyday functions

Hadley Wickham

September 18, 2018
Tweet

More Decks by Hadley Wickham

Other Decks in Technology

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