First, I must say that I like the idea of the language. It has ADTs (case classes) and typeclasses (traits), a bit of type inference, can run on Android and isn't Java. It's just the baroque syntax that bothers me.
It starts from this [1]. Then there's case classes, _, optional everything (forgetting = in a function def can make it mean something else), the currying syntax [2] (sometimes it needs an arbitrary _ to break ambiguity), the imports (especially renaming), arbitrary rules on whether construction needs "new" or not, etc.
The fact that [3] is possible even though Scala is not an almost-no-syntax language (like Lisps and Haskell) concerns me. And it even has macros, but all of its very many language features aren't implemented as macros :(
_ is a godsend for code conciseness; I'll accept that it comes at a complexity cost. I'd argue it's less confusing than Haskell's pointfree style (which is how you do the equivalent).
optional = in function definitions is legacy that will hopefully go away at some point. Optional brackets and braces are something most languages have (bwim you can usually bracket or unbracket an expression without changing it), so it doesn't bother me that scala has them in slightly more places.
Using _ for partial application of an object method is simpler than you make it sound; you always need it. That page misunderstands. I dislike the complexity but it allows UAP to work which is awesome; are there languages with a similar UAP and functions-as-values without requiring disambiguation?
Agreed that relative imports and renaming imports are evil bad and wrong.
Construction requires new; I think this is largely there because it's a major difference at the JVM level and some people care about knowing when it's happening. Personally I agree we'd be better off without it.
Macros are new and experimental. I suspect that if/when they gain acceptance we'll see core language features implemented using them where this simplifies (e.g. there's no reason for comprehensions and case classes couldn't be macros).
- [1] comes down to the idea of not having to build two separate concepts (namely, operators AND methods) with different syntax, different declaration styles, different parsing rules, ... into the language. Scala has only methods (which can have a “symbolic” name). The usual precedence rules are based on that name.
- case classes: I love them.
- _: The underscore has one meaning, “there is something, but I don't care about the name”. Super simple.
- forgetting = in a function def can make it mean something else: I agree, it is very error-prone. As far as I know, there are some proposals to get completely rid of procedure syntax.
- currying syntax: PinS has a pretty good explanation why it works that way. It is certainly not perfect, but less error-prone than alternatives.
- the imports (especially renaming): Many languages have this feature and I have not seen any issues with it.
- arbitrary rules on whether construction needs "new" or not: No. The rule is that you always need new to construct an instance.
-[3]: You can do crazy stuff in every language. Have a look at functional code written in Java.
- And it even has macros, but all of its very many language features aren't implemented as macros: No. In a sense, ALL features are implemented via macros, because the compiler API and the reflection API (macros) are pretty much the same underneath.
- I don't mind unifying operators and functions/methods, I think it's a great idea. What I do dislike is having lots of optional syntax that is however still used much of the time. I much prefer using ( ) only for disambiguation
- case classes are great because they're a Algebraic Data Types. I dislike their syntax
- the underscore is sometimes necessary for disambiguation, that's the only thing that bothers me
- I don't mind the fact that renaming imports is possible, I think that's great. I just dislike the particularly unusual syntax, since = is already there for symbol binding
- since there isn't a de-sugared version of every language construct, I doubt macros are indeed that equivalent. Again, I think macros are great, but it worries me when a language's syntax is already so complex through "hard-coded" methods (as opposed to the more programmatic macros)
Could you expand on that a bit?