DEV Community: Rafi Panoyan

Higher-order functions in Kotlin

Rafi Panoyan — Thu, 04 Jun 2020 08:12:41 +0000

Kotlin is a language where functions are first class citizens. This allow us to manipulate them as we please.

Today we will see what higher-order functions are, why do they matter and how to create them in Kotlin.

My functions are High

In functional programming (FP for the rest of the post), as the name suggests, functions are the base building blocks of the code.

Often in OOP, a function takes some data as an input, process them, and returns an object (representing some other data).

In FP you can also find higher-order functions : functions that returns another function or functions that take one or more function as arguments.

Show me the code

Step by step, here is what's happening :

fun multiplyBy(multiplier: Int): (Int) -> Int {
    return { value -> value * multiplier }
}

If we look at the multiplyBy function signature and return type, we can tell that :

it takes an Int
it returns a function that takes an Int and returns an Int.

Returning a function is a typical signature of a higher-order function.

The multiplyBy body consist of returning a new function which takes a value in parameter and returns that value multiplied by our multiplier.

val by3 = multiplyBy(3)

Here we call our higher-order function to create a new function named by3 which will multiply by 3 every parameter we give it.

val result = by3(5)

Clearly, we execute by3 with 5 as a parameter. The result is 15.

Ok but, why ?!

If you would have asked me this question yesterday, I would have said... I don't know.

I always liked this "function that creates other function" principle in FP, but never seemed to exceed the academic meaning of it.

Yes, you can now write this :

val by5 = multiplyBy(5)

but in a real application, what's the matter ?

Unless...

My functions are Small

After many years studying FP, writing higher-order functions (HOF for the rest of the post) in Clojure, Haskell or Kotlin, just for the sake of learning a new language, I finally came across a real use case where it saved me a good amount of duplicate code.

I will now develop a concrete (and very simplified) example from an Android application I'm developping.

Context

This application holds a list of dated objects (Record). The user should be able to filter these records by year and by month independently.

Given this list :

Record 1 : 1st january 2019
Record 2 : 1st march 2020
Record 3 : 1st may 2020

I should get these filters :

Years : 2019 2020

Months : january march may

From a single source of data I must get 2 distinct lists based on 2 distinct fields of the record's date (the year and the month).

First try

