Re: [scala] The right tool — by Martin Odersky

http://scala-programming-language.1934581.n4.nabble.com/The-right-tool-td2220305.html#a2222101

In reply to this post by Erik Engbrecht
On Mon, May 17, 2010 at 10:49 PM, Erik Engbrecht <[hidden email]> wrote:

I think Scala is very large compared to languages like Python or Java, but smaller than C++.
By “large” I mean there are a lot of concepts in the language.  Just to list a few that aren’t in Java…
… I am always a bit uneasy when reading a list like this and arguing with it. Yes, Scala has a lot of features but it tries very hard to make them facets of a uniform core which is not that large. I realize that for a newcomer, in particular someone brought up in the C/Java tradition, Scala might look large. For instance, objects/companion objects which you mention. If you do an in-depth study of language specs, these are actually significantly simpler then Java’s static class members. But static class members are known whereas companion objects are less well known, so they look more complex for most people.

Here’s a discussion of the other features you mention, in comparison to Java.

  • Higher kinded types

Yes, that’s definitely beyond Java. This is the one feature where for a long time I was not sure whether it is worth the weight. I have been leaning recently more towards believing that it will probably turn out to be quite useful.

  • by-name method parameters
vs special treatment of ||, &&, assert.
  • companion objects
vs statics (see above).
  • case classes
vs enums (arguably at least as complicated in both syntax and type checking).
  • structural types
Yes.
  • closures / first-class functions
Yes, until Java gets them, in which case Java’s will be more complex, due to throws clauses.
  • for comprehensions
vs extended for-loops, looks like pretty much the same thing to me.
  • mixin composition / multiple inheritence
vs extends/implements. Again, you might argure that traits simply drop some restrictions in interfaces.
  • self types
yes, sort of. Again we simply drop a restriction in Java on the type of `this’.
  • type inference
Not sure that adds complexity per se. Java does it as well, but more clumsily. Have you looked at the
<> notation in Java 7? How is that simpler?
  • currying
You might say, we just drop a restriction that functions have only one parameter list…
OK I concede, it’s a yes.
  • pattern matching (and associated unapply etc support machinery)
vs switches, which are getting more complex, and I always forget to put a break at the end of a case.
  • loose syntax for some language constructs, e.g. dropping parenthesis
Yes, but Java programmers have to learn that it’s array.length, but string.length(). Not sure what is better.
  • specialization
That’s an annotation-driven optimization. I don’t think we should count that
  • operator overloading
Compared to the large number of synactically defined operators in Java I think that’s a net win.
  • multiple parameter lists for methods
That’s a duplicate of currying.
  • parameter lists that come before the method name (colon prefixed operators)
You mean colon-suffixed, right? yes.
  • implicits (parameters, conversions, values)
Yes, but they let us avoid a lot of special cases.
  • stable ids vs non-stable ids
Linked to abstract types, yes.
  • default arguments
Yes.
  • lazy values
Vs special static member initialization, which also has lazy semantics.
  • added access qualifiers (e.g. private[this])
Vs dropping package level visibility.
  • XML as-a-language construct
Yes. That’s the second extension where in retrospect I am not sure it was a good thing overall. When we started out with Scala, XML was the showcase where functional programming could be clearly shown to be useful. At the time most people thought you could do everything with pure OOP. So we added XML.. Today, the case for FP is much stronger, and the case for XML has gotten weaker. So maybe the inclusion of XML in Scala was a historical accident. But anyway, it’s in, and will stay in.
  • …and I’m probably forgeting some…
So what does it drop from Java:
  • static members
  • field / method dichotomy
  • object / primitive dichotomy
I think you seriously underestimate the complexities in Java. Just some points, it’s far from an exhaustive list

– 4 namespaces (methods/fields/types/packages) instead of two.
– different name resolution rules for each namespace.
– enums
– annotations (yes Scala has them as well but they are much, much simpler than Java’s)
– some tricky syntactic corner cases to disambiguate between casts and expressions.
– nasty explicit parameterization. Does anyone even know how to pass a type parameter to a method in Java?
– over-reliance on wildcards, leading to very hard to diagnose type errors.
– restrictions on arrays with generics.
– raw types(!)
– restrictions that inner classes can only acces final members.
– super constructors.
– dataflow analyses for definite assigment and termination (these are actually useful, but burn about 20 pages in the spec).
– throws clauses and the rules governing them
– auto-boxing
– complicated rules what kind of casts are allowed where

A lot of these points look simple, but start to read up on their precise rules, they are anything but.

I don’t want to get into a feature to feature comparison between languages. My main point is, that, if you draw up a list of bullet points you can make any language look forbiddingly complex.

I certainly agree that if Java is your point of departure, then there is a lot of new stuff to learn in Scala. My argument is that there is also a lot of stuff in Java that people take more or less for granted but that is pretty complicated under the covers (and I argue from quite intimate experience here).

Some measures: The grammar of Scala is actually smaller than the grammar of Java. The typechecker of Scala is about the same length in lines of code as the type checker for Java, or the type checker for Haskell. Of course, every type checker is written in its own language, so you can draw an infinite number of conclusions form that, all of the form:

Scala’s type system is X-times more complicated than Java’s or Haskell’s, but code written in the language
is X-times more compact

where X ranges from 0 to infinity.

Cheers

— Martin

Tags:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: