Strategic Scala Style: Principle of Least Power (2016)

Oh man, I read this article a few months back and it immediately resonated with me. I've never used Scala, but this advice has been applicable in every language, project, and team I've ever worked with, and I very much regret that I didn't already have this resource to cite in past code reviews.

A lot of the worst tendencies that developers complain about in complex programming languages (i.e. all of them, they're all complex) could be addressed by this advice.

This principle as presented is not universal, it's built on a set of assumptions that are true for Scala but not for other environments.

For example, it assumes that refactoring is easy, making it easy to switch your initially simple solution to something more complex if / when the need arises. That is true in Scala thanks to a rich and safe type system, but in other languages it may not be as easy, and it's certainly not easy to replace a python app with a Scala app.

10 Principles of the system design

https://github.com/linpengcheng/PurefunctionPipelineDataflow...

The W3C had a Tag Finding on the Rule of Least Power back in 2001 https://www.w3.org/2001/tag/doc/leastPower.html

That's true. If you use a more restricted language, such as Go, then in does not happen so often that a developer chooses to (or even can) over-engineer something.

Unfortunately, at the same time it also takes away the power in situations where it should be used and where the benefits of abstraction overweigh the drawbacks. This then leads to repetitive and bloated code, runtime errors and all the problems that come from it.

Pick your poison...