4 ms·

Yeah the line between FP and OO can be argued over. At my work it's pretty OO, with FP used where convenient. People join and start reading/writing Scala with

Yeah the line between FP and OO can be argued over. At my work it's pretty OO, with FP used where convenient. People join and start reading/writing Scala with zero experience or training, and it works out OK. At Stripe, I understand their Scala is pure FP, with the first onboarding docs discussing "What is a Monad". I assume they need more training for people who don't have a pure-FP background, but if it works for them who am I to judge. My own personal style is somewhere in between, certainly more FP than at my work, but nowhere near as FP as those who are really into it.

dwohnitmok 6y ago
I think even if you ultimately use Scala as an almost entirely pure FP language (e.g. you live entirely in the Typelevel universe), you really need to understand the "desugaring to OO" well in a way that doesn't happen in the reverse direction (i.e. if you use Scala entirely as an OO language you don't really need to understand equivalent FP constructs). I think that's where a lot of flames towards Scala from some hard-core FP programmers came from: trying to use Scala as a pure FP language, but having to grapple constantly with the quirks of the underlying OO desugaring.
- cheriot 6y ago
  imho, it feels like the language is always getting in the way because much of Scala's FP ecosystem is created by abusing language features in ways the author did not intended. For example, when explaining typeclasses in Scala I found engineers quickly understood the concept of a typeclass and the got tripped up on how to make them with implicits. Scala3 really cleans a lot of that up.
  - dwohnitmok 6y ago
    FWIW I think that typeclasses are actually a prime example of what Scala 2's implicits were meant to enable from very early on rather than abuse of them (I know that e.g. the `Ordering` typeclass was at least in Scala 2.9 maybe earlier and context bounds to emulate typeclass syntax were in Scala 2.8). But I do think your example of typeclasses is a great one. It's a good example of an FP concept (typeclasses thought of as logical constraints to a type variable) desugaring into an OO one (additional implicit arguments).
    - cheriot 6y ago
      Fair point, although I'm not sure I'd call implicit function parameters an OO concept. Regardless, scala3 will make that conversation so much simpler http://dotty.epfl.ch/docs/reference/contextual/type-classes.html http://dotty.epfl.ch/docs/reference/contextual/type-classes....
      - dwohnitmok 6y ago
        > implicit function parameters an OO concept. True enough that implicitness is not an OO concept in and of itself (I think that was the operative word you're focusing on), but I do think it's the first thing that comes to mind if you're thinking in an OO manner. (Ugh... I keep needing to thread this parameter around... oh I know I could just use this DI library to implicitly insert this parameter for me!)

dwohnitmok 6y ago

I think even if you ultimately use Scala as an almost entirely pure FP language (e.g. you live entirely in the Typelevel universe), you really need to understand the "desugaring to OO" well in a way that doesn't happen in the reverse direction (i.e. if you use Scala entirely as an OO language you don't really need to understand equivalent FP constructs). I think that's where a lot of flames towards Scala from some hard-core FP programmers came from: trying to use Scala as a pure FP language, but having to grapple constantly with the quirks of the underlying OO desugaring.

cheriot 6y ago
imho, it feels like the language is always getting in the way because much of Scala's FP ecosystem is created by abusing language features in ways the author did not intended. For example, when explaining typeclasses in Scala I found engineers quickly understood the concept of a typeclass and the got tripped up on how to make them with implicits. Scala3 really cleans a lot of that up.
- dwohnitmok 6y ago
  FWIW I think that typeclasses are actually a prime example of what Scala 2's implicits were meant to enable from very early on rather than abuse of them (I know that e.g. the `Ordering` typeclass was at least in Scala 2.9 maybe earlier and context bounds to emulate typeclass syntax were in Scala 2.8). But I do think your example of typeclasses is a great one. It's a good example of an FP concept (typeclasses thought of as logical constraints to a type variable) desugaring into an OO one (additional implicit arguments).
  - cheriot 6y ago
    Fair point, although I'm not sure I'd call implicit function parameters an OO concept. Regardless, scala3 will make that conversation so much simpler http://dotty.epfl.ch/docs/reference/contextual/type-classes.html http://dotty.epfl.ch/docs/reference/contextual/type-classes....
    - dwohnitmok 6y ago
      > implicit function parameters an OO concept. True enough that implicitness is not an OO concept in and of itself (I think that was the operative word you're focusing on), but I do think it's the first thing that comes to mind if you're thinking in an OO manner. (Ugh... I keep needing to thread this parameter around... oh I know I could just use this DI library to implicitly insert this parameter for me!)