There are much less complex but precisely as powerful languages out there (like Haskell). Scala's crazy amount of syntax is what makes me avoid it, not unlike C++.
http://talesfromannoyance.blogspot.com/2012/05/why-im-lookin...
If you want reuse, you need to look at taking those parts and wrapping them up in SOA.
Don't get me wrong, I like Scala. You just really have to watch its dual paradigm behavior when dealing with Java code
Monad m => Int -> m Bool
Haskell actually has whole program type inference (unlike Scala, which only does local inference), so fold/map will always return the right type as well, but you also get to not have to put types anywhere if you don't want to (including function signatures).
Scala's main advantage over Haskell is being able to call into Java.
+ a superior module system + better type classes (no global namespace)
But yes, if running on the JVM is no option, Haskell is a serious contender
Could you expand on that a bit?
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 :(
1. http://en.wikipedia.org/wiki/Scala_(programming_language)#Sy... 2. http://brenocon.com/scalacheat/ 3. http://blog.fogus.me/2009/03/26/baysick-a-scala-dsl-implemen...
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).
It is usable now even for production although the compiler is not yet optimized and the language is still evolving.
- 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.
- 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)