Strategic Scala Style: Principle of Least Power

Oh I'm sure that's true, but as a recovering Python programmer I'm uncomfortable with justifications of mutability under any except the most extreme circumstances. ("In our codebase we avoid writing side effecting code", my colleagues said, whilst filling the codebase with side effecting code.)

I agree.

The fact that Scala is proper multi-paradigm, and has a first-class functional sublanguage as well as a first-class imperative sublanguage is part of its great appeal.

I have mentored quite a few people over the last couple of years in Scala. In my experience, going from imperative Java, C, Python straight to Scalaz/Typelevel/higher-kinded monad style pure functional programming never works, and drives Scala-beginners away.

What works extremely well is to start with Scala as a nice Java without semicolons, and then, as they become more proficient in the OO/imperative Scala fragment, gradually to introduce more advanced features, starting with case classes.

The reputation Scala has for being too difficult comes from certain parts of the Scala elite trying to convince everybody, including beginners, that higher-kinded purely functional Scala is the only way to use the language. Nothing wrong with this style of programming per se and it's great that people are pushing the envelope, but the conceptual gap is too big for a language learner hailing from the imperative world (which is most of them).

Ah, but that's a different claim. The claim in the article is "You can use mutability to model things that change with time.". Your claim here is "You can use mutability if it makes programming easier.".

This [1] part of an interview with Rich Hickey is great on this topic.

[1]: https://youtu.be/wASCH_gPnDw?t=37m13s

   it's precisely when values change 
   over time that you want immutability 
   most.

Values always change over time, otherwise you could replace variables by constants.

I suggest that immutability is most useful for data that crosses into a context that you (the programmer) have no/little control over. There is nothing wrong with a bit of state, like so

  def pow ( n : Int ) : Int = {
    var result = 1
    var i = n
    while ( i > 0 ) {
      result *= 2
      i -= 1 }
    return result }

The reason this is OK is that the state changes are local, while globally (from the outside) pow remains functional. There is no need to coordinate with other programmers, or other functions or modules, to get i and n to behave properly.

In contrast, if you pass shared state into a context that you have limited knowledge or control over (e.g. shared memory concurrency) then things become hairy.

That's why I advocate: "locally stateful, globally stateless" programming.

Find something you want to do, try to do it, find out what you don't know, and learn it.

You could try learning from a book or a course, but personally I've never found a better way of learning "what I need to learn for X" than trying to do X and then googling all the things I don't know.

Sure, you'll forget a whole bunch of that stuff, but if it's at all important you'll find yourself re-learning it again and again until it sticks.

Scala by example and the coursera courses by Martin Odersky have helped me, but like Li said, there is no substitute to having something in mind and getting your hands dirty using Akka, Play or Spark and Googling what you don't know.

http://www.scala-lang.org/docu/files/ScalaByExample.pdf

> Explicitly declare the return type of all public methods.

+1

This is very helpful for quickly scanning code.

>Again, IMHO, while Option is an exceptionally useful type, when indicating errors at the "public API level" it proves to be insufficient.

Agreed. Either, or even better, \/ (Scalaz either/disjunction) is much easier to work with and more expressive.

I don't type-ascribe all public methods. Maybe I should but I'm lazy. I don't even type-ascribe my implicit vals or defs... i probably should but i don't

As to Either, I didn't mention it because I don't use it much, and don't see many other people using it either. Sure you can use it and it'll work, but it's not the style I use or the style I see most open source libraries using.

As for Scalaz, yeah \/ is great, or cats' Xor. But this doc is all about Vanilla Scala: for every library out there, they will have their own best practices, that are totally uninteresting to people not using hat library. If someone wants to write similar documents for Scalaz, Cats, Akka, Play, Finagle, Play, they would each probably be just as long as this one, and probably just as valuable!

I rarely use Either. If logic is internal to my program, often the cause of the deviation from the happy path is implicit, and I can just use Option. But if I do want to propagate the cause, usually I prefer to model directly within my types as a sealed trait, because then I can easily model multiple causes. Of course, this comes up short if I want to reuse the same cause for multiple distinct outcomes. Either could be nice for this, but it comes up short for multiple causes, because you have to resort to nested Either. Consequently, I very rarely use Either.

