1. 4

  2. 2

    I think anything coming from abstract math is transferable. The problem is in many languages, simple concepts from abstract math tend to manifest themselves in too cumbersome forms to be useful (or even reasonably performant) alone. So, libraries, frameworks or patterns that resemble these concepts tend to actually be a composition of many such concepts, and then the end result is not transferable, since that custom tailored composition would probably cease to make sense in another arbitrary context.

    As a side note, please don’t ever use error in pure code, unless that case is really, provably an impossible condition. Like if you’ve carefully encapsulated something, and the type system doesn’t suffice to show that some combination of inputs is impossible to observe. As a side note to this side note, this happens to be a nice example of what I meant in the above paragraph. The author tries to introduce some notion of error into his event sourcing, and instead of doing it properly as an explicit composition of two layers, one that folds the events, and another that handles errors, he abuses the last resort error mechanism, thereby mashing together these two concepts.

    1. 1

      It would be nice if there was a functional programming tag for functional programming patterns.