The many faces of modularity
0 likes591 views
Modularity reduces complexity by isolating components and allowing for reuse. It is difficult to achieve true modularity due to dependencies between modules, lack of clear specifications, and assumptions that will break over time. The document outlines the history of modularity in programming languages from the 1960s to present day, and recommends using functional programming techniques like typeclasses, effects, and wiring libraries to help achieve modularity. It acknowledges modularity is complicated and there are no silver bullets, but emphasizes controlling dependencies, separating building from use, and using the type system to help manage complexity.
The many faces of modularity
- 1. The many faces of modularity Eric Torreborre
- 6. Why do we care?
- 8. Isolation
- 10. Understanding
- 11. “Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure.” Conway’s law
- 13. Reuse
- 14. Open-source
- 16. Believe me?
- 19. Why is it so hard?
- 20. Denial
- 23. Not an island
- 24. Not all parameters are equal } dependencies!
- 25. There are modules anyway!
- 27. Dependencies
- 28. High cohesion, low coupling
- 30. What’s a dependency anyway?
- 32. Not a silver bullet
- 34. How modular is data?
- 40. The other “assembly” language
- 46. Build tools
- 49. SOAP
- 53. Why is it so hard? Denial The butterfly effect Lack of specifications A modularity language Extending is hard We keep changing the techno! Mutable state, still Data is infectious Assumptions will break!
- 54. Where’s hope?
- 55. A short historyA short, incomplete historyA short, incomplete and imprecise history 1958 Lisp 1967 Simula 1960 ALGOL 1978 ADA 1983 C++ 1977 Modula 1995 Java/Python/Ruby 1984 SML 1998 Haskell
- 56. Procedures 1960
- 57. Class Glyph; Virtual: Procedure print Is Procedure print;; Begin End; Glyph Class Char (c); Character c; Begin Procedure print; OutChar(c); End; Glyph Class Line (elements); Ref (Glyph) Array elements; Begin Procedure print; Begin Integer i; For i:= 1 Step 1 Until UpperBound (elements, 1) Do elements (i).print; OutImage; End; End; End; 1967 Objects
- 58. 1977 Modules
- 59. User data types 1978
- 60. 1984 SML modules
- 61. The dark ages
- 64. Aspects
- 66. Annotations
- 67. Monkey patching
- 68. Renaissance
- 70. Control the dependencies, Luke!
- 75. Have a librarian attitude
- 77. Monad transformers, effects, final tagless, ReaderT, how different?
- 78. Monad transformers 1995 Inflexible stack!
- 84. ReaderT = low-level only
- 87. 1. recursive expressions 2. dependencies = graph 3. call context
- 89. Encapsulation
- 91. Functions all the way down! My take on wiring https://skillsmatter.com/skillscasts/12299-wire-once-rewire-twice
- 93. Separate building from use
- 94. No tagless final No MTL No effects No DI Easy!Easy, buy it now!Not so fast :-)
- 95. Not so fast :-)
- 96. Reader pattern where necessary Wiring library A good IO type Interfaces My recommendation
- 98. Use FP, Luke!
- 100. Functional = modular
- 102. Use the types, Luke!
- 103. Generics
- 106. Higher-kinded data
- 107. A look at the future
- 108. 522 .c files 260000 LOC 811 conf. options Variational typing
- 109. Modules research
- 110. Modules research Weak vs Strong modularity Small vs Large modularity
- 112. Thank you!
- 113. The many faces of modularity Eric Torreborre