On Tue, Aug 3, 2010 at 18:28, Dick Wall <dickw...@gmail.com> wrote:
> or doing it with anonymous inner classes:
>
> Arrays.sort(list, new Comparator() {
> public int compare(Object o1, Object o2) {
> String s1 = (String) o1;
> String s2 = (String) o2;
> return s1.toLowerCase().compareTo(s2.toLowerCase());
> }
> });
>
> You need to try seeing this through the eyes of a room full of Java
> virgins - as I did many times at Google working as an Android
> Advocate.
Yes, you are right, this is a similar annoying example from the Java world.
And at this point I remember that in the initial times I found that
hard to read also.
> This is just a ton of noise that threatens to completely
> obscure the intent of the code. Yes, often things like the casts can
> be removed via generics,
Oh, and for the generics it took me a good while to understand.
> Now take a look at the same thing in Scala:
> val list = List("Hello", "very", "nice", "World")
> list.sortWith((s1, s2) => (s1.toLowerCase < s2.toLowerCase))
>
> and yes, you have an alternative here as well, you just need to
> understand what you are doing, but the alternative is:
>
> list.sortBy(_.toLowerCase)
Oh, and this is again such a point, where I really don't know which
one I should choose for an implementation. I really can't easily
figure out, which way is faster or more readable or more "Scala-like"
or ...
> I would argue that either of these two
> examples is way easier to read than the Java versions.
Although annoying and more to write I still prefer the Java version -
anyway, such things as comparators I only need very seldom and I
veeery rarely use anonymous classes.
> Java's binary backwards compatibility has been it's own curse as well
> as reward. We still have artifacts in the language that have pretty
> much been accepted to be a bad idea, but 100% backwards compatibility
> means that they will continue to be there
I think, there could be things safely dropped that are depreceated
since Java 1.4. I personally have not seen something below 1.4 in the
last years and everyone using something below, I guess is anyway not
going to update to 1.6 or later. And BTW: ASFAIK you can have several
java runtimes and an application might use a particular one (just as
solution for the veeeery old stuff).
> It's a double edged sword. If you really need the features
> of an older version of the language, why not just use the older
> version? With Scala, this is even de-coupled from the JVM, so you can
> still benefit from JVM improvements while using an older version of
> the language - Python has done very well with this model.
I think there is a difference in dropping things that are depreceated
since a veery long time or breaking things from one version to the
next maybe without either making it depreceated before.
Microsoft had it the same way in the early days of .net - different
programs needed different version of .net and there were
incompatibilities. Customers needed plenty of runtime versions, more
memory and disk space and things went slower and developers could not
immediately gain from new features by upgrading because they would
have need to change existing code.
Even Microsoft switched to compatibility strategy.
> Finally, I would urge anyone complaining about the tooling to give
> Scala 2.8 a try with some of the new IDE integrations. I have to say
> that for me, NetBeans 6.9 squeaks slightly ahead in this arena than
> the others, but they have all got much better with 2.8. There is still
> room for improvement, but NetBeans even offers some refactoring
> support now, has great code completion, syntax coloring that is far
> more extensive and informative than that for Java code, and the
> debugger works great.
Oh, I just recall that I had syntax coloring in VB already in 1998 (or
even earlier) and now in Java there is not really much of it (at least
by default).
> I would like to see code completion for named
> parameters, but I suspect even that will come in time.
That is something I like very much in NetBeans because then I can use
longer and better speaking variable names more often (because less to
type with the autocompletion).
> Above all, keep learning. Scala is just one new thing to learn, and
> not the only one, so if not that, give something else a go - but I
> believe it will expose you to new ideas. Developers should keep
> learning - it's a healthy sign.
Of course I keep learning. But learning a new language seriously (for
day-to-day use) takes a lot of time. I do this only once in 10 years
or so and as I have gone Java only about two years ago (when Scala was
not even worth taking a closer look). My daily job involves still
legacy development for Windows only, customer support, consulting etc.
At home waiting wife with two children. Besides that I also gone Linux
and do testing and bug reporting. Basically I don't have the time to
learn something just for fun. When I learn a new programming language
it must be by aiming to use it on a daily basis in the near future. I
am not yet convinced that Scala would be the next big language for me.
--
Martin Wildam
http://www.google.com/profiles/mwildam
--
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.
