Math For Programming
A math book for the curious.
For updates, sign up here:
Contents
Part I: Practical Contextual Math
(Arithmetic, Probability)- 1. Introduction: How Math fits in to Programming
- 2. Arithmetic, Algorithms, and Numbers
- 3. Not Financial Advice
Part II: Basics of Math for Programming
(Logic, Functions, Comparisons, Computation, Set Theory, Base Systems)- 4. Program Execution and Math Analogs
- 5. Programming Structures and Math Analogs
- 6. A few Bits about Architecture
Part III: Growing and Showing Software with Math
(Algebra, Analytic Geometry, Complexity, Stats, Data Visualization, Calculus, Number Theory)- 7. Scaling Programs with Math
- 8. Managing Projects with Math: Estimation, Predictions, and Visualization
- 9. Showing off: Promoting and selling
- 10. Keeping and Sharing Secrets
Part IV: Architectural Sophistication
(Abstract Algebra, Set Theory, Category Theory, Type Theory, Proofs)- 11. Functional Programming I: Compositional Programs
- 12. Functional Programming II: Algebraic Architecture
- 13. Guarantees Through Tests, Types, and Proofs
Part V: Games
(Probability, Trigonometry, Calulus, Linear Algebra)- 14. Games I: Up to 2.5 Dimensions
- 15. Games II: 3 Dimensions
Part VI: Machine Learning
(Cumulative)- 16. Machine Learning
- 17. Projects
Findings, Claims, Conjectures, and Suspicions
Here is some of the information that I discuss and demonstrate in the book. I don't claim these to be original discoveries so much as ones that I feel deserve more engagement relative to tooling concerns which dominate so much of our time.
- Confidence in code is informed by trust, along with experience and choice of guarantees in the program.
- A standard of confidence in a given program can be decided upon by its context and purpose.
- Abstract Algebra can help determine the cardinality of inputs and outputs of your program (the "surface area of testing").
- Abstract Algebra can help identify UX features to adopt or anticipate.
- Category theory can give functional programming a good basis of understanding language and framework features.
- Empathy : Testing :: Representation : Types
- Guarantees ⊆ Possibilities ⊆ Ambitions ⊆ Imagination
- A test is a direct proof.
- A well formed error message provides the basis for a contrapositive proof.
- A characterization test is a proof by contradiction
- Inductive data types provide the basis for inductive proofs.
- A weakness of proofs via types vs tests is the ability to refactor implementation code without breaking guarantees. In other words, tests shouldn't break unless your interface changes, but proofs likely rely on implementation details.
References & Resources
(free materials are denoted by an asterisk)(work in progress)
About the author
