the original quote that got me thinking about pareto optimality and software development
quote
One could make a case that what we’re seeing here is that Haskell web frameworks, and probably a great deal more of the real Haskell code the community has produced in the past few years, is reaching the Pareto optimality frontier between ease-of-use and type safety guarantees.
I imagine a lot of people know what that is given where I am :), but in short, Pareto-optimal means that if you are optimizing between two quantities, you can not increase one without decreasing the other. You can draw a boundary between “all of X, none of Y” and “none of X, all of Y” that has certain characteristics which you can read about elsewhere if you are interested.
I bring this up because one very common cognitive mistake people in general make is to speak of a “tradeoff” between X and Y without taking the time to first establish that they are Pareto optimal, because if you’re not yet Pareto optimal, that mean that you can in fact have more of X without having less of Y yet, and constraining the discussion to “tradeoffs” is introducing a false premise. A real world example is “security vs. convenience”; the vast bulk of real-world situations in which we putatively have this conversation, we could in fact have more of either without affecting the other, because we should be so lucky as to be on the Pareto optimality line.
The less-common second-order mistake is that when a particular X and Y have spent a very long time nowhere near the optimality frontier, people can forget that there is, in fact, a tradeoff to be had, if you do manage to optimize sufficiently. As a third-order consequence, it becomes easy to adopt an X-at-all-costs metric because if you never have to pay in Y, more X is always a good thing.
Arguably, ease-of-use and type safety could be such a case. For a long time the Haskell community has had a lot of places to get “free” gains in both dimensions. But, it should be expected that if you get enough of these gains squared away, that eventually you will hit the point where they will become tradeoffs. And not just “tradeoffs because you aren’t skilled enough to use the ‘hard’ stuff yet”, but truly tradeoffs, for everybody. Users with differing skills and needs may choose different points on the curve for their own needs, but a discussion about tradeoffs is a fundamentally different discussion than one about right vs. wrong.
I’m just musing and providing food for thought. Whether Haskell is there yet anywhere is an interesting question. But if it is, I’d have to say that while in some ways it may be the sad passing of an era, it is also an incredible accomplishment, because I don’t think any other language community has ever even gotten close to the optimality frontier while retaining a high degree of type-based safety.
(I could probably make a case for some languages with low type-based safety and high ease of use, though if you start poking at it “ease of use” is a family of criteria rather than a unique one; for instance, “easy 10 line script” and “easy million-line system” are substantially different languages.)
https://old.reddit.com/r/haskell/comments/3qtmgt/beginner%5Ffriendly%5Fcode%5Fand%5Fapis/cwida8e/