5 ms·

Strategic Scala Style: Principle of Least Power (2016)

51 points by brok3nmachine 5y ago

dhconnelly 5y ago
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.
- Cthulhu_ 5y ago
  They all CAN be complex, but I feel like Scala was designed to BE complex, to give a developer as many tools as possible to write complex code. Contrast this with Go which was designed to be simple, to give developers few options and few points of contentions. And it's not just the language, but the mindset of the developing community. I mean in a future release of Scala, they will add generics - that, combined with higher-order functions, will allow for functional programming constructs like Option and operations like map, filter, etc - those are already possible, but the function they operate on has to be declared for every type. But while that has really taken off in some languages and environments, it's heavily discouraged in Go - the runtime is not designed for it, it can't cleverly unroll and optimize it, and the function call overhead will make its performance terrible compared to a regular loop. TL;DR while it is or will be possible, it conflicts with the principle of least power described here, and a number of e.g. Go proverbs and other wisdoms.
  - nikitaga 5y ago
    > I mean in a future release of Scala, they will add generics This is a typo, the great old one meant to say Go, not Scala.
  - dhconnelly 5y ago
    Yeah, no argument there. And I definitely like the Go community’s tendency towards straightforward code. But even there (among less Go philosophy-minded engineers, possibly) I’ve seen crazy abstractions built using interface{} that didn’t need that kind of generic code for the use case. Another one in Go is the nil/interface type interaction, for example. And this kind of thing can be hard to reason about, and that’s what I’m trying to say. All the languages have these complex and tricky bits and it’s best to stay away from them unless truly necessary.
MrBuddyCasino 5y ago
A developer that is concerned (and rightfully so) with the Principle Of Least Power choosing Scala as his weapon of choice, in 2014, meaning before they partially saw the errors of their ways in Scala 3: a theoretical possibility, sure, but not one I have ever seen in the wild.
- nikitaga 5y ago
  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.
dang 5y ago
Past related threads: Strategic Scala Style: Principle of Least Power - https://news.ycombinator.com/item?id=11467339 https://news.ycombinator.com/item?id=11467339 - April 2016 (64 comments) Strategic Scala Style: Principle of Least Power - https://news.ycombinator.com/item?id=11265424 https://news.ycombinator.com/item?id=11265424 - March 2016 (4 comments)
lincpa 5y ago
10 Principles of the system design https://github.com/linpengcheng/PurefunctionPipelineDataflow#Principles-of-the-model https://github.com/linpengcheng/PurefunctionPipelineDataflow...
paulddraper 5y ago
I worked in Scala for years, and it is no small irony that this article is based in that language.
- valenterry 5y ago
  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...
  - Cthulhu_ 5y ago
    Repetitive yes, bloated, not sure what you mean by it. But it's readable and maintainable, and will be that for the next decade, both by the original authors and the potentially hundreds or thousands that will follow. With Scala, and I've worked with the language and some Scala oriented developers, I get the feeling that each individual developer styles themselves an artisan, and their code is not for the likes of mortals to comprehend. I mean I kinda get it, it makes them feel smart and empowered and above the common Java developers and will probably earn them more money. Hell, I've been at one and heard of at least one other place where they decided for Scala not so much because it was the best language for the job, but because if they went with Java they would have to weed out 95% of applicants because they're mediocre - if you nab a Scala developer you know you've got someone from the top 10% at least. I mean the one project failed and they went back to C# / .NET after a few years because they couldn't find developers and the other one probably muddles on because of sunk cost, but still.
    - nikitaga 5y ago
      Indeed, Scala code quality varies a lot based on developer / team / org. Code can be several different flavors of crap, but it can also be magnificently good in the hands of strong developers, and the quality is definitely scalable to team / org, with the right attitude and hiring practices. Thankfully the Scala teams I worked on have been great, and to be fair the issues we did encounter were mostly from developers having little Scala experience being lost without mentorship. I'm yet to encounter the stereotypical overengineers or FP nazis, I think the fashion for those attitudes might be more in the past these days.
bryanrasmussen 5y ago
The W3C had a Tag Finding on the Rule of Least Power back in 2001 https://www.w3.org/2001/tag/doc/leastPower.html https://www.w3.org/2001/tag/doc/leastPower.html
0x008 5y ago
For me at least it sounds like another reiteration of KISS
- Cthulhu_ 5y ago
  Yup, but it's a bit more actionable and concrete I think. I mean which is simpler? A single line (low LOC!) of some clever functional code, or 5-15 lines of iterative but dead simple code? But you can definitely state that the oneliner is powerful while the loop is low tech.
  - 0x008 5y ago
    The least possible complexity.
AheadOfTime295 5y ago
If this Principle of Least Power had been applied to sbt, what would have been the result? Compilation times depend on scalac and not so much sbt. Perhaps Scala adoption would be higher today. Assuming no competitors (Kotlin) had gained momentum.
- nikitaga 5y ago
  Probably something like https://github.com/com-lihaoyi/mill https://github.com/com-lihaoyi/mill (2017) https://www.lihaoyi.com/post/SowhatswrongwithSBT.html https://www.lihaoyi.com/post/SowhatswrongwithSBT.html (2018) https://www.lihaoyi.com/post/MillBetterScalaBuilds.html https://www.lihaoyi.com/post/MillBetterScalaBuilds.html

