Pareto Optimal Dev

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

TODO Choosing ide’s that “good out of the box” versus more extensible editors

examples being



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.