5 ms·

To add to lihaoyi's sibling comment, some good examples of things people realized were overly complex pits of pain in Scala but were all the rage in the Lift da

To add to lihaoyi's sibling comment, some good examples of things people realized were overly complex pits of pain in Scala but were all the rage in the Lift days are the cake pattern and gratuitous use of implicit conversions. Those thankfully have largely disappeared. The design space of programs in Scala is still large (detractors might say too large), but it's way better explored now and there's a much clearer idea of the various tradeoffs among the various approaches as well as how to harmonize one with another.

cutler 6y ago
I think Scala will always suffer from its choice to make implicits so fundamental. Whether abused or not they impede compiler efficiency and complicate code. Implicits were the main reason I dropped Scala a few years ago.
- sideeffffect 6y ago
  > I think Scala will always suffer from its choice to make implicits so fundamental. Thankfully it won't. Scala 3 deconstructs implicits and discourages (or outright discards) the bad parts: http://dotty.epfl.ch/docs/reference/contextual/motivation.html http://dotty.epfl.ch/docs/reference/contextual/motivation.ht... "Implicits" are useful for the Type class pattern and is available in Scala 3 with an improved syntax. "Implicits" for implicit conversions is an ugly hack that should be avoided as much as possible and Scala 3 restricts it. "Implicits" for extension methods is a clever hack, and Scala 3 provides a dedicated syntax for defining extension methods.
- dwohnitmok 6y ago
  Implicit conversions I think are landmines that should to the greatest extent possible be avoided except in a few very select cases. Implicit arguments... man I go back and forth on that so much. On the one hand every crazy tower of abstraction that grinds the compiler to a halt in Scala inevitably begins with implicit arguments and you can have a really rough time with them if your IDE doesn't support looking up implicit arguments. On the other hand, if you want ad-hoc polymorphism, implicit arguments are really useful, often far more so than inheritance. My usual take on this is that you probably don't need ad-hoc polymorphism most of the time, which is my way of wriggling out of the dilemma.
  - cutler 6y ago
    Clojure has ad-hoc polymorphism and it isn't even statically typed so I don't get how implicits are so essential. Implicits are still alive and well in Scala 3 I hear so I guess they blew any chance of going mainstream (again).
    - dwohnitmok 6y ago
      We're talking about different notions of ad-hoc polymorphism (as you point out, static vs dynamic). For statically typed languages, implicit arguments (in some form or another) are really great at getting statically checked ad-hoc polymorphism. But even in dynamically typed languages such as Clojure, ad-hoc polymorphism mechanisms bottom out at some form of implicitness at runtime. I assume you're referring to multimethods here (which generalize protocols, whose very existence is a performance hack akin to atoms vs volatile, so I'll focus just on multimethods)? The entire lookup system based off of defmulti is really just the same thing as Scala's implicit system just at runtime rather than compile time, but even harder to understand IMO because it can change wildly at runtime. The same "spooky action at a distance" problems can result here. The reason this isn't an issue in Clojure is that multimethods are very rarely used and instead a lot of code just specializes on vectors or maps (again going back to my point that you usually don't need ad-hoc polymorphism).
- valenterry 6y ago
  I think it's the opposite. All languages have their own "implicits" - just not as a proper language concept, but for "special cases". The problem is, that while it gives developers are more stable/clear framework to work with, it also limits the development of the language itself. If you look at Scala, implicits could be used to model typeclasses from haskell and method-syntax-extension. Other languages such as Kotlin have a dedicated language feature for that. Scala never needed that. However, this power also ask for responsible usage of course. That is a drawback that can't be denied.
  - dwohnitmok 6y ago
    > implicits could be used to model typeclasses from haskell and method-syntax-extension To be fair those are powered by two different mechanisms (implicit arguments and implicit conversions) that just so happened to share the same keyword name but are semantically quite different (and have been broken up in Scala 3). But your overall point is well-taken.
    - valenterry 6y ago
      > To be fair those are powered by two different mechanisms You can call it like that, but in the end it is the same language feature: describing things in a scope as implicit and having the compiler resolve them by certain rules. What happened in Scala 3 is just that they were named different to make clear when things get defined and when they get used - one without the other is useless though, hence to me it is the same concept or language feature.
killtimeatwork 6y ago
Re: implicits - just try doing anything in cats. The whole thing is hugely based on implicits, which you need to import with magical import invocations (which of course the compiler has no way of suggesting to you).
- sideeffffect 6y ago
  > the compiler has no way of suggesting to you Of course it does. And since Scala 3, it does suggest to you the imports you need for implicits. And IntelliJ does recommend imports even for Scala 2. Regarding cats, the codebase has been restructured, so that you won't need the implicit imports (or not as much at least): https://meta.plasm.us/posts/2019/09/30/implicit-scope-and-cats/ https://meta.plasm.us/posts/2019/09/30/implicit-scope-and-ca... The trick there is that the Type class instances were moved to appropriate companion objects which are searched by the compiler by default and thus the used doesn't need to do any manual imports.
- hocuspocus 6y ago
  Here you go: `import cats.implicits._` Done. And once you start understanding the typeclass hierarchy a little bit, finding the specific syntax and instances comes pretty naturally.
