This was an interesting read for me, but I&#x27;m struggling to understand, from a design&#x2F;organizational perspective, why solving the expression problem is a <i>good</i> thing.<p>If I don&#x27;t try to solve the expression problem, I&#x27;m left with two common [OOP] implementation approaches:<p>1. A file for each type, within which all operations are also defined for that type.<p>2. A file for each type (POD), and a file for each operation which contains implementations for all types.<p>With either implementation, I achieve a good deal of consistency. The questions of &quot;where should I put this new code&quot;, &quot;what is the responsibility of this file&quot;, or &quot;where could I find the implementation of operator &lt;x&gt; on type &lt;y&gt; within the code repository&quot; are easily answered.<p>Solutions to the expression problem appear to mix these two approaches. The result seems to be much more loosely structured code. If I want to find the definition of ToString for type Constant, where do I look? It could either be in `src&#x2F;types&#x2F;Constant.code` or `src&#x2F;operations&#x2F;ToString.code` within my code repository. And as a result, it&#x27;s no longer obvious what the full responsibilities of any file are within a structured repository without skimming the source.<p>I&#x27;ve heard some brief discussion of extending libraries with both types and operators - for example, adding a new image format to an image processing library and also adding a new operation. But at that point, doesn&#x27;t your new code belong in the library (where you can implement it using approach 1 or 2), rather than in application code?