There's two perspectives here: For many of Java's features, Scala will typically have a "simpler" alternative:
switch + catch blocks => pattern matching equals + hashCode + properties => case classes fields + properties => uniform access principle class static methods => singletons interfaces + explicit delegation => traits SAM interface + overridden methods => functions class declaration + constructor => class parameters call-site variance => declaration-site variance A lot of the benefit here comes from the unification illustrated in that list. When two concepts from Java are represented as a single concept in Scala, is "simpler" not the appropriate word? OTOH, Scala also has features that Just don't exist in Java: implicits higher-kinded types type members type inference type aliases This is different, to evaluate the relative complexity of the languages here you must compare Scala features to features that *Java doesn't have*. It's like asking if (null > 5) ... Fortunately, the languages are both Turing-complete. Anything that Scala can do is also possible in Java, just not directly. So how do Scala's features compare to "equivalent" Java approaches: implicits => implicits can be risky, it's true (but Java also has risky features). Used correctly, they are incredibly powerful and flexible. To use just one example, take dependency injection. The most common technique for doing this in Java is a framework such as Spring. higher-kinded types => The only real alternative is to work with raw collections and reflection. Higher-Kinded type signatures can be one of Scala's most challenging features when first seen, but they guarantee type safety in your program. With reflection, the compiler wont be able to see certain problems, but your customers might! type members => No real equivalent, to rewrite Scala that uses type members would likely involve a massive refactoring Again, working with Object instance and reflection is another possibility type inference => Used excessively, inferred types may make it hard to spot certain information that could help someone understand a piece of code. If this is a real possibility, then the option to specify a type is always available. By comparison explicit types cause a great deal of boilerplate (hence the new diamond operator) and are basically impossible to avoid, although some inference is available for factory methods, and used to great effect by libraries such as Google Guava. type aliases => A nice intermediate solution between inference and full typing. By defining `type Grid = List[List[Int]]`, you can avoid the boilerplate of repeatedly stating that type signature, but you can still specify `Grid` as a parameter or return type if you want to make something explicit. The only Java alternative is to specify types in full, whenever they're used. Scala certainly has a higher-level feature set here, and this can easily look scary and complex if you're unfamiliar with a particular feature and how best to use it. >From this perspective, parts of Scala *are* more complex than Java. If you can write any program you want in Java without these features, why add them? Isn't it just more stuff to learn? Scala is more complex. But what If you're familiar with Scala? If you're happy and familiar with all the features that Scala has. In this case you perceive problems/solutions in terms of this richer feature set and you have to have to translate your mental model when writing Java code. Every missing feature will have to be written by you, it feels like added boilerplate; extra lines of code that you just *know* a different compiler simply doesn't need. Worse still, you may have to refactor your model to use a different feature-set (e.g. visitors instead of pattern matching), that's more work at the design level PLUS a ton of extra code to be written. From this perspective, Java becomes the more complex language. And this is the crucial observation... In order to achieve the second viewpoint, you must first learn and use enough Scala to start thinking in terms of idioms that are based on higher-kinds, implicits, immutability and first-class functions. Perhaps this is why Martin advocates Scala as a language for those who are willing to learn? On 29 September 2010 14:53, Casper Bang <[email protected]> wrote: > Listen, no matter the amount of failed analogies and argumentation > logic we pull into the conversation, the original issue still stands: > Scala goes too far and is too complex to appeal to the average > developer. > > Even from the horses' own mouth "The programmers we want to appeal to > are the expert programmers" and "...over time there will be enough > teaching materials and enough good tools to also make Scala appeal to > more average programmers. But that's not what our immediate aim is..." > suggests that there is some truth to this. I am out of this > conversation, it's the never-ending story - Scala edition. > > On Sep 29, 3:09 pm, Nick Brown <[email protected]> wrote: > > At the risk of sounding like a troll, while not being a Scala fan is > > not a mark of a bad developer, I would say a poor grasp of logic > > skills is. > > > > A conditional statement being true does not mean its inverse is also > > true. "If A then B" does not mean "If not A then not B". The > > converse ("If not B, then not A") is, but not the inverse. Consider a > > math example, "If a number is divisible by 6 then it is a composite > > number", I'm sure you will agree is true. But the inverse, "If a > > number is not divisible by 6 then it is a prime number" is clearly > > false, even though composite/prime are complementary. > > > > Similarly, "If someone is interested in Scala, they are a good > > developer" (which isn't what Odersky said, but lets pretend it was > > since that's what everyone apparently thinks he said) does not > > logically imply "If someone is not interested in Scala, they are not a > > good developer". > > > > On Sep 29, 8:20 am, Casper Bang <[email protected]> wrote: > > > > > > > > > Sure it does, "good" and "bad" are complementary, there is no other > > > atomic/terminal state. Obviously there are MANY alternatives to > > > "blue". > > > > > On Sep 29, 3:26 am, Josh Suereth <[email protected]> wrote: > > > > > > I don't think logic works that way. > > > > > > That's like saying, of a box of colored shapes: "Some of the box-like > shapes > > > > are blue" implies that "All non-box-like shapes are not blue" > > > > > > On Tue, Sep 28, 2010 at 7:29 AM, Casper Bang <[email protected]> > wrote: > > > > > So by inference, people who are not convinced by Scala, are > inferior > > > > > developers unwilling to learn? > > > > > > > On Sep 28, 11:55 am, B Smith-Mannschott <[email protected]> > wrote: > > > > > > On Tue, Sep 28, 2010 at 10:51, Vince O'Sullivan < > [email protected] > > > > > >wrote: > > > > > > > > > On Sep 28, 9:23 am, Kevin Wright <[email protected]> > wrote: > > > > > > > > An important trait of being a good programmer is the > willingness to > > > > > learn > > > > > > > > and push the boundaries of what can be done well. That's also > why > > > > > Scala > > > > > > > is > > > > > > > > quite suitable for new programmers, including children and > students. > > > > > > > > > There's no logical connection between those two sentences. > > > > > > > > The logical connection is "willingness to learn". Presumably > students are > > > > > > willing to learn. "Good" programmers are also willing to learn. > (Or would > > > > > > you argue that they are not? Or perhaps that all programmers have > the > > > > > same > > > > > > level of skill and interest?) > > > > > > > > // ben > > > > > > > -- > > > > > 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]> > <javaposse%2bunsubscr...@googlegroups .com> > > > > > . > > > > > For more options, visit this group at > > > > >http://groups.google.com/group/javaposse?hl=en. > > -- > 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 / gtalk / msn : [email protected] pulse / 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.
