3 ms·

> Haskell is getting OO-style dot-syntax for records. Go is getting generics. I would dispute the former means Haskell is getting OO features (more the case th

> Haskell is getting OO-style dot-syntax for records. Go is getting generics. I would dispute the former means Haskell is getting OO features (more the case that it's finally realized that having proper records a la Purescript or Elm is pretty important for day-to-day code; records and objects are quite different beasts) and Go getting generics is Go getting functional (or OO features, I don't find Go particularly OO to begin with). > Really, every language is converging on Scala I think this is more symptomatic of Scala trying to do so much to begin with, such that any change any language makes can be tied to some feature Scala has. That being said, I'm really happy to see Scala 3 reining in a lot of those choices (except a new parallel set of whitespace-based syntax... that seemed like a gratuitous cost to one's novelty budget, but time will tell; the community already seems to be warming to it). To those starting out with Scala, lihaoyi's book is a great place to begin! I'll offer one piece of advice (to those beginners, not lihaoyi, who I'm sure needs none of my advice). These days when I talk to people about Scala who've never used it before, I don't like talking about it as a hybrid FP/OO language. I prefer to describe it as an OO language with a lot of syntax sugar and standard library choices to enable emulation of FP on top when desired. It is useful to think of Scala the base language, i.e. what everything desugars to, as an OO language. This is neither good, nor bad. However, I think this realization helps illuminate a lot of strategies around coding in Scala. If your having performance issues, drop down to the desugared OO layer and you'll probably find ways to squeeze out more performance. If you're having a hard time understanding how some of the FP constructs work, step through their desugared OO equivalents (e.g. there aren't really higher-order functions, just an automatic instantiation of FunctionN classes wrapping methods at call sites). Scala 3 has smoothed out a lot of the mismatch so that its most obvious issues are gone (monomorphic functions vs polymorphic methods, weird eta expansion issues, weird subtyping requirements for implicit prioritization, etc.), but I've still found treating OO as the core of Scala to be a general rule of thumb which is useful for new Scala programmers when they come across something they think should work but doesn't. As you work more and more in Scala and that conversion of FP to OO primitives becomes extremely fluid and natural for you, a lot of choices and quirks that Scala has become far easier to explain and a lot easier to deal with.

lihaoyi 6y ago
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).

lihaoyi 6y ago

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).