There’s no average, dumb Java Joe!

Wow, it’s been quite a long time since i’ve blogged the last time (that’s for the one or other reason that would only bother you, so in essence – please excuse) . But now i can’t keep calm any longer, since there’s an increasing number of articles, claiming that e.g. Functional Programming – in particular using Scala – is too hard to get for the average programmer.

First of all,  there isn’t any ‘Java Joe’  (as a synonym for all those so called ‘dumb’ Programmers) out there. Well ok, if it is, then i’m the ideal protoype of that Joe! And as such  i can tell you, if you’re willing to learn some new ideas and try to improve your programming skills, than Scala may provide you with a bunch of whole new concepts, not only from the functional world (and i’m not even talking about type systems here).

In fact, i don’t care if it’s Scala, Haskell or any other language, as soon as it may widen my horizon. But i would answer to all those who think Scala is to hard to grasp, that it’s only a matter of how you would pick up those persons. Granted, it may be difficult to meet those ‘newcomers’ at their common ground – there are some complaints out there that some Scala community members might behave too elitist when it comes to blaming Scala as being too difficult (like ‘it’s not Scala which is too difficult, it’s only you who don’t understand it’).

Frankly, i can follow those complaints. If you’re willing to learn and may have some problems to grasp some blog posts about Scala (or any other language) or even some code snippets, it is by way no solution to retreat to a position, saying your just to dumb (or lazy or whatsoever) to get it. Spitting out some code snippets or short articles everey now and then is easy – especially if they come without any context or any larger explanation. That’s really the easy part! The hard part is meeting that so called average Java Joe at his level and escort him intellectually!

So as a community of Scala fellows (or in any other way), we need to stop  judge over those large herd of programmers as being too dumb. That’s simply not true! There may be some individuals too sluggish to learn and excel. But for all those others, who may have a hard job and having no chance to deal and become proficient with Scala at day (and therefore have only some hours at night) , we need to provide a way of guidance. And that’s best done to face that before mentioned reality. It’s not the people who are dumb. We as a community are dumb if we don’t react to that reality and welcome those people on their ground!


In order to walk the talk, i decided to resume my work on writing about functional Scala! Hopefully some may still find it a useful intro to get into the ideas of functional programming in Scala.

Functional Scala: Functions

Welcome back to the second episode of Functional Scala!

After we’ve checked out some core ideas and extracted Expression based function application as the basic computation method of Functional Programming within the last episode, let’s start with what Dr. Erik Meijer* would call the bread and butter of Functional Programming: and now guess what … it’s surprisingly about … Functions (please imagine a chorus of trumpets in the background while reading this).

In order to call a Function (it is said to apply a Function to its arguments), you firstly have to define one. So let’s get a feeling about how to define Functions in Scala … Read the rest of this entry »

Functional Scala: Introduction

Welcome to the first part of a series of episodes about ‘Functional Scala’. While positioning itself as a so called object-functional language, most of the discussion and articles about Scala centered around its object oriented features so far. If you’re reading this, chances are you want to learn more about the functional side of Scala. Well, you’ve come to the right place. Read the rest of this entry »

Scala in practice: Composing Traits – Lego style

As a kid, i loved to play with Lego bricks, especially to build freaky spacecrafts.

spacecraftAt that time it was easy to let my phantasy go (where noone has gone before) and build completely new models simply by composing some standard bricks. Those bricks weren’t too specialized, meaning that there weren’t too many constraints on how to combine them. On the other side you always had to compose a new spacecraft from the very ground up as there weren’t some more higher organized units like engines or control cabins.

Nowadays, you’ll find such units. There are engines, control cabins or a whole commando bridge, Wings, Field Generators and so on – a whole set of higher organized units whithin a single domain. On the other side, you can’t combine every unit with an arbitrary other unit within that domain since there are some ‘constraints’  that will prohibit some unsound combinations.

Now you may ask how that cute childhood story relates to Scala?
You may have seen already some similarities to the field of software development where you also want to compose some higher organized building blocks within a certain domain, enforcing that they are only combined in a proper way. It turns out, that Scala’s concept of traits provide some mechanisms of ‘mixin’ them together while enforcing the compliance of some constraints. This may sound too abstract at that point, but hold on – we’ll build some spacecrafts in the above mentioned way and things will get clearer.

