1. 3
  1.  

  2. 1

    My interpretation of DI is that it makes the fundamental mistake of OOP, which is to presume complexity and vertical growth (i.e. growth within functions/method/classes) rather than orthogonality and horizontal growth. If you’re using hard-core OOP, DI is probably a win. That said, function composition is just so much nicer. You don’t need to configure “a framework” to use Haskell’s (.) operator, which is often surprising in its generality (see: lenses).

    Functional programming presumes horizontal growth and asserts that the programmer (whether an application or library or core programmer, and this distinction isn’t really made, at a people level, in the FP community) is smart enough to use the features, libraries, and tools that make sense to solve the problem. Vertical growth is sometimes necessary, but best avoided unless required. Corporate-style OOP, on the other hand, seems to be geared toward haphazard vertical growth as the inexorable behavior. If you’re going to have massive vertical objects, then you need something like DI to keep, at least, some of the parts interchangeable. But it becomes unnecessary if you have the compositional benefits of FP done right.