https://peertube.lagbag.com/videos/watch/3998e406-98d3-4a3e-b8ef-f30ae575630e Hardware got a million times faster, yet your text editor still stutters. The reason isn't progress — it's software amnesia. Five academic papers solved the complexity crisis decades ago, and the industry quietly forgot every one of them. This is an analytical essay on the five papers that already answered the bloat, the leaks, and the latency we fight today: Parnas on information hiding, Liskov on abstract data types, Dijkstra on structured programming, Hoare on proving programs correct, and Brooks on why no framework will ever be the silver bullet. The thesis is uncomfortable — the industry didn't innovate, it rotated. Each generation re-derives a heavier, slower version of what the last one already proved on paper, with mathematics, before most modern frameworks were born. ☕ Support Macro Lens on Patreon → https://www.patreon.com/c/MacroLens Independent, ad-light deep-dives. Patreon keeps them that way. ━━━━━━━━━━━━━━━━━━ RELATED VIDEO FROM THE CHANNEL ━━━━━━━━━━━━━━━━━━ If this lands, the natural next watch is "Senior Engineers Write Ugly Code on Purpose. Here's Why." — the same idea applied to people instead of papers: the most senior engineers write the plainest, least clever-looking code in the room, and it's for the exact reason these five papers have outlived every framework built since. ━━━━━━━━━━━━━━━━━━ CHAPTERS ━━━━━━━━━━━━━━━━━━ 0:00 The editor that forgets 1:03 The Great Regression 2:29 Parnas 1972: information hiding 3:59 Liskov 1974: the data contract 5:50 Dijkstra & Hoare: reasoning vs running 7:07 Sympathy for the hardware 8:01 Brooks: No Silver Bullet 9:17 Open your dependency tree ━━━━━━━━━━━━━━━━━━ PAPERS & CONCEPTS MENTIONED ━━━━━━━━━━━━━━━━━━ Parnas (1972) — "On the Criteria To Be Used in Decomposing Systems into Modules" → information hiding, Liskov & Zilles (1974) — "Programming with Abstract Data Types" → CLU, the data contract, Dijkstra (1968) — "Go To Statement Considered Harmful" → structured programming, Hoare (1969) — "An Axiomatic Basis for Computer Programming" → the Hoare triple, proving correctness, Brooks (1986) — "No Silver Bullet" → essential vs accidental complexity, Related ideas: the distributed monolith, leaky abstractions, sympathy for the hardware, ━━━━━━━━━━━━━━━━━━ FAQ ━━━━━━━━━━━━━━━━━━ What is information hiding? It's Parnas's rule that each module should hide one design decision likely to change behind a stable interface, so when that decision changes you only open one module. What did Parnas's 1972 paper say? That you should decompose a system by what each module HIDES, not by the steps it performs — cutting by the flowchart is the mistake that produces tightly coupled systems. What is a distributed monolith? A system sliced into many services by steps rather than secrets, so every service knows the internals of every other — all the coupling of one program plus network latency between every call. What is the difference between essential and accidental complexity? Brooks split software difficulty into essential complexity (the genuinely hard problem you're modeling) and accidental complexity (the mess from your tools and platform). No single framework gives a 10x gain because most of what's left is essential. Why is modern software slower despite faster hardware? Because abundance removed the constraint that forced early engineers to be precise — we manufacture accidental complexity with bloated tooling and spend hardware to avoid reasoning about it. #softwareengineering #programming #computerscience #softwarearchitecture #coding Fri, 03 Jul 2026 21:46:31 GMT https://validator.w3.org/feed/docs/rss2.html PeerTube - https://peertube.lagbag.com https://peertube.lagbag.com/client/assets/images/icons/icon-1500x1500.png https://peertube.lagbag.com/videos/watch/3998e406-98d3-4a3e-b8ef-f30ae575630e All rights reserved, unless otherwise specified in the terms specified at https://peertube.lagbag.com/about and potential licenses granted by each content's rightholder.