examples of considering pareto optimality in software development
Ease of use and type-safety of Haskell programs
quote from the original quote that got me thinking about pareto optimality and software development
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.
takeaways and thoughts from re-reading this
What can we improve in X positively that doesn’t affect Y negatively?
Eventually you’ll hit the wall of tradeoffs, but most assume they are in tradeoff territory way too soon
- To counteract my cognitive biases by playing devils advocate though, we humans only have finite time and that forces us to prioritize
TODO Choosing ide’s that “good out of the box” versus more extensible editors
examples being
vscode
emacs
Thinking from the lens counteract my cognitive biases by playing devils advocate though
Me stating this might be not considering Pareto Optimality in that, there’s a lot that could be done to make emacs better out of the box without sacrificing it’s extensibility. My gut response though is that the hesitance in changing defaults is something that has kept it’s userbase over the years, and potential adoption of people not pre-selected to put forth the same effort doesn’t seem like a good gamble to take.