I expose these filters to my UI with two different LiveData, one for the years and one for the months (if you don't know what a LiveData is, just think about them as Observable data).

The general idea of the flow is as follows :

get the list of all records with getRecords.getAll()
map this list from List<Record> to List<Int> representing the list of years or months of the filters
- we call distinctBy to obtain a list of distinct records based on their year or month
- we map this new list to extract only the corresponding field of the date
- we sort the final list of years or months

This piece of code has several issues. One of them being that the two filters have almost exactly the same code, and only this part differs :

.distinctBy { record ->
    return@distinctBy Calendar.getInstance().apply {
        time = record.date.value
    }[Calendar.YEAR]
}
.map { record ->
    return@map Calendar.getInstance().apply {
        time = record.date.value
    }[Calendar.YEAR]
}

.distinctBy { record ->
    return@distinctBy Calendar.getInstance().apply {
        time = record.date.value
    }[Calendar.MONTH]
}
.map { record ->
    return@map Calendar.getInstance().apply {
        time = record.date.value
    }[Calendar.MONTH]
}

This seems to be a good candidate for a refact.

Quick note

These functions (map, distinctBy, filter, etc.) are all HOF as well, because they take another function as argument (here it's the lambdas we are passing). They implement Function composition and it's one of the main use of HOF.

The OOP-way

Instinctively in OOP, I would have created a function taking two parameters : a record and the calendar field to read from the Calendar instance.

private fun readCalendarField(record: Record, calendarField: Int) {
    return Calendar.getInstance().apply {
        time = record.date.value
    }[calendarField]
}

We would use it as follows :

// years filter
.distinctBy { record ->
    return@distinctBy readCalendarField(record, Calendar.YEAR)
}
.map { record ->
    return@map readCalendarField(record, Calendar.YEAR)
}

// months filter
.distinctBy { record ->
    return@distinctBy readCalendarField(record, Calendar.MONTH)
}
.map { record ->
    return@map readCalendarField(record, Calendar.MONTH)
}

Better. We avoided the duplicate implementation of reading the calendar field, but we still have duplication.

For each filter, the exact same lambda has been created twice : one for distinctBy and another for map. How can we avoid that ?

The FP-way

You saw it coming, let's introduce our higher-order function !

We need to write a function that creates a function, very similar to the lambda we were creating twice, but with an additional parameter : the calendar field.

private fun newCalendarFieldGetter(calendarField: Int): (Record) -> Int = 
    { record ->
        Calendar.getInstance().apply {
            time = record.date.value
        }[calendarField]
    }

The return type of our function is key here : (Record) -> Int. It complies to both distinctBy and map input type which is (T) -> R.

Additionnaly, our HOF asks for a calendar field to parameterize the new function that it creates.

We can now write this :

This starts to look pretty good ! We take advantage of the fact that newCalendarFieldGetter is a pure function (thus has no side effects) to share the same instance for dinstinctBy and map.

Now let's tackle the last duplication of this snippet : the two filters are exactly identical, only differing by the calendar field parameter.

Following the exact same logic as previously, we can create a parameterized function to fill the getRecords.getAll().map() input.

Perfection

The map function we are trying to call needs one parameter of type suspend (T) -> R.

Our new higher-order function will comply to this by returning a suspend (List<Record>) -> List<Int>, and it will take one more parameter, the calendar field.

private fun getDistinctDateFields(calendarField: Int)
    : suspend (List<Record>) -> List<Int> = { records ->
        val fieldGetter = newCalendarFieldGetter(calendarField)
        records
            .asSequence()
            .distinctBy(fieldGetter)
            .map(fieldGetter)
            .sorted()
            .toList()
    }

The previously duplicated block is now generic and can be used to extract a list of any disctinct field of the Record date !

Here is how the entire code looks like.

With this version, adding a third filter on another field of the date, let's say DAY_OF_MONTH, is quit easy !

Final thoughts

This kind of refact is not the most impressive thing you can do with HOF, but it was simple enough to understand how it works in Kotlin and how to use them with common collection manipulation functions as map, filter etc, which also are higher-order functions.

Function composition is a frequent use of HOF, I will certainly post an article about this in the future.

The goal is not to use them everywhere. A good balance must be found between readability, maintainability and optimization (as every aspect of programming). However it's always interesting to learn more new tools to helps us choose the right one for every task.

P.S.

A more optimized version of the getDistinctDateFields function consists of mapping first all records to the date field, and call distinct() right after. It eliminates the need to use the same fieldGetter instance twice :

private fun getDistinctDateFields(calendarField: Int)
    : suspend (List<Record>) -> List<Int> = { records ->
        records
            .asSequence()
            .map(newCalendarFieldGetter(calendarField))
            .distinct()
            .sorted()
            .toList()
    }

That being said, I won't modify the post to include this new version because it allows us to see the possibility of this kind of "function instance" use.

Code is beautiful

Rafi Panoyan — Fri, 15 May 2020 06:58:14 +0000

Today's post will be a bit different. First of all because, at the end of the article, we will have the opportunity to share some code. Then because we won't talk about technical details of a specific programming language, instead we will take a step back and look at the shape of what we write everyday.

Why do we write code ?

We often look at languages as tools that enable us to build software, and at the end of the day, it's exactly what they are. We solve real-world problems with software. Sometimes people's lifes are at stake. Programming is a serious task.

Our code must be robust, maintanable, concise, performant. To achieve that, we define clean code guidelines, clean architectures, development methodology like TDD, CI platform to control the entire pipelines, etc...

Programming is a serious task

But there is more to that.

Take a breath

Every day, in a file, characters become keywords at the tips of our fingers.

We associate these keywords in a very specific way, particular to each programming language, to define the behavior of our software.

And we look at these files, we look at these functions, properties, classes throughout the day.

Of course we do that to understand what real-life rules they are trying to express, we look at them because we might want to refact these pieces of code, or we want to test them. But we definitely look at them, A LOT.

I love your shapes

Consequently, the looks of our code matters. And the appareance of a piece of code is ruled by the programming language we are using.

This is one of the reason I really like learning new programming languages, they don't look the same as the one I'm used to write every day. Different keywords, syntax, special characters... Different shapes.

I will now show you some snippets of a very basic function with different languages, just to admire the shape of the syntax.

The code

The code you will read is certainly not optimized, we could surely write these functions with less lines, with more advanced concepts, but we don't care here.

FizzBuzz is a trivial function that takes an integer x and returns either "fizzbuzz" if it's divisible by 15, "fizz" if it is by 5, "buzz" if it is by 3 and x otherwise.

Kotlin

fun fizzbuzz(x: Int): String =
    when {
        x % 15 == 0 -> "fizzbuzz"
        x % 5 == 0 -> "fizz"
        x % 3 == 0 -> "buzz"
        else -> "$x"
    }

The first language is the one I use the most as an Android Developer. Kotlin introduced a new syntax to develop on the JVM and it has been some fresh air from Java !

Clean, readable

Haskell

fizzbuzz :: Int -> String
fizzbuzz x
    | x `mod` 15 == 0   = "fizzbuzz"
    | x `mod` 5 == 0    = "fizz"
    | x `mod` 3 == 0    = "buzz"
    | otherwise         = x

This purely functional language is very comparable to pure mathematic in its syntax. I really love this facet, you can tell it by the way the signature of the function is declared.

Pure, rational

Clojure

(defn fizzbuzz [x]
    (let [d { 
        :by15 (= 0 (mod x 15))
        :by5 (= 0 (mod x 5)) 
        :by3 (= 0 (mod x 3))}]
      (cond 
        (:by15 d) "fizzbuzz"
        (:by5 d) "fizz"
        (:by3 d) "buzz"
        :else x )))

Controversial choice here but... what a beauty ! A LISP language, where absolutely everything is a list.

(element1 element2 element3 ...)

That's it. Each and every piece of code you write is exactly this, a list. Either you declare or call a function, compare two values, create a conditional branch... Consistency.

CONSISTENT

Now what ?

You might not have learnt anything new reading this post, but I really hope you stopped for a moment to think about the shape of what you write everyday.

That being said, I'm sure that caring about the "physical" beauty of our code can help us write it better overall.
More concise, readable, enjoyable to read... you certainly don't want this 30+ lines' method in your class !

Our job can seem like art sometimes, and syntax is just one the many facet of it. Architecture, algorithm, even project structures, are aspects we should look at with art in mind.

Share !

I would really appreciate if you could share a piece of art with your own FizzBuzz function, written in whatever language you find good-looking !

If you are curious about the languages above, here are some links :

Basic key behaviors of Kotlin coroutines

Rafi Panoyan — Thu, 30 Apr 2020 20:25:09 +0000

When I first learned about Kotlin coroutines, I was having a hard time identifying the specific behavior of all keywords: launch, withContext, async, etc...

Is my coroutine suspended ? How can I wait many of them at one point ? Where are they executing ?

Quickly, I decided to sum up some key basic behaviors to help me with that, and that's what I will share today ! This post is aimed at developers who are not using coroutines right now, or are using it but need a quick refresh on some basic behaviors.

What is a coroutine ?

According to the offical documentation, a coroutine is essentially a (very) light-weight thread.
It enables asynchronous operations without the need of callbacks, Promise, or Future concepts. Write imperative code, run concurrent operations.

Snippets setup

Let's declare some context for our coroutines snippets:

private val job = Job()
private val customScope = CoroutineScope(job + Dispatchers.Default)

private suspend fun fakeHardWork(tag: String): String {
    println(tag)
    delay(4000)
    return "I'm exhausted"
}

A Job is responsible for holding a reference to a coroutine. With that reference you can .start() the coroutine if it was not started, wait for its completion with .join() or cancel it with .cancel()
customScope is a CoroutineScope composed of the job and a CoroutineDispatcher (and it can be much more). Yes, I added a CoroutineDispatcher to a Job. That's because they both are a CoroutineContext and they can be merged together.
fakeHardWork() is, as the name can suggest, a suspend function faking a 4 seconds task

I did not get into the details of these objects that are part of the coroutine's vocabulary. I encourage you to read the documentation about all of them, or find some posts describing them.

Quick look at `CoroutineDispatcher`

The CoroutineDispatcher is responsible for describing where the coroutine must be executed. Some dispatchers are provided by the core library with these properties :

Dispatchers.Default which serves for basic background task.
Dispatchers.IO offers a thread pool optimized for IO tasks (only available for the JVM).
Dispatchers.Unconfined if the thread of execution does not matter.

Finally, Dispatchers.Main property is a special dispatcher that is allocated to main thread operations. Such tasks as manipulating the UI are often required to be executed on this dispatcher (Android crashes the app if that's not the case for example).

Using the Dispatchers.Main property without providing a concrete implementation in the classpath of your application will throw an IllegalStateException. kotlinx-coroutines-android is the provider of the Main dispatcher for Android.

Launching a coroutine

fun newCoroutine() = 
    customScope.launch { // starts a new coroutine 'C1'

        fakeHardWork("working") // this suspends C1 until the function completes
        println("done")
    }

Theoretical output:

00s:0000ms : working
04s:0000ms : done

This piece of code is quit straighforward. We launch a new coroutine inside the customScope. Since this scope has been initialized with Dispatchers.Default, it's executing on the corresponding thread pool.

launch creates and executes a new coroutine and must be called on an existing CoroutineScope.

Switching Dispatchers

fun switchDispatchers() = 
    customScope.launch { // starts a new coroutine 'C1'
        fakeHardWork("work from Dispatchers.Default") // same as above, suspends C1

        // switch Dispatcher, still suspends C1
        withContext(Dispatchers.IO) { 
            fakeHardWork("work from Dispatchers.IO") 
        }
        println("done on Dispatchers.Default")
    }

Theoretical output:

00s:0000ms : work from Dispatchers.Default
04s:0000ms : work from Dispatchers.IO
08s:0000ms : done on Dispatchers.Default

Here, withContext changes the execution context of the block in parameter. The second call to fakeHardWork() is executed on Dispatchers.IO, and withContext is still suspending C1.

withContext merges the current CoroutineContext it has been launched from (here customScope's context), with the context you passed in parameter.

withContext does not create a new coroutine and suspends its caller until its block is executed.

Parallel execution inside a coroutine

fun parallelWorkInCoroutine() = 
    customScope.launch { // starts a new coroutine C1

        // fire a new coroutine C2. C1 is not suspended
        val work_1 = async { fakeHardWork("w_1 from Dispatchers.Default") }
        // fire a new coroutine C3 on another Dispatcher. C1 is not suspended
        val work_2 = async(Dispatchers.IO) { fakeHardWork("w_2 from Dispatchers.IO") }

        // await() calls suspend C1
        val result = work_1.await() + work_2.await()
        println(result)
    }

Theoretical output:

00s:0000ms : w_1 from Dispatchers.Default
00s:0010ms : w_2 from Dispatchers.IO
04s:0010ms : I'm exhaustedI'm exhausted

Now this is interesting. async is a coroutine builder. Unlike withContext, it actually creates and starts a new coroutine while also immediatly returning a Deferred<T> (T being the return type of the block passed to async, a String in our example).

We can then call await() on this object to effectively suspend the caller coroutine (C1 in the snippet) and get back the String produced by the blocks passed to async.

Here result equals to "I'm exhaustedI'm exhausted".

With this, we could await many Deffered and then execute something only when all of them complete.

async creates and starts a new coroutine. The returned Deferred allows us to suspend the caller coroutine and get the produced value.

Wrapping it up

I described very few behaviors about coroutines, there's so much more to discover and to learn about them ! But I find these points to be good tools to start manipulating coroutines and learn step by step.

I'll probably write later about other more advanced concepts. For now, if you were asking yourself if coroutines are worth a try, go ahead !

More starting resources

If you are curious, this great talk is a perfect introduction to Coroutines from the creator, Roman Elizarov.

DEV Community: Rafi Panoyan

Higher-order functions in Kotlin

My functions are High

Show me the code

Ok but, why ?!

My functions are Small

Context

First try

Quick note

The OOP-way

The FP-way

Perfection

Final thoughts

P.S.

Code is beautiful

Why do we write code ?

Take a breath

I love your shapes

The code

Kotlin

Haskell

Clojure

Now what ?

Share !

Basic key behaviors of Kotlin coroutines

What is a coroutine ?

Snippets setup

Quick look at CoroutineDispatcher

Launching a coroutine

Switching Dispatchers

Parallel execution inside a coroutine

Wrapping it up

More starting resources

Quick look at `CoroutineDispatcher`