You've got quite the balls to post yet another rehash of the "scala is simpler" argument after Dick Wall's plea. Stop it.
On Sep 29, 8:47 pm, Kevin Wright <[email protected]> wrote: > 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%2bunsubscr...@googlegroups > > > > > > .com> > > <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%2bunsubscr...@googlegroups > > .com> > > . > > 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.
