Reference Types vs Value Types: the Original Sin of Programming
Gentle reader, you might know where this is written, better than I have written it here, and perhaps canonically: there aren’t that many kinds of code, right? It seems to me that in any language, any given statement or expression can be reduced to one (or a composite) of these two kinds of activities:
Reference activities: - initializing/mutating/messaging/destroying a reference type (or an external resource, which I’d argue is effectively the same thing).
Value activities: - evaluating/transforming/returning a value
A notion I’ve been struggling to nail down in words over the past several years is how—still struggling here—all pain seems to stem from one original sin: real-world programs require both kinds of activities, reference and value, but those two activities are as incompatible as oil and water. To write a useful program, you need to undertake reference activities and value activities, but the two don’t want to be mixed. The act of writing the program is itself the cause of the problem!
Programming paradigms — OO, Functional, Procedural, Imperative — and application design patterns — MVC, MVVM, VIPER, YADA•YADA – all seem to be answers to the problem of how to resolve the impedance mismatch between reference and value activities, but a side effect is that in the act of proposing a solution they implicitly suggest to the developer the paradigm has done the hard work of understanding the diagnosis for you, so you don’t have to. When inevitably a given paradigm runs aground on a blind spot, too often the ensuing debate becomes about the merits of particular paradigms and not nearly enough about achieving a universal understanding of the nature of the problem that all paradigms aim to solve.
I believe that it is vastly more important for a developer to internalize the “simple” lesson of how reference types and value types differ. It’s Programming 101 material, but so much of what we do is merely a footnote to that difference. The more one internalizes that insight, the easier it becomes to reason about this or that paradigm, the easier it becomes to jump to a different ship as project needs change, lacking loyalty to any solution but fiercely deepening one’s understanding of the diagnosis.