So much to critique in this article, but I decided to pick on this: "THE codebase becomes impossible to maintain" "THE codebase becomes too complex and unmaint

So much to critique in this article, but I decided to pick on this: "THE codebase becomes impossible to maintain" "THE codebase becomes too complex and unmaintainable" "What makes THE codebase complex?" I count fifteen references to "the codebase." THE codebase. THE. Well your program consists of more than one codebase! What then? Here's some code that ran on the linked site: window.webpackJsonp = window.webpackJsonp || []).push([[8], { "./config/polyfills.js": function(e, t, n) { Medium (codebase A) dynamically interrogates the API provided by my browser (codebase B) as influenced by plugins (codebase C) linking the UI framework of my OS (codebase D) and then loads some polyfills provided by Babel (codebase E)... Which one is "the codebase?" Your runtime environment is multiple components, each evolving independently! How do you write reliable software here? You can use static types but can't trust them, they can't predict the future and don't know the past. You want runtime interrogation and reflection. You want graceful degradation and dynamic polyfills. You need late bound interfaces. You need objects, not ADTs. This I think is the heart of the OOP idea: software components realized in classes/objects/messages which can evolve truly independently. Drop the "THE codebase" assumption and some of OOP's strengths will appear.