3 ms·

> So why don't you name those things that you don't like? Because then you will tell me that I don't like these features because I don't understand them? But

> So why don't you name those things that you don't like? Because then you will tell me that I don't like these features because I don't understand them? But alright, here are a few: - The type projector lambda syntax is absurdly arcane: `({type λ[α] = Either[A, α]})#λ]` - The curry syntax is silly as well (multiple parentheses) - The "_" character has eleven different meanings depending on where it's used [1] [1] http://stackoverflow.com/questions/8000903/what-are-all-the-uses-of-an-underscore-in-scala http://stackoverflow.com/questions/8000903/what-are-all-the-...

lmm 11y ago
The type lambda syntax is arcane, but that's not a feature - indeed if anything it's the absence of a feature (would you favour explicit support for type lambdas, like the plugin does?). If you're complaining about the syntax of curried functions then again that's not a complaint about a feature; likewise _. I'm not saying they aren't issues, but none of the things you mention is about Scala having "too many features".
- yawaramin 11y ago
  To be fair, isn't type projection a Scala feature? Have you ever seen another language that can do it?
  - lmm 11y ago
    It's not a language-level feature. It's a pattern that makes use of several features - type members, structural types, member selection. (You can often write these things more readably by splitting them onto two lines, putting the type alias in one place and the use of it in another, avoiding the need for the structural type and member selection). It's like the visitor pattern in a language that doesn't have pattern matching, or an explicit Y combinator in a language that doesn't have recursion. Some newer languages have this kind of functionality (in Haskell it's a GHC extension, I think).
bad_user 11y ago
Personally I'm not having discussions about Scala with the purpose of winning arguments, but rather with the purpose of clearing misunderstandings and this goes both ways. The "_" character is a placeholder for things that can be named, but for which you don't care about that name. And because you don't care about the name, it can function as a wildcard (i.e. any). To me all use-cases of the underscore make perfect sense and I can't remember a single instance in which I was confused by its meaning. Type lambdas are arcane, but as @lmm points out, this is more about the absence of a feature. Basically in Scala type lambdas do not have first class support and so they are based on Scala's abstract types. As to why they don't have first class support? Well, because people complain about too many features ;-) But it's worth pointing out that the TypeLevel folks have plans to introduce first-class support in their fork and thus propose an improvement. And also, because of the work that happened in Dotty, Scala the language is heading towards a DOT calculus foundation, along with a unification of higher kinded types with abstract types, which should iron out the edge cases. The curry syntax seems silly if you come from SML, Ocaml, Haskell or languages from the ML family in general. In such languages all functions have exactly one argument. But Scala is not an ML language and so it doesn't do currying by default. It's annoying sometimes, but as with all design choices there are disadvantages and benefits.

lmm 11y ago

The type lambda syntax is arcane, but that's not a feature - indeed if anything it's the absence of a feature (would you favour explicit support for type lambdas, like the plugin does?). If you're complaining about the syntax of curried functions then again that's not a complaint about a feature; likewise _. I'm not saying they aren't issues, but none of the things you mention is about Scala having "too many features".

yawaramin 11y ago
To be fair, isn't type projection a Scala feature? Have you ever seen another language that can do it?
- lmm 11y ago
  It's not a language-level feature. It's a pattern that makes use of several features - type members, structural types, member selection. (You can often write these things more readably by splitting them onto two lines, putting the type alias in one place and the use of it in another, avoiding the need for the structural type and member selection). It's like the visitor pattern in a language that doesn't have pattern matching, or an explicit Y combinator in a language that doesn't have recursion. Some newer languages have this kind of functionality (in Haskell it's a GHC extension, I think).

bad_user 11y ago

Personally I'm not having discussions about Scala with the purpose of winning arguments, but rather with the purpose of clearing misunderstandings and this goes both ways. The "_" character is a placeholder for things that can be named, but for which you don't care about that name. And because you don't care about the name, it can function as a wildcard (i.e. any). To me all use-cases of the underscore make perfect sense and I can't remember a single instance in which I was confused by its meaning. Type lambdas are arcane, but as @lmm points out, this is more about the absence of a feature. Basically in Scala type lambdas do not have first class support and so they are based on Scala's abstract types. As to why they don't have first class support? Well, because people complain about too many features ;-) But it's worth pointing out that the TypeLevel folks have plans to introduce first-class support in their fork and thus propose an improvement. And also, because of the work that happened in Dotty, Scala the language is heading towards a DOT calculus foundation, along with a unification of higher kinded types with abstract types, which should iron out the edge cases. The curry syntax seems silly if you come from SML, Ocaml, Haskell or languages from the ML family in general. In such languages all functions have exactly one argument. But Scala is not an ML language and so it doesn't do currying by default. It's annoying sometimes, but as with all design choices there are disadvantages and benefits.