Hi Martin
It is not my intention to get into a tit-for-tat, but I do think this
illustrates a few good points about Java that we have all just come to
accept, but which appear to be crazy from an outsiders viewpoint:
> object Main {
> def main(args: Array[String]) {
> [...]
>
> and
>
> object somestuff extends Application {
> [...]
>
As people have already mentioned, the Application trait was an idea
that did not pan out - for those interested the real failure is that
it prevents the hotspot JIT doing its work properly, which is the
reason it has been deprecated (at least from recommendations).
However, I don't think you can blame people for trying stuff out,
especially (and this is one of those crazy Java cases we have all just
come to accept) the Java alternative is:
class CalculateResults {
public static void main(String[] args) {
....
}
}
Yes - this looks familiar to all of us, but really, you should see the
look in beginners eyes when they see this for the first time. We are
just used to some crazy (and incomprehensible) stuff. You can't blame
folks for trying to improve that, after all from an end users
perspecitive
object CalculateResults extends Application {
...
}
would be a lot easier to explain to someone new. It's just a shame it
had a technical flaw when used on the JVM.
> (I have seen 5 ways to write the same simple stuff in other cases
> which I unfortunately can't recall now - just ridiculous it was!). It
> is hard enough to read others code, but such things makes it worse.
>
> 2. Readability
> No, this is not (just to give one example):
> val elems = args map Integer.parseInt
> println("The sum of my arguments is: " + elems.foldRight(0) (_ + _))
>
I can see why this was presented in this form, since .sum is just one
operation, while foldRight, reduceLeft, etc. can be used for any kind
of operation, but even then a reduce instead of a fold would have made
things more readable here (once you know and are familiar with this
syntax, it can be used very flexibly, and incidentally with my hand on
my heart, the above reads just fine to me and is very understandable -
it probably took me a couple of months to get comfortable with the
underlying concepts, but this is not tricky to read once you have that
familiarity).
On the other hand, an easy counter example is this:
Arrays.sort(list, new AlphabeticComparator());
...
class AlphabeticComparator implements Comparator {
public int compare(Object o1, Object o2) {
String s1 = (String) o1;
String s2 = (String) o2;
return s1.toLowerCase().compareTo(s2.toLowerCase());
}
}
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. 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, but then you have the generic syntax to layer
in on top of things as well, and this does little to increase the
signal to noise ratio. Yes, I should probably have @Override in there
too for Java 6, etc. etc.
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)
which basically tells the sort command to use the lower cased form of
each of the items to sort by - a common case for a sort is to choose
an individual property of, or a function on, the item to determine
order, like in this case. I would argue that either of these two
examples is way easier to read than the Java versions. You even get
code completion in the IDE for the innards of the sort functions,
since Scala infers the typing all the way through.
The point is that there is plenty of scary stuff in Java - anonymous
inner classes being a superb example, and yet people hold it up as the
simpler choice. The truth is that a large part of that is simply
familiarity, or "better the devil you know".
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, and new features will
experience the kind of combinatorial complexity explosion that keeps
new features that might make life better from being added to the
language. 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.
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. I would like to see code completion for named
parameters, but I suspect even that will come in time.
> 3. Functional approach
> I could never get warm with functional programming, Scala does not
> make a difference here.
>
> YMMV.
>
> > There are definitely features (like Higher-kinded types) that are pretty
> > complex but they can also offer incredible elegance and functionality
>
> I am also thinking about the younger people coming after me. One of
> the major problems I often hear is that it is difficult to find new
> developers (and we experienced as well). When I faced the last time
> apprentices getting into programming, I could not even believe that
> one needs to learn what a loop is. If you ask me what language I want
> them to use then I would never ever give them Scala, because it is
> completely overwhelming for them! Java still is, but much better IMHO!
The sort example above is a higher order function, both in Java and in
Scala. A higher order function is simply a function that takes and
defers to another function internally, as is the case with Sort (it
defers to the Comparator which tells sort how to compare two values
and tell which is larger or smaller). This leads to a much more
elegant solution for sorting, and many other uses. You don't
necessarily miss it until you have had it, but don't underestimate its
usefulness.
>
> > Tooling does *not* compensate for boilerplate
>
> I never ever read about the boilerplate issue before listening to the
> Java posse. Seriously!
I can't comment on this, other than to be a little surprised. I
figured most people have got tired of writing getters and setters,
equals, hashcode, anonymous inner classes, etc. by now. It's so much
faster and more fun when you don't have to.
>
> > C++ is also too Verbose
>
> ROTFL! You lost me here.
>
> > Yes, Scala has issues.
> > It may be less necessary, but Scala IDE support still needs to improve if
> > the language is to gain wider acceptance
>
> A major issue for me and...
It really is getting there - give Scala 2.8 and NetBeans 6.9 a go, or
the eclipse Scala IDE, or IDEA (but make sure it is Scala 2.8). Also,
take a look at the Scala 2.8 REPL (the interactive shell), which has
tab completion built in now as well - very useful for just trying
stuff out.
> Martin Wildamhttp://www.google.com/profiles/mwildam
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.
Dick
--
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.
