Re: The Origins of Scala
Posted: May 6, 2009 3:08 PM
> Heh. It is interesting that a lot of the longer
> discussions in artima become a debate over the
> complications of generic variance. That alone indicates
> something is wrong. I've said this many times here: a
> feature of a type system is useful only if it *helps*
> **us** read and write code. If it's confusing us, it's not
> helping, thus it's not useful.
I agree with the general thrust here, but might say it differently. I think you need to strive to make features as simple as possible. But sometimes a feature, though it be hard to learn, can be still worth it. In other words, even if the cost is great, it can still be worthwhile so long as the benefit is greater.
> A lot of smart people have a difficult time grasping
> variance with respect to type parameters esp. with call
> site variance e.g., wildcards in Java. Definition site
> variance as discussed here (too) many times is also a hard
> pill to swallow. The difficulties arising from generics in
> both Java and Scala, in my opinion, indicate a failed
> experiment -- so far generics in the aggregate is not
> helping us.
I've met a lot of people who have expressed the same sentiment about Java's wildcards, and I myself have that feeling. Although the basic concept of a wildcard I pretty much grok, I find the subtleties of wildcards quite confusing and challenging myself. By contrast, I find Scala's declaration site variance quite easy to grok. The most challenging part for me was contravariance, but with some study I got it.
You made a blanket statement that smart people find definition site variance a hard pill to swallow. I've know many dynamic typing leaning folks who don't want to swallow the pill, but I must say so far I've never heard someone who actually programs in Scala complain that Scala's variance is too hard to understand. They all have complaints, as do I, but the complexity of the type system just doesn't pop up much as a complaint.
That said, I think it is too early to tell. The people coming to Scala so far are early adopters and may not represent the mainstream well. They may also be people who are comfortable with type systems, etc. So what I'm curious about is to what extent this will become a complaint as more people try Scala. It also tells me that maybe I should publish some things that try and explain definition site variance in easy to understand terms.
> I'm not suggesting we should abandon generics. We just
> need to be pragmatic about how we integrate generics into
> a language so that it's useful to most people who'll use
> the language. Since most people seem to have no problem
> understanding variance with respect to array component
> types, I'm inclined to believe that is the best option we
> have (so far). Thus the GScript and Eiffel approach seem
> like the way to go.
Eiffel, we've been guessing, didn't really let you pass functions around. So contravariance wasn't an issue there as much. But most of today's emerging languages have first class functions. That's one of the trends.
If I understand Carson correctly, GScript does have contravariance of function parameters. So GScript has contravariance, the hard to understand one. It just only has it in one place, like Fan's only letting you put type parameters on Map, List, or Func, or Java only letting you use + on String. Scala just makes contravariance a general feature. You can make your own types contravariant if you want. The place where I've seen contravariance used in Scala is primarily function parameters. The place where I used it was in Matcher, which is also a function, and contravariance is for the function parameter. It was nice that I could do that.
What GScript does then, if I understand it, is everything else is covariant, a la Eiffel. In Scala, other things will be either nonvariant or covariant. The Scala compiler will only let you make something covariant if it is type sound. It won't let you make a mistake. Also, if you're not sure, just start out nonvariant. Later you can make it covariant without breaking any client code. There are no wildcards to think about, and with those out of the way, I really don't think the conceptual complexity of grasping this stuff is much greater in Scala than GScript.
But as I said before, time will tell. I'm not sure Scala's early adopters are a good measure of how palatable the masses would find Scala's approach to variance.