Look, it’s a spacecraft

Let’s start with a hull for our spacecraft. To keep things simple and to focus on the core idea of constrained
composition, the spacecraft’s hull will only provide one abstract method engange to start the craft:

abstract class Spacecraft{

    def engage

As you can see, method engage and therefore the whole class is abstract, so you can’t instantiate a pure hull
of a spacecaft. So whenever we want to build a full fledged craft, we may have to ‘add’ (or mix in) a component
that knows how to engage that craft.

Captains place

Typically, a spacecraft possess a kind of ‘control center’ which is normally well suited for initiating the
start of a craft, hence should provide an implementation for method engage. There may be different kinds of
control centers that could be used for building your own, customized spacecraft – e.g. a whole commando bridge for
those big deep space crafts or a small control cabin for those little crafts mainly maneuvering near the orbit.

 trait CommandoBridge{

def engage { for( _ <- 1 to 3 ){ speedUp } }

    def speedUp

Now we see what it means to engage (a Spacecraft) if composing a commando Bridge to the hull. We simply speed up that craft 3 times.
But hold on – although we know what it means to engage that craft, speeding up that craft is not in the responsibility of the commando bridge, since speedUp is left abstract (speeding down is omitted since it follows the same mechanism – you get the idea).

Re-calibrating all Dilithium crystals

So the spacecraft seems to be incomplete without a unit to speed it up – let’s call such a unit ‘engine’.  Again, there may be different kinds of engines we could select from to assemble our craft.
Let’s say there is a Pulse-Engine that directly supports the command of speeding up:

trait PulseEngine{

    val maxPulse: Int

    var currentPulse = 0;

    def speedUp { if( currentPulse < maxPulse ) currentPulse += 1  }

As you can see, a PulseEngine is able to speed up until a maximum pulse rate. In order to ‘produce’ different pulse engines (supporting different maximum pulse rates for different types of crafts), the field is again left abstract.
Now we could create our first spacecraft, using a commando bridge and a pulse engine (let’s say that’s all you need for building a full fledged spacecraft).

class StarCruiser extends Spacecraft with CommandoBridge with PulseEngine{

    val maxPulse = 200

As you can see, we’ve created a new (Sub-)Type of a spacecraft and mixed in both Traits, obtaining a commando bridge (that knows how to engage the whole craft) and an engine (that knows how to get the craft into speed when engaging the craft).
The only thing left is to define the maximum pulse rate our StarCruiser is able to achieve.


In the above case, all units fitted together smoothly. For example, a pulse engine provided exactly the ‘interface’ (speedUp) that was needed by a commando bridge, so you could compose both without additional work. Let’s take a look at another control center, that we could apply to our craft, that may offer an incompatible ‘interface’ :

trait ControlCabin{

    def engage = increaseSpeed

    def increaseSpeed

This time we need to do some additional wiring, if we want to compose a new type of craft using a control cabin and a pulse engine, since both units don’t fit together directly (the dependency needed by ControlCabin (increaseSpeed) isn’t directly fulfilled by PulseEngine)

class Shuttle extends Spacecraft with ControlCabin with PulseEngine{

    val maxPulse = 10

    def increaseSpeed = speedUp

As you can see, we have to wire together the control cabin with the pulse engine in order to let them cooperate.
In the same way, we could think of another kind of engine which offers a completely different ‘interface’:

trait WarpEngine extends Engine{

    val maxWarp: Int

    var currentWarp = 0;

    def toWarp( x: Int ) { if( x < maxWarp ) currentWarp = x }

Again, we need to wire together the concrete control center with the WarpEngine, depending on their incompatible ‘interfaces’.

Let’s compose a craft, using a commando bridge and a warp engine.
Firstly, we are forced to define a maximum warp level, since it’s an abstract field of WarpEngine. Secondly we have to wire together the commando bridge with the warp engine, that is to ‘route’ the commando bridge’s method speedUp to the warp engines ‘interface’ toWarp with an appropriate implementation:

class Explorer extends Spacecraft with CommandoBridge with WarpEngine{

    val maxWarp = 10

