Hm :( that was supposed to be a private reply. Apologies for that. On Sep 29, 10:59 pm, Reinier Zwitserloot <[email protected]> wrote: > 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.