51 points by brok3nmachine 5y ago

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.

Cthulhu_ 5y ago
They all CAN be complex, but I feel like Scala was designed to BE complex, to give a developer as many tools as possible to write complex code. Contrast this with Go which was designed to be simple, to give developers few options and few points of contentions. And it's not just the language, but the mindset of the developing community. I mean in a future release of Scala, they will add generics - that, combined with higher-order functions, will allow for functional programming constructs like Option and operations like map, filter, etc - those are already possible, but the function they operate on has to be declared for every type. But while that has really taken off in some languages and environments, it's heavily discouraged in Go - the runtime is not designed for it, it can't cleverly unroll and optimize it, and the function call overhead will make its performance terrible compared to a regular loop. TL;DR while it is or will be possible, it conflicts with the principle of least power described here, and a number of e.g. Go proverbs and other wisdoms.
- nikitaga 5y ago
  > I mean in a future release of Scala, they will add generics This is a typo, the great old one meant to say Go, not Scala.
- dhconnelly 5y ago
  Yeah, no argument there. And I definitely like the Go community’s tendency towards straightforward code. But even there (among less Go philosophy-minded engineers, possibly) I’ve seen crazy abstractions built using interface{} that didn’t need that kind of generic code for the use case. Another one in Go is the nil/interface type interaction, for example. And this kind of thing can be hard to reason about, and that’s what I’m trying to say. All the languages have these complex and tricky bits and it’s best to stay away from them unless truly necessary.

MrBuddyCasino 5y ago

A developer that is concerned (and rightfully so) with the Principle Of Least Power choosing Scala as his weapon of choice, in 2014, meaning before they partially saw the errors of their ways in Scala 3: a theoretical possibility, sure, but not one I have ever seen in the wild.

nikitaga 5y ago
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.

dang 5y ago

Past related threads: Strategic Scala Style: Principle of Least Power - https://news.ycombinator.com/item?id=11467339 https://news.ycombinator.com/item?id=11467339 - April 2016 (64 comments) Strategic Scala Style: Principle of Least Power - https://news.ycombinator.com/item?id=11265424 https://news.ycombinator.com/item?id=11265424 - March 2016 (4 comments)

lincpa 5y ago

10 Principles of the system design https://github.com/linpengcheng/PurefunctionPipelineDataflow#Principles-of-the-model https://github.com/linpengcheng/PurefunctionPipelineDataflow...

paulddraper 5y ago

I worked in Scala for years, and it is no small irony that this article is based in that language.

valenterry 5y ago
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...
- Cthulhu_ 5y ago
  Repetitive yes, bloated, not sure what you mean by it. But it's readable and maintainable, and will be that for the next decade, both by the original authors and the potentially hundreds or thousands that will follow. With Scala, and I've worked with the language and some Scala oriented developers, I get the feeling that each individual developer styles themselves an artisan, and their code is not for the likes of mortals to comprehend. I mean I kinda get it, it makes them feel smart and empowered and above the common Java developers and will probably earn them more money. Hell, I've been at one and heard of at least one other place where they decided for Scala not so much because it was the best language for the job, but because if they went with Java they would have to weed out 95% of applicants because they're mediocre - if you nab a Scala developer you know you've got someone from the top 10% at least. I mean the one project failed and they went back to C# / .NET after a few years because they couldn't find developers and the other one probably muddles on because of sunk cost, but still.
  - nikitaga 5y ago
    Indeed, Scala code quality varies a lot based on developer / team / org. Code can be several different flavors of crap, but it can also be magnificently good in the hands of strong developers, and the quality is definitely scalable to team / org, with the right attitude and hiring practices. Thankfully the Scala teams I worked on have been great, and to be fair the issues we did encounter were mostly from developers having little Scala experience being lost without mentorship. I'm yet to encounter the stereotypical overengineers or FP nazis, I think the fashion for those attitudes might be more in the past these days.

bryanrasmussen 5y ago

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

0x008 5y ago

For me at least it sounds like another reiteration of KISS

Cthulhu_ 5y ago
Yup, but it's a bit more actionable and concrete I think. I mean which is simpler? A single line (low LOC!) of some clever functional code, or 5-15 lines of iterative but dead simple code? But you can definitely state that the oneliner is powerful while the loop is low tech.
- 0x008 5y ago
  The least possible complexity.

AheadOfTime295 5y ago

If this Principle of Least Power had been applied to sbt, what would have been the result? Compilation times depend on scalac and not so much sbt. Perhaps Scala adoption would be higher today. Assuming no competitors (Kotlin) had gained momentum.

nikitaga 5y ago
Probably something like https://github.com/com-lihaoyi/mill https://github.com/com-lihaoyi/mill (2017) https://www.lihaoyi.com/post/SowhatswrongwithSBT.html https://www.lihaoyi.com/post/SowhatswrongwithSBT.html (2018) https://www.lihaoyi.com/post/MillBetterScalaBuilds.html https://www.lihaoyi.com/post/MillBetterScalaBuilds.html