3 ms·

Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this vi

by fnl 9y ago

Indeed, if people would only use implicits the way Odersky recommends, I'd love Scala. The problem is, too many people do exactly what he warns about in this video. And so my love-hate relationship continues... :-)

virtualwhys 9y ago
If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. Otherwise, refresh my memory, what was he warning about with implicits? There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.
- fnl 9y ago
  That sounds like a great idea. So no more importing of implicits in Scala 3 to use them on methods of another package (or namespace)? That would make them quite a lot more "wieldable". What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
- tekacs 9y ago
  > If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2]. Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules). Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on. I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution. [1]: https://github.com/lampepfl/dotty/pull/2060 https://github.com/lampepfl/dotty/pull/2060 [2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation. [3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.
Randgalt 9y ago
So true. Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.

by fnl 9y ago

virtualwhys 9y ago

If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. Otherwise, refresh my memory, what was he warning about with implicits? There's currently no way around definition site boilerplate (e.g. `implicit name: Type`); `implicit` keyword and providing a variable name are required. Implicit function types eliminate definition site boilerplate while providing function composition -- looks like a solid enhancement for FP in Scala.

fnl 9y ago
That sounds like a great idea. So no more importing of implicits in Scala 3 to use them on methods of another package (or namespace)? That would make them quite a lot more "wieldable". What Odersky warns about is defining implicits on built-in types. Which IMO too often gets abused to hide poor design.
tekacs 9y ago
> If you're referring to implicit conversions, IIRC, those will have to be defined in the same source file in which they are used in Scala 3. That PR [1] is (IMO thankfully) not merged yet (marked as on hold) and reminds me of the indentation-based syntax proposal - ambitious, far from consensus on it being 'a good thing' by actual users, full of workarounds or escape hatches being sought by everyone, almost unilateral and very little to suggest it's even solving the problem it claims to (and it's fuzzy on what that is, exactly)[2]. Matching Rust's rules on this seems like the source motivator for Odersky and that only leads me to recall a conversation I had with a friend on these two languages and about a dozen or so practical, dramatically boilerplate- or complexity-reducing solutions that library authors or I had coded up; these would be either outlawed or made into large, complex workarounds under this scheme (Rust rules). Even in a codebase directly under my purview, we would have to duplicate implicits across modules (and keep them in sync), merge deliberately-separated modules and give up on some functionality altogether to support this proposal. These are mostly 'free' additional type safety constraints that we would just have to give up on. I'm not against making changes to make implicits easier to 'see'[3] - I'd only say that an approach with the above problems that gets worked around anyway is not the solution. [1]: https://github.com/lampepfl/dotty/pull/2060 https://github.com/lampepfl/dotty/pull/2060 [2]: Indeed even in this HN thread there are people criticising implicit parameters in a bunch of places (definitely not going away, IIRC Odersky likes them) - when people say 'they don't like implicits', between the various user demands they might well be removed in every variation. [3]: Indeed in IntelliJ IDEA and Ensime, every implicit conversion is underlined at the point of use. In that thread, someone suggests making implicits importable only with a modifier.

Randgalt 9y ago

So true. Implicit parameter explosion is one the worst aspects of maintaining Scala code. In larger projects trying to comprehend how to import and understand which implicit parameters are used/needed can be maddening.