Monday, December 30, 2013

Take a trip back to 1984. Apple release the Macintosh, 'The Final Battle' is about to commence in V and Scotland win the Five Nations completing a grand slam in the process. Right in the middle of miners' strike in the UK, English pop group Sade release the catchy number: Smooth Operator. It was chart success in the UK and in the US (not to mention the German, Dutch and Austrian charts). Little did Sade know that decades later the Groovy programming language would feature several
smooth operators that go above and beyond the standard set of Java operators. Now, we'll leave the 1980's comparisons there and shall discuss a few of the smooth operators in Groovy in this blog post.

Elvis

The Elvis Operator (so named after a certain person's hairstyle) is a shortened version
of the ternary operator. It is very handy for null checking. And remember even though it can be argued null handling is bad coding practise because it is better to not have nulls in your code, lots of APIs in a code base will inevitably return nulls and in the real world where you want to add some robustness and defensive coding to keep things smooth in production, this kind of thing can be useful.

Now here is how it works. If the expression to the left of the Elvis operator evaluates to false (remember in Groovy
there are several things such as null, such as an empty String which can be coerced to mean false),
the result of the expression will be the whatever is on the right.

String country = country.name ?: "Unknown country"

So, in the above example if country.name is null or just "" since both are false in Groovy, country
will be assigned as "Unknown country". If country.name was not false, country would just be assigned that value.

Null-Safe Dereference (also called the Safe Navigation operator)

This is especially useful to avoid null pointer exceptions in a chained expression. For example,

String location = map.getLocation().getXandYCoordinates();

might yield a null pointer exception. But using the safe navigation operator if either map, or the result of map.getLocation()
are null

String location = map?.getLocation()?.getXandYCoordinates();

location will just be set as null. So, no null pointer exception is thrown.

Spread

The Spread operator is useful when executing a method on elements of a collection and collecting the result.
In this example, I parse a bunch of Strings into arrays and then run a closure on each of the arrays to get
all the first elements.

Now, remember the Spread operator can only be used on methods and on elements. It can't execute a closure
for example. But what we can do is leverage Groovy's meta programming capabilities to create a method
and then use the spread operator to invoke that. Suppose we had a list of numbers that we wanted to
add 50 too and then multiply the answer by 6 we could do:

Spaceship operator

This originated in the Perl programming language and is so called because you guessed it, <=> looks like a spaceship! So how does it work? Well, it is like this. The expression on the left and the right of the spaceship operator are both evaluated. -1 will be returned if the operand on left is smaller, 0 if the left and
right are equal and 1 if the left is larger.
It's power should become more obvious with an example.

But what about when our list of Engineers grows and grows and we have multiple engineers of the same age?
In these scenarios it would be nice to sort by age first and name second.
We could achieve this by doing:

engineers.sort{a, b ->
a.age <=> b.age ?: a.name <=> b.name

This expression will try to sort engineers by age first. If their ages' are equal
a.age <=> b.age will return 0. In Groovy and in the Elvis construct, 0 means false
and hence a.name <=> b.name will then be evaluated and used to determine the sort.

Field Access

In Groovy, when a field access is attempted, Groovy will invoke the corresponding accessor method. The Field Access operator is a mechanism to force Groovy to use field access.

Saturday, October 26, 2013

Occasionally, when I buy some food I check the label to see how unhealthy it is in an effort to remind myself to eat better. I probably should do this more often
but that's another story.

With software, I take a more strict approach. I like to know
exactly what version of what I am using and if it pertains to a build coming from a project
I am working on, I like to know even more:

the branch it came from

any code or config changes

the time the build was done

the person who did the build

the commit revision it corresponds to

The advantages of this are obvious but worth re-stating.

While you are in development, if you have multiple deployments and see something unusual
you will immediately want to compare them.

For example say you have:

build #349 on box 1

build #352 on box 2 (which includes development changes from a feature branch Y)

You notice some strange behaviour for an error message on box 2 but don't on box 1. You can
immediately check which box has what version, then check the changes and then try to rationalise the difference.

You can be sure your latest code check-in is deployed

All this build information should be in official release notes, so if you can automate
it as part of your development process you have saved yourself having to automate it as part of your release

In enterprise architectures where you have multiple components developed from different
teams integrating with each other, all components should make it easy to get this information.
This helps to manage the stack and for everyone to be able to immediately check if new versions
of any components have been deployed or to roll back to stable versions if problems with any upgrades of components happen.

So away with the opinions and now with some examples. The project that I am currently working uses a Grails
based architecture and Atlassian's Bamboo for builds and deploys. I wanted to get this information I described into every build - and yes that includes every development build. I will now outline the steps.

Step 1

Write an event handler to execute when the war is being created.
This should read a bunch of system properties (which you'll set in bamboo)
and put them in your application.properties of your war file.
Example:

This will mean when bamboo builds you war all the above properties will be put in your application.properties file.

Step 3

Now all you need to do is make it easy for a Grails GSP to read these properties
and display them. This means that when deployed all anyone will have to do is hit a special URL and then they'll get all the build info for the deployed WAR.

...
... Some CSS and JavaScript

Environment: ${grails.util.Environment.current.name}

Build Info:

Name

Value

UserName

#${g.meta([name: 'build.userName'])}

Built by

#${g.meta([name: 'build.number'])}

Date

#${g.meta([name: 'build.date'])}

Branch

#${g.meta([name: 'repository.branch'])}

Revision number

#${g.meta([name: 'repository.revision.number'])}

And in the spirit of food analogies... Here's one I made earlier and how it looks

So there you go, software taken more seriously than food.
I'm off to get a Big Mac!

Get the median value for a column named responsetime in a table allrequests

SELECT( (SELECT MAX(responsetime) FROM (SELECT TOP 50 PERCENT responsetime FROM allrequests ORDER BY responsetime) AS BottomHalf) + (SELECT MIN(responsetime) FROM (SELECT TOP 50 PERCENT responsetime FROM allrequests ORDER BY responsetime DESC) AS TopHalf)) / 2 AS Median

Monday, June 17, 2013

Any web architecture using JavaScript will always have plenty of
AJAX requests to the server. There are many, many, many different ways AJAX calls can be made.
Suppose you're thinking good software engineering and you want to avoid coupling your client code to the AJAX mechanism you are
using? You could use a wrapper / bridge / proxy type object which contains all the APIs to get information
from the Server and encapsulates your AJAX mechanism.
Following the Crockford Module pattern this could pan out something like:

What are the pro's of using the wrapper approach? Well essentially
the advantages are all derived from the fact there is a nice separation of
concerns: the transport mechanism (doesn't even have to be ajax) is separated from
the actual data requests coming from the client.
This means:

If you wish to change Ajax mechanism (i.e. move from one Ajax library
to another), it's not a big deal. The impact is limited.

It's easier to stub out and test.

It's easier to achieve code reuse. Suppose you want to have consistent
error handling for exceptions from Ajax requests, it's much easier to do this if
all Ajax request are following the same pattern.

Tell me something more interesting.

Well we all know that you can see the AJAX requests in firebug. But say you wanted
another way to log what requests had been invoked on your wrapper. In Java, you
could write an Aspect and set it on every method that made an Ajax request.
There is no direct equivalent to aspects in JavaScripts. But we can do something similar.
Firstly, the function to do the pre and post logging:

Ok so wrapPrePostLogic takes a function, and returns a new function
which wraps around the existing function and puts logging before and after
the invocation of that function. Hold on sec - IE is awkward. It
doesn't support getting the function.name variable. So let's write a helper method
to get function name for any browse and use that instead.

Not bad. Anything else?

Ok, so say you are you using a UI test framework and wanted to test code coverage of
all methods that send / receive data to / from the server. Instead of getting
your wrapper function to log to the console you could update a hidden div and then
make your test framework check this hidden div.

Saturday, May 18, 2013

Merge sort is a classical "divide and conquer" sorting algorithm. You should have to never write one because you'd be silly
to do that when a standard library class already will already do it for you. But, it is useful to demonstrate a few
characteristics of programming techniques in Scala.
Firstly a quick recap on the merge sort. It is a divide and conquer algorithm. A list of elements is split up
into smaller and smaller lists. When a list has one element it is considered sorted. It is then merged with the list beside it.
When there are no more lists to merged the original data set is considered sorted.
Now let's take a look how to do that using an imperative approach in Java.

An auxillary array is used to achieve the sort. Elements
to be sorted are copied into it and then once sorted copied back.
It is important this array is only created once otherwise there can
be a performance hit from extensive array created. The merge method
does not have to create an auxiliary array however since it changes an
object it means the merge method has side effects.

The splitAt function is used to divide up the data up each time
into a tuple. For every recursion this will new a new tuple.

The local function merge is then used to perform the merging.
Local functions are a useful feature as they help promote encapsulation
and prevent code bloat.

Neiher the mergeSort() or merge() functions have any side effects.
They don't change any object. They create (and throw away) objects.

Because the data is not been passed across iterations of the merging,
there is no need to pass beginning and ending pointers which can get very buggy.

This merge recursion uses pattern matching to great effect here. Not only
is there matching for data lists but when a match happens the data lists are
assigned to variables:

x meaning the top element in the left list

xs1 the rest of the left list

y meaning the top element in the right list

ys1 meaning the rest of the data in the right list

This makes it very easy to compare the top elements and to pass around the rest of the date
to compare.
Would the iterative approach be possible in Java? Of course. But it would be much
more complex. You don't have any pattern matching and you don't get a nudge to declare
objects as immutable as Scala does with making you make something val or var. In Java, it would always be easier
to read the code for this problem if it was done in an imperative style where objects are being changed
across iterations of a loop. But Scala a functional recursive approach can be quite neat.
So here we see an example of how Scala makes it easier to achieve good, clean, concise
recursion and a make a functional approach much more possible.

Friday, May 17, 2013

Coursera run an excellent Scala course which I just had the opportunity of participating in. The course duration is
seven weeks. Each week consists of about 1.5 hours of lectures and then an
assignment which can take anything between an hour to about 5 hours.The course syllabus is outlined here.So personal opinion time...

Was it worth it?Absolutely.Unless you are a
complete pro in Scala and Functional Programming you will learn something from this course - most importantly a deeper understanding of the FP paradigm.

I remember many eons ago when I first started learning OO,
like many noobs I thought I understood OO when I understood polymorphism, inheritance, encapsulation and could name check a few design patterns. It took me a while to really realise the
difference between good and bad abstractions and how dependencies that look
benign can drastically increase software entropy in a project.Similarly many people might approach FP thinking
it is just all about function literals, 2nd
order functions, inner functions and closures.Well the first important point to make about
this course is that it does a super job of emphasising the importance of smart
and clever usage of recursion in FP.This was not apparent to me before the course. The
reason why recursion is a big deal in FP is of course because immutable state is a big deal in FP. That is easier to achieve when you pass data between
iterations as in recursion than an imperative style loop which can usually
mean some object(s) is being changed across iterations.

Now, I hope that made some sense. Because the realbrain tease is when you are given a problem that
you could do with one arm tied behind your back using a for loop and told to do
it with recursion.It takes a lot of
practise to get really good at recursion and it is something I still have to
practise more myself but the course really made me think about it much much
much more than I ever did previously.

Sunday, April 21, 2013

Firstly, sorry it has been so long since last blog post. Life is busy when you have two children. I decided to try and learn Scala in 2013 and I am currently still pluggin' away. This blog post is a review of David Pollack's Beginning Scala.

David Pollack has been writing software since 1977. He wrote diagnostic software for the Commodore 64, the first real-time spreadsheet and founded the Lift Web Framework in 2007. He describes his experience with Scala as an epiphany that changed the way he approach software; he certainly writes with enthusiasm and passion and in this book we even get a forward from the Godfather himself Martin Odersky.

'Beginning Scala' focusses very much on the core fundamentals of Scala. The book in length is just under 300 pages. This is quite short in comparison to say Martin Odersky's excellent 'Programming in Scala' which is well over twice the length. Where I see the sweet spot for Beginning Scala is for someone who wants to dip their toe into the water and is curious about the language feels and wants to get a good overview of the language quickly. For more a detailed and substantial take on the language something like Odersky's book is necessary.

Areas covered include:

Scala traits and Scala's type system

Call-by-name

Scala collections and their immutable nature

Functional characteristics (passing functions, returning functions)

Pattern matching

Actors and concurrency

There are also some tips on how to introduce Scala to your team and some best practise advice. My favourite parts were the explanation of Scala traits and the demonstration of the classic GoF Visitor Pattern made so simple using pattern matching (I'll cover this in a separate post). The one criticism I'd have is that I think what really sets Scala apart from Java is not that has lots of syntactic sugar but that it offers a functional programming approach. This doesn't just mean you can pass functions to function, return them functions and so on but that you have to approach problems in a very different way. In functional programming recursion is favoured over iteration. There are many problems that developers could solve using iteration with one arm tied behind their back but to solve them using recursion is trickier. One of Scala's features is that it facilitates both approaches but I think if you are going to embrace the functional paradigm properly you need to ditch iteration and embrace recursion. This isn't really covered in the book - in fairness it is not really covered in detail Odersky's book either. However, if you look at the Scala course on coursera it is a massive massive massive massive massive massive massive massive part of it.

So overall, a very good book and well worth a dabble for someone that wants a dabble in Scala but if you want more you'll need more.

Sunday, January 27, 2013

The 16th President of the United States. Abraham Lincoln once said: "As our case is new we must think and act anew". In software engineering things probably aren't as dramatic as civil wars and abolishing slavery but we have interesting logical concepts concerning "case". In Java the case statement provides for some limited conditional branching. In Scala, it is possible to construct some very sophisticated pattern matching logic using the case / match construct which doesn't just bring new possibilities but a new type of thinking to realise new possibilities.

Let's start with a classical 1st year Computer Science homework assignment: a fibonacci series that doesn't start with 0, 1 but that starts with 1, 1. So the series will look like: 1, 1, 2, 3, 5, 8, 13, ... every number is the sum of the previous two.

All straight forward. If 0 is passed in it counts as the first element in the series so 1 should be returned. Note: to add some more spice to the party and make things a little bit more interesting I added a little bit of logic to return 0 if a negative number is passed in to our fibonacci method.

It is possible to test for multiple values on the one line using the | notation. I do this to return a 1 for both 0 and 1 on line 4 of the example.

There is no need for multiple return statements. In Java you must use multiple return statements or multiple break statements.

Pattern matching is an expression which always returns something.

In this example, I employ a guard to check for a negative number and if it a number is negative zero is returned.

In Scala it is also possible to check across different types. It is also possible to use the wildcard _ notation. We didn't use either in the fibonacci, but just to illustrate these features...

def multitypes(in: Any): String = in match {
case i:Int => "You are an int!"
case "Alex" => "You must be Alex"
case s:String => "I don't know who you are but I know you are a String"
case _ => "I haven't a clue who you are"
}

Pattern matching can be used with Scala Maps to useful effect. Suppose we have a Map to capture who we think should be playing in each position of the Lions backline for the Lions series in Austrailia. The keys of the map will be the position in the back line and the corresponding value will be the player who we think should be playing there. To represent a Rugby player we use a case class. Now now you Java Heads, think of the case class as an immutable POJO written in extremely concise way - they can be mutable too but for now think immutable.

In this example we have players for every position except inside centre - which we can't make up our mind about. Scala Maps are allowed to store nulls as values. Now in our case we don't actually store a null for inside center. So, instead of null being returned for inside centre (as what would happen if we were using a Java HashMap), the type None is returned.

For the other positions in the back line, we have matching values and the type Some is returned which wraps around the corresponding RugbyPlayer. (Note: both Some and None extend from Option).

We can write a function which pattern matches on the returned value from the HashMap and returns us something a little more user friendly.

This example doesn't just illustrate pattern matching but another concept known as extraction. The rugby player when matched is extracted and assigned to the rugbyPlayerExt. We can then return the value of the rugby player's name by getting it from rugbyPlayerExt. In fact, we can also add a guard and change around some logic. Suppose we had a biased journalist (Stephen Jones) who didn't want any Irish players in the team. He could implement his own biased function to check for Irish players

Single Parameter functions

Consider a list of numbers from 1 to 10. The filter method takes a single parameter function that returns true or false. The single parameter function can be applied for every element in the list and will return true or false for every element. The elements that return true will be filtered in; the elements that return false will be filtered out of the resultant list.

Now now now, listen up and remember this. A pattern can be passed to any method that takes a single parameter function. Instead of passing a single parameter function which always returned true or false we could have used a pattern which always returns true or false.

What this example is saying is patternToUseLater is a partial function that takes a string and returns a string. The last statemeent in a function is returned by default and because the case expression is a partial function it will returned as a partial function and assigned to pattenrToUseLater which of course can use it later.

Finally, Johnny Sexton is a phenomenal Rugby player and it is a shame to hear he is leaving Leinster. Obviously, with Sexton's busy schedule we can't be sure if Johnny is reading this blog but if he is, Johnny sorry to see you go we wish you all the best and hopefully will see you back one day in the Blue Jersey.

It was considered best practice to always check if your logging was enabled for the appropriate level before performing any String concatenation. I even remember working on a project ten years ago (a 3G radio network configuration tool for Ericsson) where String concatenation for logging actually resulted in noticeable performance degradation.

Since then, JVMs have been optimised and Moore's Law has continued so that String concatenation isn't as much of a worry as it used to be. Many frameworks (for example Hibernate), if you check the source code you'll see logging code where there is no check to see if logging is enabled and the string concatenation happens regardless. However, let's pretend concatenation is a performance issue. What we'd really like to do is remove the need for the if statements in order to stop code bloat.

The nub of the issue here is that in Java, when you call a method with parameters the values of the parameters are all calculated before the method is called. This why the if statement is needed.

simpleComputation(expensiveComputation());// In Java, the expensive computation is called first.
logger.log(Level.INFO, "Log this " + message);// In Java, the String concatenation happens first

Scala provides a mechanism where you can defer parameter evaluation. This is called call-by-name.

The => before the String types means that the String parameter is not evaluated before invocation of the log function. Instead, there is a check to confirm the logger level value is at the appropriate value and if so the String will then evaluated. This check happens within the log function so there is no need to put the check before every invocation of it. What about that for code re-use?

Anything else?

Yes when pass-by-name is used, the parameter that is passed-by-name isn't just evaluated once but everytime it is referenced in the function it is passed to.
Let's look at another example

In this example, we can see that nanoTime() isn't just executed once but everytime it is referenced in the function, printTime it is passed to. This means it is executed three times in this function and hence we get three different times. 'Til the next time, take care of yourselves.

Wednesday, January 16, 2013

Problem?

We want a function that will take an List of Rugby players as input and return those players names that play for Leinster and can run the 100 meters from the fastest to the slowest.

Step 1: Have a representation for a Rugby player.

Ok so it's obvious we want something like a POJO to represent a Rugby player. This representation should have a player's name, their team and the time they can the 100 meters in. Let's use Scala case class construct which removes the need for boiler plate code.

The code above should be self explanatory. The various rugby players are instantiated. Note the inferred typing. There is no need to declare any of the rugby players as RugbyPlayers types. Instead, it is inferred. Another thing that is interesting is the keyword val is used. This means the reference is immutable It is the equivalent to final in Java.

Step 3: Write the function

The function begins with def keyword signifying a function declartion.

A List of RugbyPlayerCaseClass instances are taken in as input. The List type is a Scala type.

The return type is optional. In this case it is not explictly specified as it is inferred.

The part to the left of the = is what the function does. In this case the function invokes three difference collection operators.

.filter(_.team =="Leinster) - this iterates over every element in the List. In each iteration the _ is filled in with the current value in the List. If the team property of the current Rugby player is Leinster the element is included in the resulting collection.

.sortWith(_.sprintTime100M < _.sprintTime100M) - sortWith is a special method which we can use to sort collections. In this case, we our sorting the output fromthe previous collection operator and we are sorting based on the sprintTime for 100M.

.map(_.name) - this maps every element from the output of the sort operator to just ther name property.

The function body does not need to be surrounded by {} because it is only one line code.

There is no return statement needed. In Scala, whatever the last line evaluates to will be returned. In this example since there only is one line, the last line is the first line.

Sunday, January 13, 2013

Nearly everyone who learns Scala can get confused over the word partial used in the contexts:

Partial functions

Partially applied functions

Let's look at both.

Partially applied functions

Scala gets its functional ideas from classical languages such as Haskell (Haskell 1.0 appeared in same year as Depeche Mode's Enjoy the Silence and Dee Lite's Groove is in the Heart in 1990). In functional languages a function that takes two parameters that returns one parameter can be expressed as a function which takes one of the input parameters and returns a function that takes the other input parameter and returns the same output parameter.

f(x1, x2) = y

f(x1) = f(x2) = y

A cheesey analogy would be to time travel back to 1990 and find yourself a juxebox. Put money in for two selections and select Depeche Mode first and Dee Lite second, walk away and throw a few shapes as they are played one after the other. Or, put in your money for two selections select Depeche Mode and then don't make another selection. Don't walk away just yet. The well engineered Juxebox should prompt you for another selection (give you another function) and then you can select Dee Lite (pass in the second parameter). So, the end output in both cases is the same music in the same order.

In Scala, when only some parameters are passed to a function to make another function it is said to be a partial application of that function.

So consider the function:

def minus(a: Int, b: Int) = "answer=" + (a-b)

Now, let's partially apply this function by passing in some parameters and making another function.

val minus50 = (a: Int) => minus(a, 50);

In this case minus50 is a partial application of minus.

We can do:

minus50(57); // outputs 7.

Note: we can also partially apply using the _ notation and a save ourselves a little bit of finger typing.

val minus50 = minus(_:Int, 50);

Partial functions

A partial function is a function that is valid for only a subset of values of those types you might pass into it. For example,
Consider the mathematical function where x is set of all number from 1 to 100:

f(x) = x + 5;

A function is said to be partial if the function is only applied to a subset in set of element of x.
So if we only want to define the function

f(x) = x + 5

for the numbers 1,2,3,4,5,6,7 but not 8,9,10, ... - we define a partial function.

f(x')=x+5

where x' = {1,2,3,4,5,6,7}

In Scala, a PartialFunction inherits from Function and adds two interesting methods:

isDefinedAt - this allows us to check if a value is defined for the partial function.

orElse - this allows partial functions to be chained. So if a value is not defined for a function it can be passed to another function. This is similar to the GoF Chain of Responsibility pattern.

Ok so open up a Scala REPL and create the following partial function which will add 5 to an integer as long as the integer is less than 7.

When you try this for a value less than or equal to 7, you will see the result no problem

scala > add5Partial(6);
res1: 11

When you try it for a value greater than 7 you don't get a nice clean answer.

scala> myPartial(42);
scala.MatchError: 42 (of class java.lang.Integer)
at $anonfun$1.apply$mcII$sp(:7)
at .(:9)
at .()
at .(:11)
at .()
at $print()
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at scala.tools.nsc.interpreter.IMain$ReadEvalPrint.call(IMain.scala:704)
at scala.tools.nsc.interpreter.IMain$Request$$anonfun$14.apply(IMain.scala:920)
at scala.tools.nsc.interpreter.Line$$anonfun$1.apply$mcV$sp(Line.scala:43)
at scala.tools.nsc.io.package$$anon$2.run(package.scala:25)
at java.lang.Thread.run(Thread.java:722)

The use of isDefinedAt() should now be becoming apparent. In this case, we could do:

And yes for this specific case, this will work. But what if your functions/ commands become more complex. Are you go to hang around in if / else land? Probably not. 'Til the next time, take care of yourselves.

Sunday, January 6, 2013

Functions are an important part of the Scala language. Scala Functions can have a parameter list and can also have a return type. So the first confusing thing is what's the difference between a function and a method? Well the difference is a method is just a type of function that belongs to a class, a trait or a singleton object.
So what's cool about functions in scala? Well you can define functions inside functions (which are called local functions) and you can also have anonymous functions which can be passed to and returned from other functions. This post is about those anonymous functions which are referred to as function literals.
As stated, one of the cool things about function literals is that you can pass them to other functions. For example, consider snippet below where we pass a function to a filter function for a List.

List(1,2,3,4,5).filter((x: Int)=> x > 3)

In this case, the function literal is (x: Int)=> x > 3
This will output: resX: List[Int] = List(4, 5).
=> called "right arrow" means convert the thing on the left to the thing on the right. The function literal in this example is just one simple statement (that's what they usually are), but it is possible for function literals to have multiple statements in a traditional function body surrounded by {}. For example, we could say:

List(1,2,3,4,5).filter((x: Int)=>{
println("x="+ x);
x > 3;})

which gives:

x=1
x=2
x=3
x=4
x=5
resX: List[Int] = List(4, 5)

Now one of the key features of Scala is to be able to get more done with less code. So with that mindset, let's see how we can shorten our original function literal. Firstly, we can remove the parameter type.

List(1,2,3,4,5).filter((x)=> x > 3)

This technique is called target typing. The target use of the expression in this case, what is going to filter is allowed to determine the type of the x parameter.
We can further reduce the strain on our fingers by removing the parentheses. This is because the parentheses were only there to show what was been referred to as Int in the parameter typing. But now the typing is inferred the brackets are superflous and can be removed.

List(1,2,3,4,5).filter(x => x > 3)

Shorten it even more? yeah sure...
We can use the placeholder underscore syntax.

List(1,2,3,4,5).filter(_ > 3)

Underscores have different meanings in Scala depending on the context they are used. In this case, if you are old enough think back to the cheesey game show blankety blank.

This gameshow consisted of of sentences with blanks in them and the contestants had to make suggestions for what went into the blank. In this example, the filter function fills in the blanks with the values in the Lists it is being invoked on. So the filter function is the blankety blank contestant and the List (1,2,3,4,5) are what the filter function uses to fill the blank in.
So now our code is really neat and short. In Java to achieve the same, it would be:

Tuesday, January 1, 2013

Right time to broaden the horizons. It's 2013 and I am going to start blogging about Scala which I am trying learn. I am going to start with for loops.

for(i
It is quite easy to figure out what is going on here, without even mentioning the word Scala. Hey it's just a for loop and yeah it iterates from 1 to 5 and there's probably some type inference going on - since Scala is statically typed. That's all fine, but, I find it useful when trying to learn a new language, to learn the language of that language. For anyone coming from a Java background the 'generator. Why? Because it generates individual vales from a range which in this case is the 1 to 5 part.

There is not much else interesting in this example except the intent of 2 spaces - Java programmers will be use to 4. So what else? Well there are two styles of for loops in Scala:foreach and for. The former is intended for a functional approach and I'll cover this is another post. The later is suited for imperative style. In fact the for and foreach constructs are an excellent example of how Scala facilitates both imperative and functional progamming.

Give me more?

Sure, let's have at look at more tricks with for loops using the imperative approach.

There is no need to explictly make the class ForLoopExample public. This is because public is default access level in Scala. Where you said public in Java you say nothing in Scala.

The only difference between forExampleWithTo and forExampleWithUntil is that one uses to in its range and the other uses until. In these examples to means 1,2,3,4,5 and until means 1,2,3,4 - i.e. the last element is not included.

forExampleWithMultipleRanges shows how to iterate over multiple ranges. In addition, note the statement in the for loop are enclosed in {}. The {} are required when multiple statements are in each iteration. If there is only one statement they can be omitted.

forExampleWithFilter shows how to filter out values from the list.

forExampleStoreValues shows how to store the result of the iteration values from a for list.

Rather than MainRunner being declared as a class, it is declared as an Object. This means it is singleton.

The main() method is similar to Java's public static void main. Except there is no need for public (it's the default). There is no need for static (we are in a singleton) and there is no need to declare the return type. You see Scala you get more code with less typing.

In some cases I omit the () from the method invocation. In cases when a method has no arguments Scala allows the omissions of the (). However, this notation should only be used when the method has no side effects i.e. the method does not change the state of anything - so I am only using it here to for purposed of illustration.

About Me

Alex Staveley is a software professional passionate about software
engineering and technical architecture. He blogs about architectural
approaches, Java topics, web solutions and various technical bits and
pieces.