Log in

No account? Create an account
Previous Entry Share Next Entry
Scalac: We're Doing it All Wrong
[Strictly for programmers. In this case, mainly for pretty advanced ones.]

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...)

  • 1
Thanks for the link. Hoping to sit down and get some quality time with this as we were wrestling with some of the same issues in Fortress (and I'm *very* curious to see which things he thinks Haskell got right).

Actually, it's not so much that he calls Haskell out for doing things right, as that several folks from the Haskell community have been pointing out that they *don't* have the problems he cites. Which is probably true, but I'm not sure whether he would agree that Haskell is a clear improvement. (Ditto Clojure, Ceylon, etc.)

He does say specifically that the Scala libraries *overuse* inheritance (and I think the implication is that the Collections library, in particular, ought to be more typeclass-driven), but I don't believe he implies that there shouldn't *be* such a thing. His arguments are fairly nuanced, and largely focused on the notion that Scala has tried to accomplish a bit too much for its own good.

My main takeaway is that, if we really want to progress to something better, we need to rethink our assumptions quite fundamentally. He goes so far as to question the wisdom of assuming that a "program" should be defined as a collection of strings. The most refreshing aspect of the whole thing is that at this point he is willing to gore *all* the sacred cows...

Scala certainly strode unabashedly into the Giant Bloated Language pit, where it joins Common Lisp and C++.

The lisp crowd have been making the "program is not a collection of strings" argument for years, of course, but their counter-proposal, that it's a collection of nested lists instead, isn't obviously compelling. The Scheme / Racket crowd have a more nuanced view of this now (they only look like lists to you, they are still abstract syntax trees).

Got to actually spend some quality time with this last night. A nice bit of confessional, I particularly like the bit where he admits that he didn't realize how wrong it would be to inherit implementations between mutable and immutable collection classes (we wrestled with that one, not particularly successfully).

And now I know about the new Java Streams package, which has a distinctively familiar look and feel (and was the thing he said Java has just done better than Scala).

Are you in Bay Area? Are you a member of Scala Bay? Paul will be giving a talk (on a different topic though) in January at Scala Bay meeting.
But you probably can ask him if you come over.:)

Sorry, wrong coast -- I'm in Boston. (And really need to get hooked into the local Scala community one of these days...)

Afaik, they do have a pretty functional Scala meetup.

Yeah, just found it and joined. Looks like they're meeting once a month or so...

  • 1