    def speedUp = toWarp( currentWarp + 1 )

Alternatively, we could also use a simple control cabin for another type of spacecraft. Again we have to link the contol cabins commands (increaseSpeed) to the warp engines ‘interface’:

object Defiant extends Spacecraft with ControlCabin with WarpEngine{

    val maxWarp = 20 // claimed by WarpEngine

    def increaseSpeed = toWarp( 10 ) // claimed by ControlCabin

Restricted Access

Until now, we only applied a control center or engines to spacecrafts. But nothing would restrict us to use those units in other domains so far. Say we want to build a certain airplane and apply a warp engine.

class Jet extends Airplane with WarpEngine{

    val maxWarp = 5

It’s propably not the best idea to equip a Jet with a warp engine, since this seems to be a bit oversized for an airplane. We need a way to restrict the usage of warp engines – they should be only applied to spacecrafts. Fortunately we can express this kind of constraint, using Scala’s self type annotation. Included within a trait, it’s like saying ‘this trait is only allowed to be mixed into a type of x‘ (in our case ‘Spacecraft‘):

trait WarpEngine extends Engine{

    this: Spacecraft =>

As you can see, we used the WarpEngines self type to restrict its appliance only to spacecrafts. In all other cases, Scala’s compiler will complain about an unsound mixin.

What makes a spacecraft a spacecaft ?

With selftypes, we now have an instrument to restrict the usage of a trait to be mixed in only to a certain Type.
On the other side, we aren’t forced to use a control center or an engine at all if creating a new spacecraft, since we could provide an implementation of the spacecrafts abstract methods directly within a subtype. That may be fine in some cases, but what if we want to state that a spacecraft has to be composed of at least a certain type of control center and a certain type of engine? Again, we can use the service of the self type annotation, this time applied to our abstract class spacecraft, stating that a spacecraft should at least be compound of a control center and an engine:

abstract class Spacecraft{

    this: ControlCenter with Engine =>

The only thing left is to provide an appropriate type ControlCenter resp. Engine and the correct classification of those concrete units (e.g. ‘CommandoBridge is a ControlCenter‘)

 trait ControlCenter

 trait CommandoBridge extends ControlCenter{ ... }

 trait ControlCabin extends ControlCenter{ ... }

 trait Engine

 trait PulseEngine extends Engine{ ... }

 trait WarpEngine extends Engine{ ... }


Abstract methods and self type annotations are two powerful tools which help to guide or constrain the composition of traits.
You may use abstract methods and abstract fields to enforce a kind of ‘wiring’ between multiple units or at least to force the definition of some concrete information.
You may use a self type annotation to restrict the appliance of a trait, so that it can only be mixed in to a certain type (or subtypes). On the other side, you’re able to enforce that a certain trait (or subtype) have to be mixed in to a certain type, again by using a self type annotation.
In all cases, the ‘composer’ of those units will be guided by the compiler – you can’t forget to give a definition for an abstract method or arrange an unsound composition, since all those ‘constraints’ are based on Scala’s statically typed Type system.

Talking about Scala

scala-logoI will talk about Scala at the XPUG Rhein/Main (in Frankfurt / Germany) Meeting on October 6, 2009.

Beside a general introduction, we’ll take a closer look at some of the new possibilities that come along with the fusion of object oriented concepts and the ideas of functional programming, trying to widen the horizon esp. for imperative thinking ‘brains’ …

Come along and feel welcome if you want to know more about functions as first class objects, Pattern Matching, Mixins or how to write your own custom control structures, making Scala a truly SCAlable LAnguage (and may want to discuss about afterwards).

Just give me a note at if you’re interested to attend and i’m up for sharing further contact / meeting infos with you (talk will be in german, slides will be in english).

Entrance is free!

Did you really get Behaviour Driven Development?

You maybe have noticed some new articles and product announcements recently, that turn themself in the ‘tradition’ of Behaviour Driven Development (BDD).
Most of them mainly concentrate on the introduction of a new vocabulary in order to get rid of the test centric terminology. Some of them even suggest to stick with the well known xUnit test frameworks and mainly kind of change their test method names (if only they contain the now famous word ‘should’) and think they’re done … really? Read the rest of this entry »