This was an interesting read for me, but I'm struggling to understand, from a design/organizational perspective, why solving the expression problem is a good thing.

If I don't try to solve the expression problem, I'm left with two common [OOP] implementation approaches:

1. A file for each type, within which all operations are also defined for that type.

2. A file for each type (POD), and a file for each operation which contains implementations for all types.

With either implementation, I achieve a good deal of consistency. The questions of "where should I put this new code", "what is the responsibility of this file", or "where could I find the implementation of operator <x> on type <y> within the code repository" are easily answered.

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/types/Constant.code` or `src/operations/ToString.code` within my code repository. And as a result, it's no longer obvious what the full responsibilities of any file are within a structured repository without skimming the source.

I'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't your new code belong in the library (where you can implement it using approach 1 or 2), rather than in application code?