3 ms·

The best summary is why bother when coding explicitly and without "magic" is far more suitable to long term maintainable code

by weego 8y ago

bad_user 8y ago
Implicit parameters in Scala are solved at compile time and lexically scoped so do not qualify for "magic". > why bother Because software development is hard, we're solving hard problems and it's good to have better and better tools to do that. In particular Scala's implicit parameters, along with its support for higher kinded types and functional programming in general allow for modeling your problem domain via tools imported from Haskell and other FP languages, because implicit parameters are in fact a generalization of type classes. And type classes are many times a superior alternative to OOP for building polymorphic code. Plus the landscape is very competitive and the market is global. I remember in 2000 when the bubble burst the jobs of thousands of developers disappeared over night. To stay competitive, a "why bother" attitude is not going to cut it when the current bubble bursts, just saying.
- couchand 8y ago
  > solved at compile time and lexically scoped so do not qualify for "magic". That seems like too limiting a definition of "magic" to me. > implicit parameters are in fact a generalization of type classes. Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic. Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell. It's true that the underlying mechanism is (roughly) the same, but the surface-level behavior is what really matters, and there they are very different.
  - bad_user 8y ago
    > "That seems like too limiting a definition of "magic" to me" What is your definition of "magic" then? Things that are unfamiliar? Please don't mention "explicit vs implicit", because Scala's implicits are in fact explicit, plus we can always talk of assembly language and how it lacks any magic. > "Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic." Ergonomics has nothing to do with whether a concept is a generalization of another. > "Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell." Nope, both type clases and implicit parameters allow for describing functions that turn type names into values. That's all there is to it. Or in other words, both type classes and Scala's implicits are about return type polymorphism. The only actual differences are that: 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project 2. Scala's implicits are more flexible in what they allow, for example it has priority rules in case of conflicts, which allow say those implicits to work in the presence of OOP subtyping, or to work with multiple type params for describing things that are difficult to describe via type classes (but not necessarily desirable, e.g. the CanBuildFrom pattern) 3. working with Haskell's type classes is nicer, because for hierarchies in Scala you end up dealing with OOP issues (i.e. in modelling Haskell's type class hierarchies, we ended up debating on inheritance vs composition), plus we do a lot of manual plumbing in libraries like Typelevel Cats But trust me when I say this, fundamentally they are the same ;-) You can also read Martin Odersky's paper about it: http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf
    - tome 8y ago
      > 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project Can you give an example?
    - couchand 8y ago
      I don't think you understand my point: the implementation doesn't matter, what matters is the user's mental model. The mental model of typeclasses is focused of a specific, clearly defined use.
rtpg 8y ago
I... mostly agree but I think that the type-class use case allows for stronger DSLs that let you seperate code from effects in a pretty clean way. A lot of functionally pure stuff works off of this and building a DSL like this without type classes or implicits might be a bit messy https://www.chrisstucchio.com/blog/2015/free_monads_in_scalaz.html https://www.chrisstucchio.com/blog/2015/free_monads_in_scala...
cphoover 8y ago
Could not agree more. I hate when developers try to be "clever" at the cost of legibility and simplicity. Scala is full of this "cleverness" built into the language itself.
jjtheblunt 8y ago
well, having just aborted a new job run by a person who pushed implicits, I came to realize the use of implicits essentially kept him one step ahead of others in understanding what explicitly his code was meant to do. Like a primal nerd turf war, for no group benefit.

The best summary is why bother when coding explicitly and without "magic" is far more suitable to long term maintainable code

by weego 8y ago

The best summary is why bother when coding explicitly and without "magic" is far more suitable to long term maintainable code

bad_user 8y ago

Implicit parameters in Scala are solved at compile time and lexically scoped so do not qualify for "magic". > why bother Because software development is hard, we're solving hard problems and it's good to have better and better tools to do that. In particular Scala's implicit parameters, along with its support for higher kinded types and functional programming in general allow for modeling your problem domain via tools imported from Haskell and other FP languages, because implicit parameters are in fact a generalization of type classes. And type classes are many times a superior alternative to OOP for building polymorphic code. Plus the landscape is very competitive and the market is global. I remember in 2000 when the bubble burst the jobs of thousands of developers disappeared over night. To stay competitive, a "why bother" attitude is not going to cut it when the current bubble bursts, just saying.

couchand 8y ago
> solved at compile time and lexically scoped so do not qualify for "magic". That seems like too limiting a definition of "magic" to me. > implicit parameters are in fact a generalization of type classes. Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic. Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell. It's true that the underlying mechanism is (roughly) the same, but the surface-level behavior is what really matters, and there they are very different.
- bad_user 8y ago
  > "That seems like too limiting a definition of "magic" to me" What is your definition of "magic" then? Things that are unfamiliar? Please don't mention "explicit vs implicit", because Scala's implicits are in fact explicit, plus we can always talk of assembly language and how it lacks any magic. > "Well, not exactly, as far as I can tell. Type classes (in Haskell at least) are significantly more ergonomic." Ergonomics has nothing to do with whether a concept is a generalization of another. > "Since they semantically describe the user's types, they allow you to perform their operations directly with the user's values. Implicit parameters have to be pulled out of the implicit environment and used explicitly themselves, as far as I can tell." Nope, both type clases and implicit parameters allow for describing functions that turn type names into values. That's all there is to it. Or in other words, both type classes and Scala's implicits are about return type polymorphism. The only actual differences are that: 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project 2. Scala's implicits are more flexible in what they allow, for example it has priority rules in case of conflicts, which allow say those implicits to work in the presence of OOP subtyping, or to work with multiple type params for describing things that are difficult to describe via type classes (but not necessarily desirable, e.g. the CanBuildFrom pattern) 3. working with Haskell's type classes is nicer, because for hierarchies in Scala you end up dealing with OOP issues (i.e. in modelling Haskell's type class hierarchies, we ended up debating on inheritance vs composition), plus we do a lot of manual plumbing in libraries like Typelevel Cats But trust me when I say this, fundamentally they are the same ;-) You can also read Martin Odersky's paper about it: http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf http://ropas.snu.ac.kr/%7Ebruno/papers/TypeClasses.pdf
  - tome 8y ago
    > 1. type classes in Haskell are supposedly coherent, i.e. the compiler is supposed to force a single type class instance in the whole project, however GHC does in fact not do that so you can end up with multiple instances of the same type in the same project Can you give an example?
  - couchand 8y ago
    I don't think you understand my point: the implementation doesn't matter, what matters is the user's mental model. The mental model of typeclasses is focused of a specific, clearly defined use.

rtpg 8y ago

I... mostly agree but I think that the type-class use case allows for stronger DSLs that let you seperate code from effects in a pretty clean way. A lot of functionally pure stuff works off of this and building a DSL like this without type classes or implicits might be a bit messy https://www.chrisstucchio.com/blog/2015/free_monads_in_scalaz.html https://www.chrisstucchio.com/blog/2015/free_monads_in_scala...

cphoover 8y ago

Could not agree more. I hate when developers try to be "clever" at the cost of legibility and simplicity. Scala is full of this "cleverness" built into the language itself.

jjtheblunt 8y ago

well, having just aborted a new job run by a person who pushed implicits, I came to realize the use of implicits essentially kept him one step ahead of others in understanding what explicitly his code was meant to do. Like a primal nerd turf war, for no group benefit.