What I'd really like is a simple type union syntax, so I could union the happy path result with any number of failure modes, where there isn't necessarily a common supertype for anything.

I really dislike Either personally. I much prefer Scalatic's "Either with attitude" Or. It's also the only natural use of infix type notation I'm familiar with so that's kind of neat.

I frequently see Either abused to represent the lack of Union Types. But then I also see it used for errors. And it's not really a perfect fit for either (no pun intended).

http://www.scalactic.org

Every (a non-Empty List) is also nice. I like Scalactic. It adds just a couple of small useful things. Very lightweight.

Option (Some or None), Or (Good or Bad) and Try (Success or Failure[T <: Throwable]) cover the bases for me.

Just in case others were unaware of scalactic. (sister library to scalatest, so if you're already using scalatest, you're already using scalactic under the covers I believe)

Using `Either` instead of `Option` would violate "Use the least complex approach that solves your problem".

If all you need is represent an optional value, why use `Either`, which needs a second type parameter representing the failure? If you don't care about what caused the failure (because there was no failure, an absence of value is a valid result), no need to represent it.

Besides, these two classes still represent fundamentally different concepts and they are not interchangeable at all.

i say "hardcode dependencies" for three reasons:

- If you want to extract them out, it's safe and straightforward. Still a tedious refactor, but a safe tedious refactor. It's not any harder than injecting stuff up-front. Given that, why do the work now if it's not any harder to do later, and you may not need to do it?

- If you hardcode dependencies except for those you can't hardcode, that means that if you come across something which isn't hard coded, you know immediately there must be some reason it needs to be injected in! This makes reading code easier, since following this convention the code itself tells you how it's used, vs having to guess whether an injected dependency is actually necessary or whether it has just one instantiation and can be hardcoded

- You are already hardcoding all sorta of things anyway. The `Seq` object? The `String` type? These, and other things, can be injected in as params or type-params if we really want to. The question is then when do you stop and draw the line? You obviously can't inject everything. "Only inject stuff that needs to be injected" provides a clear, unambiguous guideline that applies equally to dependencies on your code, on the std lib, or on third party libraries

On a semi-related note, here[0] is a talk given by a gentleman named Runar Bjarnason discussing a Dependency Injection technique in Scala.

Related in that you mentioned dependency injection, unrelated in that it is not directly relevant to the content of Strategic Scala Style. (maybe of interest to some though).

0 - https://yow.eventer.com/yow-2012-1012/lambda-the-ultimate-de...

This is a very good point. I work on a team with 7 Scala developers of varied experience. When someone commits code it is reviewed. If the reviewer doesn't understand the code we will talk it over as a group and either learn the new technique or decide that the complexity is not worth the benefit and maybe even rewrite the commit. We encourage people to talk about new techniques before implementing so that rewrites are rare.

I agree with this 100%. Having too many ways of doing things, and no way to pick between them, results in everyone doing things every which way, all different.

That's why this document exists at all. We can definitely make things better, but to do so requires putting together guidelines, proposals, and consensus (things developers are historically pretty poor at), rather than just cranking out code and complaining (both of which developers excel at, especially fueled by coffee)

> To write code with the same guarantees as the core of my system would be theoretically possible in a "simpler" language, but it would be incredibly verbose: it would take longer to write and be much harder to maintain (because you'd have to keep a lot more in your head to understand each piece of functionality).

I could use the same reasoning to justify writing my code in Common Lisp instead. The thing about Turing-complete languages is that the only real dimmension of power is their expressiveness - i.e. how much boilerplate do you have to write to implement something (and therefore how much of that cruft other people have to deal with when trying to understand your code).

I therefore find this principle as applied to programming languages to be illogical.

It makes sense in non-Turing-complete languages though (configurations, DSLs) - because there by "least power" one means power in the computational sense. Accidentally making a language too powerful when it's not needed can lead to security issues.

I guess the point of the person you're responding to is that following the article's advice, Kotlin would probably be a better choice than Scala in most cases.

For example, Kotlin doesn't support higher kinded types so if your problem doesn't require highed kinded types, Kotlin would be a better fit than Scala since it's the "Least powerful language that will solve your problem".

Which will probably lead to the controversial claim that "All programs need higher kinds" followed by the realization that the perceived power of a technology is extremely subjective.