Be careful that you don't make the mistake of assuming Java is simple, just because you know the language.
See the attached mail from the scala mailing lists in which Martin Ordersky compares the two (and this man is eminently qualified to do so, having created the compilers for BOTH languages) I'd also argue that Java generics (with their use-site variance) are horrible in any serious use, as soon as you start needing <X extends Y> or <A super B> then Java feels anything but simple! On Mon, May 17, 2010 at 10:49 PM, Erik Engbrecht <[email protected]> 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 On 20 May 2010 08:35, Nick Wiedenbrueck <[email protected]>wrote: > Having a look at the straw-man proposal (http://cr.openjdk.java.net/ > ~mr/lambda/straw-man/) and the spec draft for project lambda (http:// > openjdk.java.net/projects/lambda/) I'm concerned that lambdas in Java > might add up too much complexity to the Java Language. For example > when it comes to subtyping of function types. > > We've had the (at least controversial) experience introducing generics > in Java 5. But while developers mostly use generics from a client side > perspective, which hides much of their complexity, lambdas (or > functions or closures) will be used to a huge part at the client side. > Another indicator is that Java gets closer to Scala, which many people > think is too complex. > > Do you think, these concerns are valid? > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
