Coda Hale is Yammer's infrastructure architect. Yammer is moving their infrastructure code from Scala to Java. Typesafe's CEO (the company founded by Scala's creators) asked him for his reasons and his email was made public by mistake. Read more here

I've worked for 2 years now in on a complex scalable service exposed via web-service created in Scala and my experiense was very different. Here are my thoughts.

First, to summarise the main points of the email:

Whoever tries to learn Scala immediately encounters talk about Functional Programming.

The first step is having functions as first-class citizens. This opens up new ways of programming, and the Scala collection library if far superior to Java's because of it. There are many examples of how boilerplate loops of creating and populating new collections can be replaced by a succint one liner of using `map`.

In this post I'll try to explain the more advanced concepts of Functors, Applicatives and Monads. I'm doing it starting from everyday OO and building the API and the implementation as we go along.

(Note: This paper was not easy to write and may still be confusing despite my best efforts. I would love to hear your thoughts and suggestions in the comments, or through twitter: @ittayd)

SAM closures are a way to create an implementation for an interface with a single method easily.

In Java, creation of such interfaces requires the use of annonymous classes.

In Scala, we have functions.

But first, why create a single method interface if you can use a function? Well, there are two reasons I can think of:

1. Typing: if a method accepts an argument of type SAM, then it is is easy to see who extends this type with concrete implementations.
2. It allows to add more methods to the interface later on. Sometimes a new feature requires adding a method (maybe overloading) to the interface

Here is how one can simulate SAM closures in Scala:

In SAM.scala

Here is the presentation given at our last event about moving from Java to Scala.

The presentation show how Scala can be used instead of Java to get more concise and modular code gaining productivity and maintenance advantages. It use a simple Android application to show the transition. It touches simple Scala features that make us more productive as well as more advanced ones that make our code better.

 Here's the original presentation:

Someone asked me today how to write a service so its API can be used from Java. His problem is that he is using Scala's collection classes but it is not possible to use their methods from Java. This is because when using some features of Scala, the encoded method has a name that is not legal in Java (using '$' in particular).

For example:

trait API {
  def service: Map[String, String]
}

If we call the method 'service' from Java, there's very little we can do with the result.

The common wisdom is to create an adapter class that exposes Java consumable classes. Say, create a JavaAPI interface and JavaAPIImpl. This is very tedious and also tends to become very verbose since if another API interface returns our API interface it also requires wrapping so it will return a JavaAPI interface.

I just read a comment in reddit where someone explained that Scala's feature that allows "subj.method(obj)" to be written as "subj metohd obj" is for writing DSLs.

(Disclaimer: I don't know what were Martin Odersky's exact reasons for adding this feature)

For me the primary reason is not DSLs. It is the simple fact that it makes the language more consistent. In Java, you can write 'x + y', but this is allowed only for special types (primitives and string). This is inconsistent. In scala, 'x + y' is allowed for all types.

The 'ALM Retrospective' presentation we did in our last TCE.

This post is not yet another introduction to Monads. In fact, I hesitated whether to use the term in the title. Eventually I did, so I wouldn’t get comments that the article is in fact about Monads. It is, but not for the reasons most articles are about.

I want to discuss the design pattern that they offer. That is inversion of control between values and functions. Usually we think as values being the arguments to functions. But if we switch things around, making functions the argument of values, it can help make some code more concise and clear. It helps to model different code flows than foo(bar(car()))

Since I mentioned the word Monad, I need to give some kind of introduction. It is very superficial. I will then follow with some examples.

There's a constant discussion about Scala being a complex language. In this post I'll try to show the simple parts of Scala that make coding easier.

My favorite article about why Scala is not complex is by Martin Odersky, the father of Scala: http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html. But there's one problem with it, it appeals to those already in favor of Scala.

I think Scala *is* complex. Some due to the functional concepts that are foreign to the Java world, some due to the requirement to work inside the JVM (and CLR). In fact, I was against Scala since 2006, because then I tried to learn it and found the syntax awkward. I recently had to start using it because a client required me to and haven't looked back since.

Ok, so now to the actual post, why should you use Scala: because some parts of it make programming easier even for novices:

Sometimes Scala's compiler will infer the type Nothing for a generic type parameter which may cause an error during runtime. I show here a simple way to avoid that.

The method follows the strategy in http://github.com/harrah/up/blob/master/Contains.scala (which presents a more generalized way of declaring type parameters which are required or excluded). The strategy is to cause an ambiguity for the compiler when Nothing is used which will cause it to error.

First, a use case: Say I want to make working with Maps that contain multiple types a little easier, for example, working with a Map[String, Any]. Insted of a user needing to call map.get(key).asInstanceOf[Option[MyType]] , I want a method like map.getAs[MyType](key). The code: