Parametricity and other principles - CompCon 2015

Presentation to university students about parametricity and other important principles for working programmers, at CompCon 2015.

Transcript

1. Parametricity and other principles Fraser Tweedale @hackuador October 4, 2015
2. Intro
3. Target audience Software developers whose goals are: Correct software Maintainable software Still correct after maintenance Move fast and don’t break things
4. Move fast and break things? “When you build something that you don’t have to fix 10 times, you can move forward on top of what you’ve built. It may not be quite as catchy as ‘move fast and break things’ but it’s how we operate now.” Mark Zuckerberg http://is.gd/vx3tgj
5. Outline Principles and tools for the working programmer Lots of opinions Mine, not my employer’s Some facts May contain traces of unfamiliar syntax Manufactured on equipment that also processes tree nuts
6. Language survey
7. On correctness
8. Correctness Doesn’t matter that much right? “But I’m only ever going to write _______” web things? boring business logic? games? Broken software has consequences Start caring; embrace the tools
9. Data modelling Model data responsibly Do your research Falsehoods programmers believe about {names, time, . . . } Make illegal state unrepresentable Newtypes, units of measure Immutability
10. Dynamic vs static typing
11. Dynamically typed languages Duck typing, type juggling, argh! Checking argument “types” is boring yet fraught Little help with program construction, refactoring Type checkers eliminate whole classes of errors for free Principled abstractions. . . where are they?
12. Criticisms of static typing Too verbose Types can’t capture the information in docs Types can’t catch all errors I need rapid feedback and the ability to prototype quickly But I like {Python, JavaScript, . . . }!
13. Verbosity # Python print("Enter your name: ", end=’’) name = input() print("Hi, " + name) -- Haskell main = do putStr "Enter your name: " name <- getLine putStrLn ("Hi, " ++ name)
14. Type system expressiveness
15. Type system expressiveness
16. Prototyping
17. Warm, fuzzy feelings
18. Type safety “People first need to feel the pain of runtime errors to understand why a type system is useful.” Python aficionado
19. Why don’t my programs work?
20. Escape hatches null values type casing (instanceof) type casting exceptions general recursion side-effects (I/O, impure functions)
21. Trap
22. I know what you’re thinking How will I do X without feature Y?
23. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y?
24. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects?
25. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects?
26. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful?
27. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis)
28. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis) It’s fine, I’ve got this.
29. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis) It’s fine, I’ve got this. No you don’t (and neither do I).
30. I know what you’re thinking How will I do X without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis) It’s fine, I’ve got this. No you don’t (and neither do I). Apologise to your team mates and future-self right now.
31. Total languages languages that guarantee program termination examples: Agda, Coq, Idris can express most programs (all that we care about in industry) most programmers are using non-total languages
32. Fast and loose reasoning reasoning about programs written in non-total langauges as if they were written in a total language. justified (mathematically) in Fast and loose reasoning is morally correct, Danielsson et al. 2006 costs nothing; you can write any program without using escape hatches and you gain composability referential integrity equational reasoning reuse
33. Parametricity
34. Parametric polymorphism (syntax) // Java generics static <A> List<A> f(List<A> xs) { ... } # Python (with PEP 484 type hinting) def f(xs : List[T]) -> List[T]: ... -- Haskell f :: [a] -> [a] f xs = ...
35. Parametric polymorphism Two function signatures: f :: [Int] -> [Int] g :: [ a ] -> [ a ] Which gives the programmer more information? Which is better?
36. Theorems for Free!
37. Parametricity “Write down the definition of a polymorphic function on a piece of paper. Tell me its type, but be careful not to let me see the function’s definition. I will tell you a theorem that the function satisfies.” Theorems for Free! Wadler 1989 Polymorphic types are: partial (sometimes complete) specifications implementor cannot use any type-specific behaviour caller has guarantee function will work for any type machine-checkable documentation a free source of useful theorems (parametricity)
38. Parametricity f :: [a] -> [a] What does this function do? reverse a list?
39. Parametricity f :: [a] -> [a] What does this function do? reverse a list? drop the first element?
40. Parametricity f :: [a] -> [a] What does this function do? reverse a list? drop the first element? ignore its argument return an empty list?
41. Parametricity f :: [a] -> [a] What does this function do? reverse a list? drop the first element? ignore its argument return an empty list? Theorem: every element in the output appears in the input
42. Parametricity f :: [a] -> [a] What does this function do? reverse a list? drop the first element? ignore its argument return an empty list? Theorem: every element in the output appears in the input Theorem: ∀ g. map g ◦ f = f ◦ map g
43. Parametricity f :: a -> (a, a) g :: a -> a -> a h :: b -> a -> a https://twitter.com/parametricity
44. Testing
45. Testing Who writes tests? Who likes writings tests? Ever missed a corner case?
46. Testing Recall our old friend: f :: [a] -> [a] It turns out we do want f to reverse lists Alas! ([a] -> [a]) does not mean reverse
47. Testing ∀ x. f [x] = [x] ∀ xs ys. f (xs ++ ys) = f ys ++ f xs f :: [a] -> [a] Now we’re good. A minimal (yet complete) algebraic specification for list reversal
48. Property-based testing write down properties of your functions tell the framework how to generate random values framework generates lots of data, tries to falsify properties the best test data is random test data QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs. Claessen and Hughes 2000 Talk: https://youtu.be/TSDTDqoH_vM
49. Theorem proving the best test data is no test data proof assistants: Agda, Coq, Idris no proof, no program can prove correctness, equivalence, complexity, . . . program extraction to other languages Idris talk/demo: https://youtu.be/4i7KrG1Afbk
50. Theorem proving “Beware of bugs in the above code; I have only proved it correct, not tried it.” Donald Knuth
51. Theorem proving “We are waiting for you to catch up, so we can employ you.” anonymous, NICTA (data61)
52. Wrapping up
53. Excuses But we are a {Java, C#, . . . } shop! We won’t be able to hire {Haskell, Scala, . . . } devs! The academic-ness, it burns!
54. Languages Scala, Frege, Clojure, Ermine (JVM) F# (Common Language Infrastructure) Swift (iThings) Do you really need to stick to {JVM, CLI}? Haskell, Rust
55. Libraries functionaljava scalaz swiftz xsharpx (C#)
56. Resources Brisbane Functional Programming Group http://bfpg.org/ #bfpg on Freenode or find an FP group in your city https://github.com/NICTA/course Software Foundations Course on mathematical underpinnings of reliable software http://www.cis.upenn.edu/~bcpierce/sf
57. Conclusion Responsible modelling of data is paramount Types are your friend Avoid traps and use fast and loose reasoning Parametric polymorphism gives you theorems for free Algebraic properties → more thorough tests with less effort Use the right tools
58. Fin Copyright 2015 Fraser Tweedale This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. Slides https://github.com/frasertweedale/talks/ Twitter @hackuador Email frase@frase.id.au