What I'd like to see is this put to rest. Who cares if everyone or anyone
adopts Scala. I'm doing just fine with Java right now and will be for some
time to come. I have picked up some Groovy, tried Grails, am going to play
with Lombok next, and like many others will get around to Scala when I am
good and ready.
People don't like help forced on them. When they want the help, they will
come looking for it. I think that is for another group though, probably the
scala forums? Perhaps your questions and research would be better performed
there?
On Wed, Sep 29, 2010 at 7:41 PM, Kevin Wright <kev.lee.wri...@gmail.com>wrote:
> I'm sorry you felt that to be the case. I was in no way seeking to be
> negative or derogatory in the slightest!
>
> The goal was just to summarise the different viewpoints as I understand
> them, in the hope that I might offer people some small understanding as what
> motivates and shapes the perceptions of a Scala developer.
>
> I also attempted to explain why I believe some people feel the language is
> to complex. In the full expectation that someone can come along and
> successfully challenge that belief. If you think I misrepresented your
> objections then, please, explain the flaw in my logic.
>
>
> To that end, I isolated the two separate themes that I've seen emerging:
>
> 1) That there is a recognised need for improvement to Java, and that Scala
> offers all of the improvements frequently asked for, this is generally
> accepted by all.
> 2) That Scala goes above and beyond this. The debates are clearly centred
> in this region, with opinions varying from "scary/unnecessary/complex" to
> "simple/elegant/typesafe/can't live without"
>
> By taking point #1 for granted, perhaps we can focus more effectively on
> the deeper issues at hand.
>
>
> What I'd like to see here is a real opportunity for people to not be scared
> about exploring Scala, and likewise for Scala devs to better understand what
> features are considered scariest by newcomers to the language. This is
> important, as it can help us all in writing tutorials to better promote
> understanding, and to temper our coding conventions and APIs so that they'll
> appear less threatening. Not just in Scala, but in any library or language.
>
>
> On 29 September 2010 21:59, Reinier Zwitserloot <reini...@gmail.com>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 <kev.lee.wri...@gmail.com> 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 <casper.b...@gmail.com> 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 <nwbr...@gmail.com> 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 <casper.b...@gmail.com> 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 <joshua.suer...@gmail.com>
>> 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 <
>> casper.b...@gmail.com>
>> > > 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 <
>> bsmith.o...@gmail.com>
>> > > wrote:
>> > > > > > > > On Tue, Sep 28, 2010 at 10:51, Vince O'Sullivan <
>> > > vjosulli...@gmail.com
>> > > > > > > >wrote:
>> >
>> > > > > > > > > On Sep 28, 9:23 am, Kevin Wright <
>> kev.lee.wri...@gmail.com>
>> > > 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
>> javapo...@googlegroups.com.
>> > > > > > > To unsubscribe from this group, send email to
>> > > > > > > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
>> <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 javapo...@googlegroups.com.
>> > > To unsubscribe from this group, send email to
>> > > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
>> <javaposse%2bunsubscr...@googlegroups .com>
>> > > .
>> > > For more options, visit this group at
>> > >http://groups.google.com/group/javaposse?hl=en.
>> >
>> > --
>> > Kevin Wright
>> >
>> > mail / gtalk / msn : kev.lee.wri...@gmail.com
>> > 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 javapo...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>>
>
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wri...@gmail.com
>
> 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 javapo...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
--
Robert Casto
www.robertcasto.com
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
