cbrad

Just a quick comparison of F# Option orElse getOrElse functions in Scala. Given orElse and getOrElse are already defined in Scala, the equivalent code is:

def f(s:List[(Int, Int)]) = {
 def tf(g:Int => Boolean) = s.find {case (_,x) => g(x)}
 tf(_ < 0) orElse tf(_ == 0) map(_._1) getOrElse 10
}

The argument to orElse is defined as lazy in the function declaration via : => Option[B] rather than :Option[B]. However in the F# version, the actual argument type is changed from 'a option to 'a option Lazy.

I can honestly say if someone had shown me the Programming in Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.

- James Strachan

From Scala as the long term replacement for java/javac?

[埋込みオブジェクト:http://www.ustream.tv/flash/video/1610777]

Speakers: Martin Odersky (EPFL), Nick Kallen (Twitter), David Pollak (Lift)

Martin gives a good overview of who is using Scala, where it came from and where it is going in the first 16 minutes.

Throughout the video, Nick provides the most plausible comments I have heard to date regarding Twitter's motivation/experiences in moving from Ruby to Scala.

Java is the Brier Rabbit of IT. Once touched you can't let go. Its simplistic enough to be inadequate in almost every situation.

From The Book Of JOSH - Scala In The Enterprise

Back in December Greg Luck asked me to do a Scala example of accessing Ehcache, to fit in with the code samples on their site. Yesterday I finally got around to looking at it and Greg has now posted it on his blog.

My goal was not to write the perfect example. I decided to do something to fit in with the style of the existing Ruby code sample, which just prints the response of a HTTP GET to a fixed URL. Given that this is the sole purpose of the program, I didn't see the point of explicitly handling exceptions or closing network connections.

I couldn't find a HTTP client library written in Scala, so rewriting the Java code sample would basically be a thin veneer of Scala syntax over the Java libraries. Too much time for little value.

I must admit that I had the total number of lines of code in the back of my mind, simply because the other samples, apart from the Java one (which does more) are all short and people will notice this. Personally I think this emphasis on short LOC, considered in isolation is misguided.

For me, the expressiveness of a language is more important, i.e. the ability to express abstractions and properties that matter (or perhaps should matter). Assuming that it is possible to express a particular concept in a language, the next question is how easy it is to do so and LOC/number of characters are aspects of this.

Here is my simple Scala program:

import java.net.URL
import scala.io.Source.fromInputStream

object ExampleScalaGet extends Application {
 val url = new URL("http://localhost:8080/ehcache/rest/sampleCache2/2")
 fromInputStream(url.openStream).getLines.foreach(println)
}

I see three meaningful language features utilised (apart from static typing):

• Easy definition of an immutable value. The keyword val on line 5.


• Type inference. The type of the value url is not explicitly annotated in the code, but inferred at compile time.


• Easy use of higher order functions. foreach on line 6, takes a function as its argument.

Workingmouse is running an Introduction To Scala training course from Tuesday 2nd September to Thursday 4th September. The course will be run in an interactive, "hands-on" format, with a small number of people, ideally between 4 and 8.

The course covers topics including:

• Scala syntax


• A brief introduction to the essence of Functional Programming


• Algebraic Data Types and Pattern Matching


• Closures and Higher-Order Functions


• Integration with Java


• Intermediate Functional Programming topics (if time permits)

Yesterday, Paul Cormier, Executive Vice President and President, Products and Technologies, Red Hat gave a talk titled "Red Hat and the Open Source Software Business: from boxed software to a half billion dollar server company" at QUT.

Paul made two points that stand out in my mind:

1. The primary differentiator of an open source project software project (compared to closed source) is in the ability to build a community of people around the project.


2. He sees Red Hat as taking open source work and packaging it in a way that is palatable from an enterprise perspective. Specifically, providing stability and backward compatibility for a 'long-enough' period of time.

If I consider Scala in this light, it is currently doing well on the first point, but not so well on the second. Given that the primary users of Java are enterprises, this is important if mainstream penetration is an objective.

Having said that, I think there is a time when the cost of backwards compatibility outweighs the benefits and my threshold seems to be a fair bit lower than that of the average enterprise. In this case, I think enterprises would do well to step back and consider the real costs in doing a software project in Java (or Ruby/Groovy for that matter) and seriously consider the potential benefits from more advanced programming languages.