Java, C#, and F# recommended by the ACM for SEC regulation spec language. No mentioning of Scala [because it's complete esoteric nonsense?]: http://is.gd/e49Vt (PDF)
/Casper On Aug 4, 7:23 am, Wildam Martin <[email protected]> wrote: > On Tue, Aug 3, 2010 at 18:28, Dick Wall <[email protected]> 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 Wildamhttp://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 [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.
