Maybe it's useful to read Paul Graham's essay<http://www.paulgraham.com/avg.html> and for the ones that got convinced Steve Yegge's<http://steve-yegge.blogspot.com/2006/04/lisp-is-not-acceptable-lisp.html> .
I think it might put some water on language wars.... On 3 August 2010 18:28, Dick Wall <[email protected]> wrote: > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
