5 ms·

Scala has a lot of 'sugar': f(...) becomes f.apply(...) matching calls unapply with some various binding. Some parenthesis are optional: Some(1,2,3) is Some(

Scala has a lot of 'sugar': f(...) becomes f.apply(...) matching calls unapply with some various binding. Some parenthesis are optional: Some(1,2,3) is Some((1,2,3)) optional . so a + b is a.+(b) colon changes associativity, so a +: b is b.+:(a) for expressions become, map, flatMap, filter, withFilter and forEach, according to various rules. def f[A: B]() adds an implicit parameter of type B[A] I'm sure there's more but that's the top of my head. Of course it's not actually a long list, but none of that is obvious for a newcomer.

nikitaga 5y ago
The fact that you can make any instance callable like a function by adding an `apply` method to it isn't just "syntax sugar", it's a pretty fundamental mechanic of FP-OOP fusion that Scala is built around. Same for `unapply`. At any rate none of this "sugar" was a problem to anyone I know who learned Scala. There are harder things about it than learning basic syntax.
- dyadic 5y ago
  It’s a long time since I used scala and none of this was ever a direct problem, but it was all extra complexity. I think there’s a split between people that appreciate sugar and people that find it not worth the additional complexity. That problem does lessen with familiarity, but knowing a lot of complexity makes me wary of unknown complexities. It adds an overhead which takes energy that could be better utilised elsewhere.
  - nikitaga 5y ago
    If you don't need that "complexity" (I wouldn't call it that), you can use a pure FP or a pure OOP language that will be simpler, smaller, but more restrictive and less expressive. That's a matter of preference of course. But Scala's syntax and language features are great when you actually make use of them to accomplish your goals, especially so with Scala 3. The syntax isn't excessive or frivolous or nonintuitive. It's a pretty straightforward encoding of the desired feature set of the language.
- patrickthebold 5y ago
  Why do you consider it fundamental? Are there examples where it fundamentally does more than saving you from typing out the canonical method name? (This is for `apply`, I agree that match with unapply is actually language syntax and not sugar.)
  - nikitaga 5y ago
    Because it enables an equivalence between functions and objects. Not a technical one that's hidden deep in the implementation, but a practical one that's apparent to library authors and users. If you want to make any object `foo` callable with first-class application syntax, i.e. `foo(bar)`, you add an `apply` method to that `foo`. You don't need to bother extending Function, you don't need to come up with a method name and call that. When you call `foo()`, you don't know if `foo` is a function or an object, and you don't care. You can find out easily with a half decent editor of course, but the point is, you're free to mix objects and functions as you wish, the language does not get in your way. And for all that it provides, it's a complete non-issue in terms of learning curve. It's a basic language feature that you learn once and are never impeded by thereafter.
yawaramin 5y ago
> Some parenthesis are optional: Some(1,2,3) is Some((1,2,3)) There's a compiler warning against this syntax that everyone should really enable.

nikitaga 5y ago

The fact that you can make any instance callable like a function by adding an `apply` method to it isn't just "syntax sugar", it's a pretty fundamental mechanic of FP-OOP fusion that Scala is built around. Same for `unapply`. At any rate none of this "sugar" was a problem to anyone I know who learned Scala. There are harder things about it than learning basic syntax.

dyadic 5y ago
It’s a long time since I used scala and none of this was ever a direct problem, but it was all extra complexity. I think there’s a split between people that appreciate sugar and people that find it not worth the additional complexity. That problem does lessen with familiarity, but knowing a lot of complexity makes me wary of unknown complexities. It adds an overhead which takes energy that could be better utilised elsewhere.
- nikitaga 5y ago
  If you don't need that "complexity" (I wouldn't call it that), you can use a pure FP or a pure OOP language that will be simpler, smaller, but more restrictive and less expressive. That's a matter of preference of course. But Scala's syntax and language features are great when you actually make use of them to accomplish your goals, especially so with Scala 3. The syntax isn't excessive or frivolous or nonintuitive. It's a pretty straightforward encoding of the desired feature set of the language.
patrickthebold 5y ago
Why do you consider it fundamental? Are there examples where it fundamentally does more than saving you from typing out the canonical method name? (This is for `apply`, I agree that match with unapply is actually language syntax and not sugar.)
- nikitaga 5y ago
  Because it enables an equivalence between functions and objects. Not a technical one that's hidden deep in the implementation, but a practical one that's apparent to library authors and users. If you want to make any object `foo` callable with first-class application syntax, i.e. `foo(bar)`, you add an `apply` method to that `foo`. You don't need to bother extending Function, you don't need to come up with a method name and call that. When you call `foo()`, you don't know if `foo` is a function or an object, and you don't care. You can find out easily with a half decent editor of course, but the point is, you're free to mix objects and functions as you wish, the language does not get in your way. And for all that it provides, it's a complete non-issue in terms of learning curve. It's a basic language feature that you learn once and are never impeded by thereafter.

yawaramin 5y ago

> Some parenthesis are optional: Some(1,2,3) is Some((1,2,3)) There's a compiler warning against this syntax that everyone should really enable.