David is spot on when it comes to the complexity of the documentation; it's great that it's exhaustive, but it would be nice to have the "here's how to use it" documentation near the "here's how to implement your own collection type" doc.
Another trend I see in Scala is the abuse of symbols-as-method names. I see a lot of Scala (and Lift) code that looks like
Scala is one of those languages where you need to employ some restraint in order to use it effectively. I think Lift in particular suffers from too enthusiastic a use of the more esoteric language features.
I just think the patterns for what makes a good library interface haven't completely coalesced yet. One can introduce horrifically complex interfaces in Ruby as well, but the best libraries expose a simple, consistent interface.
I hope that's an exaggeration. I'm just starting to look into scala as a directional language for our team (new projects), but if real-life scala code tends toward that sort of ugliness we'll stay with java.
Well, when I say "tends toward" what I mean is if I have an average team of programmers, when I look through the code a year after the project starts, is this what I'm going to find?
I realize expert programmers can write legible code in any language, in the same way Tiger Woods can best me over 18 holes using only a five iron. But there are some languages, like C++, that tempt mediocre programmers into writing illegible code. That's a big strike against, IMO.
I doubt you'll have to worry about that specific problem with a team of average programmers. They won't be naming new functions with pure symbols, which is what that code represents. Just don't tell them Scala allows that and you should be fine. If they figure it out, outlaw it and require the use traditional descriptive English camelcase.
It does whatever you want it to do. ~->, <~<, and %% are just method names. It parses like:
val foo = bar.~->(45).<~<("Fred").%%(x)
If those same methods were called a, b, and c instead, it would parse like:
val foo = bar.a(45).b("Fred").c(x)
Yes, some people abuse symbolic method names. Unless your method makes overwhelming sense with a symbolic name (+, -, *, etc), just don't do that. But this problem isn't unique to Scala; poor names can strike in any language. If I called my method "slfjowierlksdfjnas", that'd be bad too. But most developers have enough common sense to choose reasonable names for their methods.
Another trend I see in Scala is the abuse of symbols-as-method names. I see a lot of Scala (and Lift) code that looks like
with little commonality of convention.