Jon Pretty

In Scala it's bad practice to use implicit parameters for summoning traits that aren't type classes. Not all traits required via implicit parameters are type classes, usage via "implicit" isn't what defines a type class, the trait's signature is. Stop using "implicit" for DI.

A lot of the "tagless final" in Scala is basically "passing all OOP dependencies at the call site as implicit parameters", the so called "algebra", in this context a fancy term describing OOP classes w/ state. The things people do to avoid giving plain arguments to functions

Using implicits for DI is bad b/c reading code requires more context. It's why the Linux kernel has never adopted C++, b/c kernel devs want to reason about pieces of code in isolation, C making everything explicit. Reading code is more important than writing it, always.

But shouldn't that be what context is? It's the things that the reader can take for granted, and every additional explicit parameter that ought to be taken for granted instead has to be present, diluting the parameters that are actually significant to the method.

Seeing that a method interacts w/ the database, or can potentially fire missiles, is as important at the call-site, as its definition. And if we want context, if we want DI, Scala also has a true and tried way of doing it, which is OOP classes, closures on steroids.

Scala is an expressive language, but the aggregate of its features can yield some of the worst code in existence. Whenever I compare Scala APIs to their Java equivalents, I almost always find the Java version easier to read. And no feature was abused more than implicits.