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++.
Terrible, terrible answer if you are mostly doing functional Scala. I've got a blog post that deals with this.
Tl;dr: Java libs are good along as they are thread-safe or immutable; if they're not, you're looking at horrible side-effects where there shouldn't be any.
For many use cases OO Scala works just fine, functional code used where it makes sense. Our goal is to integrate with existing systems, not to seek purely functional code as a goal in and of itself.
I agree with the concept. My concern is what happens as your team grows to include others whose Scala background is more functional. There is a sense that they should be aware of the old way your code base is put together. Unfortunately things could go awry when they code new functional based code expecting functional based input.
Don't get me wrong, I like Scala. You just really have to watch its dual paradigm behavior when dealing with Java code
Uhm, although I admit Haskell is a powerful language, there are quite a few things that Haskell can't express as clearly as Scala. E.g. Haskell can't express nominal subtyping.
not nominal subtyping in action? Any type you create a Monad instance for will be accepted, so subtyping. You have to actually make it an instance of Monad, it can't just have the structure of a monad, so nominal.
Right, I don't know much about Haskell (not actively programming in it), but I know that Haskell was not designed with OOP in mind and things like polymorphic nominal subclassing are not first-class there. There are also some things that Haskell's type system can't do e.g. the nice thing that Scala does with fold/map/reduce always returning the right type, even if it has to be a different type than the type of the source collection. I'd like to be proven wrong, Haskell is on my list of next languages to learn well ;)
Haskell's typeclasses (which are almost identical to traits) support polymorphic nominal subclassing just fine.
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.
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)
