Okay, time for a helpful corrective for my usual rah-rah cheerleading for the Scala language.
Paul Phillips was, until recently, one of the crucial point people on the Scala compiler. Martin Odersky is the effective owner of the language -- he invented it, and is still the final authority on what goes in -- but paulp was the guy most conspicuously on the front line implementing it. Notably, he has been the person doing the most checkins of actual compiler code. He and Martin have had some friction for a while now, and paulp finally quit a month or two ago.
This video is a talk that paulp gave at the Pacific Northwest Scala conference recently, and it's bloody fascinating. In it, Paul makes clear that this isn't a personal thing: he just can't cope with trying to make the language compile any more, and he spells out exactly why. The moral of the story is mainly that, in the interest of being deeply Java-compatible and at least halfway performant, while still adding all this power and expressiveness, Scala has wound up with scads of hard-to-reason-about corner cases. And the result is that trying to keep the compiler functioning is fantastically difficult.
Mind, none of this says that Scala is a bad language -- the talk doesn't shift me in my general opinion that it is the most practical language for serious application development available today. But he does wind up more or less calling for folks to move to the next generation: that Scala's assumptions (and *especially* the assumptions inherent in trying to be JVM-compatible) are holding things back, and will always do so.
He winds up making some suggestions that are almost startlingly radical about how software development should work, right down to questioning the way we think about languages and compilers. (Fascinatingly, a couple of the suggestions he comes up with for how things *should* work, such as rethinking the relationships of the components of "programming" and worrying less about universal generality, are along the lines of what I wound up with for Querki.) He also goes into a lot of detail about why he considers Scala in some ways *too* general and expressive, which likely has some truth to it. (Although he's especially sensitive to this problem, since he's had to deal with the resulting fallout more than most people.)
Anyway, the talk is long but worthwhile if you are interested in language theory and design. Paul is influential enough that I have a suspicion that this may prove to be the seed of *something* that may develop in the coming years.
(Initially, the main result is a lot of Haskell folks going, "Hah! See?", but I suspect that Haskell isn't going to suddenly take over the world. Paul is actually calling for something even more radical than that...)