Scala

Thoughts about Coda's Scala mail

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:

ittayd 30/11/2011 - 19:06
Scala, Scala
Why Scala seems difficult but really isn't

Here is a short article, discussing some reasons, why Scala may seem more complicated than it is to beginners.

 

I think, the most important item is the show-off factor. Not only in blogs, but also in code people try to demonstrate the most advanced Scala feature they learned recently.

 

For example, Scala creator Martin Odersky defines the lazy vals as a part of a library level. Yet, I saw a pure business logic code using lazy vals overrides to create a subclass polymorphism.

 

andrew 18/08/2011 - 10:03
Incubator, Java, Scala
Simulating SAM closures in Scala

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

ittayd 24/05/2011 - 10:13
sam scala, Scala
Creating Java API in Scala using @bridge

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.

 

ittayd 17/05/2011 - 14:09
Scala, Scala
Enough with the abuse of Scala for internal DSLs!

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.

 

ittayd 20/01/2011 - 13:36
Scala, Scala
Monads - Functional IoC pattern for Scala

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.

 

ittayd 03/10/2010 - 10:10
Scala, Scala
The simpler parts of Scala

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:

ittayd 02/09/2010 - 20:33
Scala, Scala
Avoiding Nothing

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:

ittayd 05/08/2010 - 21:59
Scala, Scala
Asynchronous functions, actors and CPS

Using  Scala we can easily create lock free multi-threaded code, while still maintaining a familiar programming model.

 

There are two issues of writing multi-threaded code: synchronizing shared access to resources and running code asynchronously. In Java this is usually done with locks and implementing interfaces that wrap the asynchronous code. This leads to code that is cumbersome to write, error prone and inefficient in how it uses threads (since a thread may block for an unspecified time waiting on a lock).

 

In Scala we have actors (of course there are actor libraries for Java also, they are just less popular).  However, using actors means giving away on type safety (we cannot know the exact set of messages an actor handled) and is also cumbersome to use as a replacement for method calls.

ittayd 06/07/2010 - 16:53
cps scala actors asynchronous, Scala
Scala actors design patterns - part 3

 Actors process messages one at a time. But what if processing a message is a read-only process? Why not be able to process them simultaneously?

 

I’ll first show a direct implementation of the pattern and then a trait that can be reused.

 

First, assume we have 2 messages  for that stand for a read operation and for a write operation (the parameter i is used for print-debug to keep track of what message is processed):

 

case class Read(i: Int)
case class Write(i: Int)

 

ittayd 27/06/2010 - 11:45
Scala, scala actors
Syndicate content