4 ms·

Would class fields not be a solution based on mutable state? Isn't that exactly the problem Odersky addresses in the beginning that your state can get mutated w

by fnl 9y ago

Would class fields not be a solution based on mutable state? Isn't that exactly the problem Odersky addresses in the beginning that your state can get mutated while your transaction is ongoing?

fnl 9y ago
Indeed, Guice even recommends not to use (static) final fields. https://github.com/google/guice/wiki/Injections https://github.com/google/guice/wiki/Injections
- hota_mazi 9y ago
  I was talking about regular (instance) fields, not static ones.
  - fnl 9y ago
    Right. "class fields" as opposed to "instance fields" had me confused.
hota_mazi 9y ago
Not necessarily. These fields can be references to immutable objects. Note that Dotty's implicit approach is similar in that respect, it doesn't prescribe anything in terms of mutability/immutability. But we've already gone down the path of implicits, they are the #1 complaint about Scala, the #1 reason why the compiler is so slow and one of the main reasons why people say that Scala code can be very hard to reason about. I can't believe Odersky is doubling down on the implicit approach with Dotty. He just seems to be stuck in a language design corner and not willing to look at other ways to approach this problem. It's programming language design myopia.
- fnl 9y ago
  Sadly, I agree on your beef about implicits. They are a nice idea, but are far to easy to abuse to "hide" poor design.
- doikor 9y ago
  Implicit parameters are one of my favorite features of the language. I think most of the ambiguity comes from the days when IDEs couldn’t tell you what implicit was being used. I see the implicit functions as a great addition to the language making certain kind of code much easier to reason about. Personally most of the “wtf is going on here” comes from implicit conversions and usage of symbols (both of which have thankfully gone out of style for the most part)
  - hota_mazi 9y ago
    > Implicit parameters are one of my favorite features of the language. The real question is: does the team you work with share your love of implicits? Implicits are fun to use but they lead to code that's very hard to follow, so it's not uncommon to come across people who love them but these same people don't always realize the kind of code they are writing until way later.
    - doikor 9y ago
      There is some learning curve for people not familiar with Scala (not enough Scala developers in the market here so we have to "train" new developers often) But in general I haven't heard that many complaints outside of the few places where we use them for type level programming (Shapeless. Where most of the complaints are related to compile times). But the goal is usually to hide this behind some library or easy to understand type class instance and using implicits and shapeless to automatically derive the instances. In general all the type class based stuff relies on implicits to be really useful and haven't really heard any complaints related to that pattern from anyone once they actually understand what type classes are and what they are used for. Almost all the other use we have for implicits is automatically passing some context around in the app. This is things like RequestContext traveling down through the app and transmitting it to the next service in the chain. Basically only used so you don't have to be manually passing it around all the time. (another common example of this is passing ExecutionContext around. Or the ctx: Context in scalac that Martin mentions which appears 2600 times. If having it as implicit parameter 2600 times is pain think about having to manually fill it in) Implicits conversions is something we try to say away from if possible (there are some valid use cases for it but be careful with it)
- dominotw 9y ago
  I started scala with Akka Http and magnet pattern[1] is the most convoluted, disgusting abuse of any language feature i've encountered. I really dislike implicits, implicit conversions ect, doesn't matter how awesome features it enables you to use. Can implicit fans explain to me how I am supposed to navigate to the correct overloaded method in Magnet pattern? Even IDE's like intellij Idea have no idea what to navigate to. If its so hard of an IDE to figure out, how are humans supposed to deal with this. http://spray.io/blog/2012-12-13-the-magnet-pattern/ http://spray.io/blog/2012-12-13-the-magnet-pattern/
  - s4vi0r 9y ago
    If you have to write that kind of code for work you're probably out of luck, but if you're comfortable with FP and have some control over your stack I'd suggest the typelevel stack. I didn't know what the magnet pattern was until you just said so, and it seems like an awful idea relying on implicit abuse on the level of the cake pattern - something which has been discouraged for the last 4 years now. Implicits are great, and allow you to do some really amazing things, but you have to be careful not to abuse them or risk making your code take forever to compile and be impossible to debug.
  - MrBuddyCasino 9y ago
    And I thought I was the only only to go "wtf" when I first read about the magnet pattern. They claimed it to be "elegant", but it really is only "clever" in the worst possible way and makes it hard to reason about the code. I've got a theory that the type of people doing overly complex Java enterprise (see EJB 2.1) 15 years ago haven't vanished, they're just doing Scala now.
    - doikor 9y ago
      Magnet pattern is purely about making the code you write nicer to look at. (for spray it had more reasons to exist but for akka-http it is purely a usability problem) Basically it allows you to write def f[T](fMagnet: FMagnet[T]): X => Y f(t) { x => // ... } instead of def f[T](t: T)(implicit tc: TC[T]): X => Y f(t).apply { x => // ... } so just about removing one ".apply" (see https://github.com/akka/akka-http/issues/100 https://github.com/akka/akka-http/issues/100 where i copy pasted the code bits from) But yeah first time I read up on the magnet pattern it was a wtf moment.

by fnl 9y ago

Would class fields not be a solution based on mutable state? Isn't that exactly the problem Odersky addresses in the beginning that your state can get mutated while your transaction is ongoing?

fnl 9y ago

Indeed, Guice even recommends not to use (static) final fields. https://github.com/google/guice/wiki/Injections https://github.com/google/guice/wiki/Injections

hota_mazi 9y ago
I was talking about regular (instance) fields, not static ones.
- fnl 9y ago
  Right. "class fields" as opposed to "instance fields" had me confused.

hota_mazi 9y ago

Not necessarily. These fields can be references to immutable objects. Note that Dotty's implicit approach is similar in that respect, it doesn't prescribe anything in terms of mutability/immutability. But we've already gone down the path of implicits, they are the #1 complaint about Scala, the #1 reason why the compiler is so slow and one of the main reasons why people say that Scala code can be very hard to reason about. I can't believe Odersky is doubling down on the implicit approach with Dotty. He just seems to be stuck in a language design corner and not willing to look at other ways to approach this problem. It's programming language design myopia.

fnl 9y ago
Sadly, I agree on your beef about implicits. They are a nice idea, but are far to easy to abuse to "hide" poor design.
doikor 9y ago
Implicit parameters are one of my favorite features of the language. I think most of the ambiguity comes from the days when IDEs couldn’t tell you what implicit was being used. I see the implicit functions as a great addition to the language making certain kind of code much easier to reason about. Personally most of the “wtf is going on here” comes from implicit conversions and usage of symbols (both of which have thankfully gone out of style for the most part)
- hota_mazi 9y ago
  > Implicit parameters are one of my favorite features of the language. The real question is: does the team you work with share your love of implicits? Implicits are fun to use but they lead to code that's very hard to follow, so it's not uncommon to come across people who love them but these same people don't always realize the kind of code they are writing until way later.
  - doikor 9y ago
    There is some learning curve for people not familiar with Scala (not enough Scala developers in the market here so we have to "train" new developers often) But in general I haven't heard that many complaints outside of the few places where we use them for type level programming (Shapeless. Where most of the complaints are related to compile times). But the goal is usually to hide this behind some library or easy to understand type class instance and using implicits and shapeless to automatically derive the instances. In general all the type class based stuff relies on implicits to be really useful and haven't really heard any complaints related to that pattern from anyone once they actually understand what type classes are and what they are used for. Almost all the other use we have for implicits is automatically passing some context around in the app. This is things like RequestContext traveling down through the app and transmitting it to the next service in the chain. Basically only used so you don't have to be manually passing it around all the time. (another common example of this is passing ExecutionContext around. Or the ctx: Context in scalac that Martin mentions which appears 2600 times. If having it as implicit parameter 2600 times is pain think about having to manually fill it in) Implicits conversions is something we try to say away from if possible (there are some valid use cases for it but be careful with it)
dominotw 9y ago
I started scala with Akka Http and magnet pattern[1] is the most convoluted, disgusting abuse of any language feature i've encountered. I really dislike implicits, implicit conversions ect, doesn't matter how awesome features it enables you to use. Can implicit fans explain to me how I am supposed to navigate to the correct overloaded method in Magnet pattern? Even IDE's like intellij Idea have no idea what to navigate to. If its so hard of an IDE to figure out, how are humans supposed to deal with this. http://spray.io/blog/2012-12-13-the-magnet-pattern/ http://spray.io/blog/2012-12-13-the-magnet-pattern/
- s4vi0r 9y ago
  If you have to write that kind of code for work you're probably out of luck, but if you're comfortable with FP and have some control over your stack I'd suggest the typelevel stack. I didn't know what the magnet pattern was until you just said so, and it seems like an awful idea relying on implicit abuse on the level of the cake pattern - something which has been discouraged for the last 4 years now. Implicits are great, and allow you to do some really amazing things, but you have to be careful not to abuse them or risk making your code take forever to compile and be impossible to debug.
- MrBuddyCasino 9y ago
  And I thought I was the only only to go "wtf" when I first read about the magnet pattern. They claimed it to be "elegant", but it really is only "clever" in the worst possible way and makes it hard to reason about the code. I've got a theory that the type of people doing overly complex Java enterprise (see EJB 2.1) 15 years ago haven't vanished, they're just doing Scala now.
  - doikor 9y ago
    Magnet pattern is purely about making the code you write nicer to look at. (for spray it had more reasons to exist but for akka-http it is purely a usability problem) Basically it allows you to write def f[T](fMagnet: FMagnet[T]): X => Y f(t) { x => // ... } instead of def f[T](t: T)(implicit tc: TC[T]): X => Y f(t).apply { x => // ... } so just about removing one ".apply" (see https://github.com/akka/akka-http/issues/100 https://github.com/akka/akka-http/issues/100 where i copy pasted the code bits from) But yeah first time I read up on the magnet pattern it was a wtf moment.