> I've developed an aversion to anything that doesn't
> follow the Zen of Python: "There should be one-- and
> preferably only one --obvious way to do it."
this is an interesting argument. but surely, given enough rope, a non-expert can hang himself in any language. I'm starting to wonder that all these language X vs language Y problems are really a matter of the skills of the team matched with the difficulty of the problem. joe bloe's blog needs beginner skills with python. embedded wireless systems need experts and C/asm, nuclear control systems are prototyped by experts in haskell. bigcos need large teams of average skill with Java, but as they are driven to become more competitive, perhaps they will turn to small teams of experts using scala.
> surely, given enough rope, a non-expert can hang himself in any language
I completely agree, and sometimes productivity absolutely demands that developers become more expressive. I've found Java overly restrictive in the past, and have spent time learning Python, Haskell and other languages (and seen decent increases in productivity when I feel less fettered by the language I'm programming in). That said, I've also come to appreciate the effect of more restrictive languages: readability and long-term maintainability. Coming back to old code can always be jarring; having to maintain decade-old Perl written in a variety of different styles was maddening.
While you can screw up in anything, it's worth appreciating that more expressive languages effectively hand you more "rope" :).
It's easy to blame the user, but the fact is that there are languages designed in good taste and languages designed in bad taste. I'd argue C++ is an example of the latter, with its panoply of awkward non-orthogonal features. It's quite possible that Scala is too, and that it's not just the user's fault.
The difference is how easy a language makes it to hang ones self, or how many ropes are lying around to do it with. I think the article touches on it aptly. It's not so much a fault of the language (one can debate the semantics of it), so much as it is an outcome of greater-than n-sized (where n is 1, 2, maybe 3) non-high-expert-Scala-users teams. The lack of an easy to grok idiomatic way of writing code is hard on a team. It bothers me when I write code and don't know the idiomatic way of doing it, and I'll often solicit feedback and rewrite it just for my own sake (really, on code that no one else will ever really see or touch).