![David Parnas (1972)
"We propose [...] that
one begins with a list
of difficult design
decisions or design
decisions which are
likely to change. Each
module is then
designed to hide such
a decision from the
others.."](https://image.slidesharecdn.com/things-we-never-told-about-fp-250119094057-c3e5bc1c/85/Things-We-Never-Told-Anyone-About-Functional-Programming-22-320.jpg)
Things We Never Told Anyone About Functional Programming
- 1. Things We Never Told Anyone About Functional Programming Michael Sperber @sperbsen@discuss.systems
- 2. • software development with FP • software reviews • training www.active-group.de funktionale-programmierung.de
- 3. bobkonf.de Mar 14, 2025, Berlin
- 4. FP What is it good for?
- 5. Functional Programming CC BY 4.0, https://free-vectors.net/business/marked-checklist-vector Build Software Systems to Fulfill Requirements
- 6. ICFP Papers and Events
- 7. ICFP 2024 Distinguished Paper “use-cases ... type-checkers and automated theorem provers”
- 8. S. L. Peyton Jones and J.-M. Eber How to write a financial contract. 2001 Build a combinator library! https://www.flickr.com/photos/tambako/4237063719 CC BY-ND 2.0
- 9. ¬FP
- 10. Software Systems (for People) • fulfill (human) requirements • make lives better • programmed by people
- 11. What It Takes • connecting requirements and software • programming in the small • programming in the large and in the long • human activities around this
- 12. Software System Qualities https://quality.arc42.org/articles/arc42-quality-model
- 13. (Functional) Requirements and Programming in the Small • data • functions
- 14. Programming in the large ... and in the long?
- 15. Human Activities
- 17. What It Takes • connecting requirements and software • programming in the small • programming in the large and in the long • human activities around this
- 18. $ = Δ Programming in the Large and in the Long 1979
- 19. Evolutionary Software Quality Source: Markus Harrer Functional Suitability Reliability Usability Performance Efficiency Security Maintainability Compatibility Portability Time
- 20. Functionality and Architecture Bass, Kazman, Clements: Software Architecture in Practice
- 21. $ = Δ Programming in the Large and in the Long
- 22. David Parnas (1972) "We propose [...] that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.."
- 23. https://www.wps.de/en/news/the-modulith-salvation-for-the-monolith The Monolith is Unmodular
- 25. Decoupled by Default • immutability • abstraction boundaries • expressive interface languages • expressive effects
- 26. https://www.isaqb.org/certifications/advanced-level/?lang=en Putting it all together
- 27. A Blueprint for Functional Software Design • bottom-up • start with functional qualities • everything is data • data modeling with sums and products • abstraction • combinator models • algebraic structures • mathematical properties
- 28. Bottom-Up
- 29. Data Modeling • functions • data • products • sums FTW https://funktionale-programmierung.de/2024/11/25/sums-products-english.html
- 30. What We Model When We Model - OO Quelle: Wikipedia CC Attribution 3.0 Unported
- 31. What We Model When We Model - FP Quelle: Wikipedia CC Attribution 3.0 Unported
- 32. A World of Objects (© Trustees of the British Museum)
- 34. Architecture Evolution • model domain with data • implement functions • change to achieve quality-specific requirements low coupling = pΔ functionality
- 35. Abstraction λ□.
- 37. Combinator Libraries • compositionality • abstraction • purity • modifiability • maintainability • privacy (actual rules are secret) • separation of concerns • junk-freeness / -quantification • efficiency
- 40. Mathematics = Brain Patterns for Thinking
- 43. FP/Mathematics and Humans • Model Human Understanding (rather than the thing) • Immutability FTW • Maths = Patterns for Human Understanding
- 44. Properties
- 46. FP FTW!
- 47. FP Todos • top-down FP design (and meet-in-the-middle) • architecture documentation patterns & visualization • stakeholder communication • books • cross-pollination with the non-FP types
- 48. How to Split a System into Building Blocks
- 49. How to Split a System into Parts
- 52. Cross-Functional Teams Frontend Business Logic Database Frontend Business Logic Database Frontend Business Logic Database separate databases!
- 53. Issues with Self-Contained System • it’s a distributed system now • model consistency • properties of event streams
- 54. Possible FP Contributions • modular monoliths • rehabilitate Parnas • practical distributed systems • bounded-context consistency • flexible self-contained systems
- 55. A Call to Action • How did you do it? • What are your requirements? • Did you write it up? • Who did you talk to? • Who did you listen to? • What have you learned? • What have you taught?
Editor's Notes
- #5: I’m expecting people to jump up and say no “play mind games and publish papers”. We’ll get to that. The same goes for functional languages, BTW.
- #7: You might say “experience reports”, but those mostly show what somebody did, not how. But wait ...
- #29: functions was what differentiated from OOP, no longer
- #37: meet functional requirements facilitate communication decouple representation from semantics slow down change fulfill future requirements without or with small changes
- #39: --- and mathematics in general