- vvillena 6y ago
  Thinking of "implicits" as one single feature can be extremely confusing. OP is talking about "implicit conversions", which transform values from one type to another automatically just by being in scope. Cats imports bring in "implicit classes", which are a way to extend existing types with new methods, in a way that works even with parametric types in a type-safe way. That's the way to get ad-hoc polymorphism (aka typeclasses) in Scala.

cutler 6y ago

I think Scala will always suffer from its choice to make implicits so fundamental. Whether abused or not they impede compiler efficiency and complicate code. Implicits were the main reason I dropped Scala a few years ago.

sideeffffect 6y ago
> I think Scala will always suffer from its choice to make implicits so fundamental. Thankfully it won't. Scala 3 deconstructs implicits and discourages (or outright discards) the bad parts: http://dotty.epfl.ch/docs/reference/contextual/motivation.html http://dotty.epfl.ch/docs/reference/contextual/motivation.ht... "Implicits" are useful for the Type class pattern and is available in Scala 3 with an improved syntax. "Implicits" for implicit conversions is an ugly hack that should be avoided as much as possible and Scala 3 restricts it. "Implicits" for extension methods is a clever hack, and Scala 3 provides a dedicated syntax for defining extension methods.
dwohnitmok 6y ago
Implicit conversions I think are landmines that should to the greatest extent possible be avoided except in a few very select cases. Implicit arguments... man I go back and forth on that so much. On the one hand every crazy tower of abstraction that grinds the compiler to a halt in Scala inevitably begins with implicit arguments and you can have a really rough time with them if your IDE doesn't support looking up implicit arguments. On the other hand, if you want ad-hoc polymorphism, implicit arguments are really useful, often far more so than inheritance. My usual take on this is that you probably don't need ad-hoc polymorphism most of the time, which is my way of wriggling out of the dilemma.
- cutler 6y ago
  Clojure has ad-hoc polymorphism and it isn't even statically typed so I don't get how implicits are so essential. Implicits are still alive and well in Scala 3 I hear so I guess they blew any chance of going mainstream (again).
  - dwohnitmok 6y ago
    We're talking about different notions of ad-hoc polymorphism (as you point out, static vs dynamic). For statically typed languages, implicit arguments (in some form or another) are really great at getting statically checked ad-hoc polymorphism. But even in dynamically typed languages such as Clojure, ad-hoc polymorphism mechanisms bottom out at some form of implicitness at runtime. I assume you're referring to multimethods here (which generalize protocols, whose very existence is a performance hack akin to atoms vs volatile, so I'll focus just on multimethods)? The entire lookup system based off of defmulti is really just the same thing as Scala's implicit system just at runtime rather than compile time, but even harder to understand IMO because it can change wildly at runtime. The same "spooky action at a distance" problems can result here. The reason this isn't an issue in Clojure is that multimethods are very rarely used and instead a lot of code just specializes on vectors or maps (again going back to my point that you usually don't need ad-hoc polymorphism).
valenterry 6y ago
I think it's the opposite. All languages have their own "implicits" - just not as a proper language concept, but for "special cases". The problem is, that while it gives developers are more stable/clear framework to work with, it also limits the development of the language itself. If you look at Scala, implicits could be used to model typeclasses from haskell and method-syntax-extension. Other languages such as Kotlin have a dedicated language feature for that. Scala never needed that. However, this power also ask for responsible usage of course. That is a drawback that can't be denied.
- dwohnitmok 6y ago
  > implicits could be used to model typeclasses from haskell and method-syntax-extension To be fair those are powered by two different mechanisms (implicit arguments and implicit conversions) that just so happened to share the same keyword name but are semantically quite different (and have been broken up in Scala 3). But your overall point is well-taken.
  - valenterry 6y ago
    > To be fair those are powered by two different mechanisms You can call it like that, but in the end it is the same language feature: describing things in a scope as implicit and having the compiler resolve them by certain rules. What happened in Scala 3 is just that they were named different to make clear when things get defined and when they get used - one without the other is useless though, hence to me it is the same concept or language feature.

killtimeatwork 6y ago

Re: implicits - just try doing anything in cats. The whole thing is hugely based on implicits, which you need to import with magical import invocations (which of course the compiler has no way of suggesting to you).

sideeffffect 6y ago
> the compiler has no way of suggesting to you Of course it does. And since Scala 3, it does suggest to you the imports you need for implicits. And IntelliJ does recommend imports even for Scala 2. Regarding cats, the codebase has been restructured, so that you won't need the implicit imports (or not as much at least): https://meta.plasm.us/posts/2019/09/30/implicit-scope-and-cats/ https://meta.plasm.us/posts/2019/09/30/implicit-scope-and-ca... The trick there is that the Type class instances were moved to appropriate companion objects which are searched by the compiler by default and thus the used doesn't need to do any manual imports.
hocuspocus 6y ago
Here you go: `import cats.implicits._` Done. And once you start understanding the typeclass hierarchy a little bit, finding the specific syntax and instances comes pretty naturally.
vvillena 6y ago
Thinking of "implicits" as one single feature can be extremely confusing. OP is talking about "implicit conversions", which transform values from one type to another automatically just by being in scope. Cats imports bring in "implicit classes", which are a way to extend existing types with new methods, in a way that works even with parametric types in a type-safe way. That's the way to get ad-hoc polymorphism (aka typeclasses) in Scala.