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 - 21: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 - 22: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 - 17: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 - 12:45
Scala, scala actors
Type safe actor messages

 One of my pain points with the actors library is how to handle replies to a message. The library provides the methods ‘!?’ and ‘!!’, but without type safety. Client code needs to cast the reply to the expected type:

 

ittayd 23/05/2010 - 10:50
Scala, scala actors
Scala actors design patterns - part 1

 This post is one of (hopefully) a series of design patterns for actor based programming. If you don’t know what an actor based programming is, see http://en.wikipedia.org/wiki/Actor_model. This post and the next will be focused on developing in Scala, using its standard actors library.

Many times, working with actors involves a request-response cycle. For the context of this post, imagine a UniversityRegistry actor. The actor can register students, assign them to classes, whatever. One of the things we may want in such a system is to query for the state of a student. To do that, we can send a message Query(id) and expect a response with the student details.

 

ittayd 13/05/2010 - 10:11
Scala, scala actors
Functional Programming

Functional Programming (FP) was one of the issues we went over during the Scala demo I gave last Tuesday.

The resolution of that discussion was't to my satisfaction, not to mention following community entries that may picture FP as a concept that is open for personal interpretations. So, following are some clarifications about FP and its place in Scala.

 

Functional Programming:

adi 17/12/2009 - 15:36
Haskell, Programming Languages, Scala
scala performance

Since version 6 update 14, the JVM has a feature called escape analysis: http://java.sun.com/javase/6/webnotes/6u14.html#hotspot14.0-G1-6u14. If the JVM sees that an object is created just for the scope of a single method (e.g., StringBuilder), it can decide not to create it and instead use the fields as local variables.

 

This is good for Java, but especially for Scala, since many of Scala's features are implemented by creating wrapper objects (implicit conversions, call-by-name). Performance improves from 11% (http://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/). Some people suggest a 25% improvement in performance

ittayd 16/11/2009 - 11:18
jvm scala performance, Scala
To Scala or not to Scala?

I heard today I'm considered an advocate of Scala for a client I'm at. I came across Scala in 2006 and was at first very excite about it, but decided not to keep with it, so I thought I'd share my view of the language.

 

So, why should you choose to use Scala:

  • It is a type-safe functional language with nice syntax. There are languages (Ruby, Python, Javascript) that are functional, but not type safe. There's Functional Java but code becomes very cluttered with template parameters.

  • Functional programming makes some code a lot shorter. You can google for many examples. For a short example, in Scala I can write

ittayd 27/10/2009 - 23:38
Scala
Asynchronous Servlets – Jetty continuation

Here are 2 useful links which explain this feature and have some examples:
http://wiki.eclipse.org/Jetty/Feature/Continuations
http://docs.codehaus.org/display/JETTY/Continuations : see How it works section.

I use the eclipse version org.eclipse.jetty --> jetty-continuation in one of my client's projects and find it a very useful, powerful and reliable.

You can manage: timeouts, suspending a request, completing implementations, resuming a request, initial phase, adding continuation listeners or just handling the requests in a simple servlet without listeners and only by checking isComplete,isInitial etc...

oded 23/08/2010 - 18:01
Asynchronous Servlets, Asynchronous Servlets, Java, JettyContinuation, JettyContinuation, Scala, threading
Syndicate content