A New Approach to Modularity

## A new approach to Modularity
            Wroclove.rb 2026 Lightning talk
            
            [tomash.eu](https://tomash.eu)
            
            ---
            ## Why is Modularity so important?

Cognitive load. 4-7 "things" at a time.
            ---
            ## A brief history of Modularity
            ---
            * Macro Assemblers (1950s)
            * Subroutines & Libraries: FORTRAN (1957) and COBOL (1959)
            * Structured Programming (late 1960s), Dijkstra 1968 on GOTO
            * Information Hiding & Modules (1970s), Parnas 1972
            * Abstract Data Types & Objects (1970s-80s), Liskov, Smalltalk, C++
            ---
            * Component & Interface-Based Design (1990s)
            * Design Patterns & Architecture (mid-1990s)
            * Package Managers & Open Source Ecosystems (2000s)
            * Microservices (2010s)
            * Modern Module Systems (2010s–present)
            ---
            ## All had one thing in common
            Code understanding is expensive. Code writing is expensive.
            ---
            ## Those are no longer true.
            Code understanding (pattern recognition) is cheap. Code writing (pattern reproduction) is cheap.
            ---
            ## What is still expensive
            1. Reviewing
            2. Shipping 
            3. **Downtime**
            4. Reverting
            ---
            ## A new approach to Modularization
            Modules as well-isolated blocks, with defined inputs and outputs and side effects.
            
            **When requirements change, Module is not updated. It is deleted and rewritten from scratch.**
            ---
            ## ACKCHYUALLY
            It's Erlang philosophy. 
            ---
            * 1. Small, focused modules (but not over-engineered)
            * 2. “Let it crash”
            * 3. Modules are replaceable at runtime
            * **4. Prefer rewriting over over-abstracting**
            * 5. Process owns state and errors
            ---
            ## Can this be applied to Ruby?
            Of course.
            ---
            ### Current tooling is piece-your-own
            * Flipper: control entry point
            * Namespaces and subdirectories: isolate component
            * Packwerk: public/private on component level
            * State and error handling in "main app"
            ---
            ## Embrace the slop

Generate messy component, isolate it, control availability.
            
            Then delete it or rewrite again.

Don't worry.
            ---