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.

1. The many faces
of modularity
Eric Torreborre

6. Why do we care?

7. Reduce complexity!

8. Isolation

9. Understanding

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

15. Foster creativity

16. Believe me?

19. Why is it so hard?

20. Denial

21. Functional programming?

23. Not an island

24. Not all parameters are equal
}
dependencies!

25. There are modules anyway!

27. Dependencies

28. High cohesion, low coupling

29. The butterfly effect
utils

30. What’s a dependency anyway?

31. car.engine.throttle.accelerate
vs
car.speedUp
The law of Demeter

32. Not a silver bullet

33. Lack of specifications

34. How modular is data?

35. Data is infectious

36. A better calendar

37. Extending is hard

38. Extending is hard

39. Mutable state, still

40. The other “assembly” language

41. A modularity language

42. A modularity language

43. A modularity language

44. A modularity language

45. A modularity language

46. Build tools

48. Planned obsolescence

49. SOAP

52. Assumptions will break

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

62. Multiple inheritance

63. Single inheritance

64. Aspects

65. Enterprise Java Beans

66. Annotations

67. Monkey patching

68. Renaissance

70. Control the dependencies, Luke!

71. Interface / implementation

72. Decomposition criteria

73. Think about domains!

74. Visualize dependencies

75. Have a librarian attitude

77. Monad transformers, effects,
final tagless, ReaderT,
how different?

78. Monad transformers 1995
Inflexible stack!

79. 2008
Algebraic effects
Types-heavy,
indirection,
Hard to rewire!

80. 2009
“Tagless final”

81. “Tagless final”, really?

82. 2009
“Tagless final”
Hierarchy of
instances!

83. 2017
ReaderT pattern

84. ReaderT = low-level only

85. 2017
ReaderT pattern
Low-level
dependencies only!

86. = it’s complicated
ReaderT

87. 1. recursive expressions
2. dependencies = graph
3. call context

88. AsyncNon-det.Bracket
Recursive expressions

89. Encapsulation

90. Typeclasses
Effects
Wiring
Traits
Static / Dynamic
Manual
Macros
Implicits

91. Functions all
the way down!
My take on wiring
https://skillsmatter.com/skillscasts/12299-wire-once-rewire-twice

92. }
dependencies!
Separate building from use

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!

99. Imperative = non-modular

100. Functional = modular

101. With ACID transactions!
2018

102. Use the types, Luke!

103. Generics

104. Parametric polymorphism

105. Typeclasses
MimeUnrender MimeRender

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