Hello again! Nice to see you decided to come back. If you check my previous post you know that functions are quite an important matter in the Scala language.

Last time, talking about recursion, I wasn’t able to cover all the topics about functions. So I decided to dedicate yet another post to it. You can call it “advanced functions”, but I don’t think is so “advance” what I’m going to show here.

You are welcome to read some more on functions in this new blog post.


Default Values

Following the Python Tutorial, I’ll talk a little about this.

Default argument values in Scala are very similar to Python’s. With the difference being in the static types, that is, you’ll have to explicit declare the type of the argument:

def foo(x: Int, y: Int = 0, z: Int = 1): Int = (x + y) * z

foo(10) // Returns 10

foo(10, 10) // Returns 20

foo(10, 10, 2) // Returns 40

foo(10, z = 2) // Returns 20

foo(10, z = 2, y = 10) // Returns 40

foo(10, 10, y = 10) // Error! The parameter `y` has already been specified

As you can see, there is no problem in how to send the arguments, but if you don’t explicitly tell what parameter you are passing, it will use the order to define the assignments.

Welcome to another post on my series of tutorials. As you can see (if you were following my tutorials since I started them), I change the environment of my blog, using Octopress to facilitate the blog writing (it has very nice features such as the automatic categories and blog archive).

This time we will exploring one of the most powerful things Scala offers as a functional programming language. That is, of course, the functions, the core concept in this paradigm.

This concept is quite important, and I’m sure I won’t be able to explain the full potential of Scala functions as I’m not a master in functional programming paradigm. Yet, I’ll do my best. However, it is important that you take a tutorial or course on Scala’s functional programming (I deeply recommend Martin Odersky’s Functional Programming Principles in Scala).

Functions Basics

Scala functions are declared using the same reserved word that Python uses: def. Like all Scala’s control flow instructions, the scope of the function is defined either by the immediate next instruction or by a block closed between curly braces: { and }.

I won’t be able to explain the full potential of Scala functions as I’m not a master in functional programming paradigm. Yet, I’ll do my best.

Functions in Scala are actually values assigned to a symbol (just like a val or a var), so naturally they have a type. The type of a function is defined as a list of parameters of some type returning a parameter of some type (can be the same, can be different). In basic terms, this means that every parameter of a function should have an explicit type (the system cannot infer the type on its own and will throw an error if you don’t declare it). But, they can have an implicit returning type that the system can infer:

def add(x: Int, y: Int): Int = x + y // All good!

def pow2(x: Int) = x * x // Correct again. The system infer the returning type as Int

def substract(x, y) = x - y // Wrong. The system doesn't know the type of x and y

Ok, after a short period of laziness, I come back for more. I warned you about my activity, but, to be fair, it’s been a busy couple of weeks at work.

However, before starting, I wanted you to know that there is an upcoming Course for Functional Programming Principles in Scala in 25 days (starts on September 15th). You can find more information about it (or even enroll in it) at Coursera. The course is in charge of Martin Odersky, the creator of Scala, so you are in good hands.

So, back to business. On this session let’s talk about some more real programming.

Control Flow Tools

The if statement

The most basic and probably the most well known statement in programming, the conditional control flow:

val x: Int = 10

if (x < 0)
  println("x is Negative")
else if (x > 0)
  println("x is Positive")
  println("x is Zero")

// Will return: "x is Positive"

So, on this entry I’ll put a halt on the series of tutorials I’ve been writing. Instead I think it’s time to give a personal opinion in why did I choose Scala as my new main language.

Before keep going on this, I’ll just state that this is a complete personal opinion on Scala, is completely subjective. The reason why I chose it is mine and doesn’t have to be your reason to choose it, but maybe you’ll find some useful insights on what advantages I think the language has.

So, a couple of friends and co-workers asked me “Why Scala over Python? (or any other language for that matter)”, I guess I’ve never answered with a full justification on why did I do it. Actually, I don’t think I have a real or valid justification more than “because I liked it”, but I do want to state some stuff that end up with me switching from a Python programmer to a Scala programmer.

So, now you’ve learnt about Scala lists. As you could see in the previous examples, Scala has a very functional kind of lists, as these are immutable.

If you are ever to use Scala as a functional programming language this is the way to go. I really recommend you to, at least, try to learn this paradigm, as it is design purpose and has many advantages. But, then again, even now I sometimes go back to imperative programming in Scala myself because is more natural to me. Scala as imperative language is pretty similar to Java, so as a side effect I ended up learning how to read Java code (I knew some Java but only the basics, learning Scala my Java understanding improved a lot).

But, lets say that functional programming is way too much to deal with now and you want to know a type more similar to Python lists, the oldie but goodie mutable lists. You have a couple of options of data structures available in Scala, I’ll present two of the most commons.

Scala Arrays

Ok, if my university’s data structure teacher sees me presenting Scala arrays as an option for a “mutable” list he probably would take away my degree and force me to redo the Computer Sciences career all over again.

An array is not a list and will never be one. But, for someone who comes from a Python environment, it’s probably an easy option to replace a immutable list for a mutable version.

Arrays are the simplest and one of the oldest (if not the oldest) data structure you’ll ever face with. In fact, most high-level programming languages lists are internally implemented as arrays. If you’ve ever deal with a real old imperative programming language (I’m looking at you C developer), you are familiar to the concept of array. The thing is that Python doesn’t really have them (at least not internally, you’ll have to import a module for dealing with arrays).

Arrays have some pros and cons in programming, as every data structure. Among the most common pros of an array you’ll find the efficiency they carry in comparison to lists. As arrays are represented as collection of elements (of the same type) stored in a continuous space of memory. They differ from lists in that you’ll have an index for all the elements (which makes the access time of a constant order) and in general are faster to make operations than in lists which can have chunks of elements sparse in many places.