Refactoring to Functional–Getting Started

This is a multi-part series on Refactoring to Functional Programming

  1. Getting Started
  2. Basic Primitives
  3. Reducing and Flattening Lists
  4. Why Class?

It’s high-time I improve my functional programming skills, and like my fellow countryman*, I’ll do it in the open. Different to Rob though, I’m going to use Kotlin, not Clojure. Reasons are:

  • I’m loving the language and am mostly comfortable with it.
  • I feel it’s a good stepping stone as it provides familiarity, allowing me to focus on functional paradigms.
  • Kotlin claims to have functional aspects. I’m hoping to prove this right.
  • It fits in nicely with my job.

and most importantly, because I want to.

In a series of posts, I’ll try and look at ways of solving problems using a functional approach as opposed to an imperative one. I’m not a big fan of blog post series, primarily because they require some sort of structure and planning, but this is an ongoing process and I’m not going to wait till the end to write about it. And while a certain level of structure will go into these posts, I can’t commit to how it will pan out so we’ll just pretend it’s not a series.

I want to give up-front credit to @jhusain as some of the ideas and exercises will be based on his LearnRX project as well as my friend Rob whose brain I pick, and will continue to pick with my functional insecurities. Last but not least also thanks to Andrey, who’ll undoubtedly (he doesn’t know yet) will end up doing some reviews.

Functional Programming

Wikipedia defines Functional Programming as

In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids state and mutable data. Functional programming emphasizes functions that produce results that depend only on their inputs and not on the program state – i.e. pure mathematical functions. It is a declarative programming paradigm, which means programming is done with expressions.

The key ideas to keep in mind when doing functional programming are:

  1. Everything is a function
    As such we need to stop thinking about objects, classes, etc. other than for returning data or interop with the platform.
  2. Functions should be pure
    A pure function should always return the same output given the same input and should not depend on anything that is not directly the input (i.e. external data). It should also not cause any side-effects.
  3. We shouldn’t maintain state
    Shared state is the root of all evil. Or so they say. In any case, if we can’t really depend on state according to point 2, then why maintain it.
  4. We should consider input infinite
    Apparently it’s better, specially if we combine it with lazy evaluation. We’ll see the benefits at some point. Or at least I hope we do.

Benefits of Functional Programming

Seems there are many benefits to functional programming, including the ability to achieve concurrency more easily as state is not maintained, writing more concise code, and solving some problems which using OO paradigms might not be so straightforward.

But that’s what they say. I want to find out for myself. So until then, I’m going to take it all with a pinch of salt. Worse that can happen is that I end up looking at approaching problems in a different way, and that for me, is definitely a win.

We’ll see…

Kotlin as a functional language

Although Kotlin is far from being a purely functional language, it does have support for functions as first-class citizens and also allows for creating immutable data, so in principle it should suit our needs. If you’re coming from a Java or C# background, you’ll have little trouble getting used to Kotlin’s syntax. I already covered the basics of Kotlin in a four part series and while there have been some changes to the language, much of it remains the same. If you want to follow this series, you can use any flavor of IntelliJ or use the command line compiler with your favorite editor. But for heavens sake, if you choose the latter, let me not catch you using cursor keys.

Top-Level Functions

In Kotlin you can have a file and in the file declare any number of functions, much like you can with JavaScript. There’s no need for a static class or object. We can simply do something like

This function sits standalone, declared as part of a package, and can be used anywhere where the corresponding package is imported.

Immutable Data and Common Data Structures

Kotlin has shorthand for declaring properties on a class, be it a regular class or a data class (i.e. a DTO). When declaring properties we can either make them mutable (var) or immutable (val). To declare a data class with three immutable properties we could do

In addition to creating immutable data types, functional languages such as Clojure use a series of common well-known data structures, namely vectors, lists and maps, all of which are available in Kotlin and we’ll be using.

Until next time.

* I was born in Iran, raised in the UK till I was 10, and living in Spain ever since. Rob as far as I know was born and raised in the UK Isle of Man. Yet I feel a bond. Maybe it’s the Stilton cheese.

The Corporate Ladder

Microsoft uses a system to evaluate its employees, commonly referred to as stack ranking. To quote the article:

“The system—also referred to as “the performance model,” “the bell curve,” or just “the employee review”—has, with certain variations over the years, worked like this: every unit was forced to declare a certain percentage of employees as top performers, then good performers, then average, then below average, then poor. …”

It then goes on to express the views of an employee:

“The behavior this engenders, people do everything they can to stay out of the bottom bucket,” one Microsoft engineer said. “People responsible for features will openly sabotage other people’s efforts. One of the most valuable things I learned was to give the appearance of being courteous while withholding just enough information from colleagues to ensure they didn’t get ahead of me on the rankings.

Reading through this article, reminded me of a Pink Floyd track – Dogs.
In particular this verse struck a chord

“You have to be trusted by the people that you lie to
So that when they turn their backs on you
You’ll get the chance to put the knife in.”

Steve Ballmer somewhat defends this system:

“…I think everybody wants to work in a high-performance culture where we reward people who are doing fantastic work, and we help people who are having a hard time find something else to do”

but he does point out that it might need some tweaking. The problem is, tweaking is not going to fix this.

Climbing the Corporate Ladder

In today’s society, we have been led to believe that the key to success is climbing the corporate ladder.

Everyone starts at the level of their competence and works their way up, ultimately stagnating once they’ve reached their level of incompetence, resulting in some, spending the rest of their corporate life covering their own deficiencies.

This system does have its benefits. Employers are identifying those that shine, the leaders, the innovators, the ones with passion and ambition. The employees in turn, know that if they do well, they’ll be recognized. They’ll get a better position. They’ll have more money. They’ll be looked up to.

There is nothing wrong with having drive, ambition, aspiring to lead. Much like there is nothing wrong in recognizing those that do. People need to be appreciated. They need to know they’re doing a good job.

However, the ends do not justify the means. Becoming a manager at any cost, does not make one a leader. Leadership is something that one earns from the respect of their peers, not handed down to them by a supervisor.

When people are ranked using systems such as the ones Microsoft (and unfortunately many other companies) use, it leads to hostile and unhealthy atmosphere.  It leads to individualism over collectivism, with all the consequences that this entails. While in the short term this system might seem like a good idea, in the long run, it only benefits a few, and along the way, leaves a lot of collateral damage.

A Career Path is not about Promotions

This idea of the corporate ladder is so deeply rooted in our society that we have come to believe that by and large, the only real way for us to accomplish a successful and happy career is by being promoted.

I’d like to think however that as humans we are not so shallow in our ambitions. I’d like to believe that it is not only about what title we hold, but what it is that we do, and how what we do touches other peoples lives. It doesn’t matter what profession we have, someway or another we should make what we do matter, and do it in a selfless way.

Because if it is only about seeing how high we climb that ladder, once we reach the top, what will be the next step? I’ll leave you with another fragment from Dogs:

And in the end you’ll pack up, fly down south
Hide your head in the sand
Just another sad old man
All alone and dying of cancer.

All in the name of Pragmatism

Knowing what a Unit Test is
Knowing what an Integration Test is
Knowing what TDD is
Knowing the advantages
Knowing the disadvantages
Knowing what you gain
Knowing what you lose

Only then, can you be Pragmatic about applying the practices and techniques.

Knowing or not knowing what DDD is
Taking a couple of DDD patterns and saying you’re doing Pragmatic DDD is not Pragmatism and it’s not DDD.

Knowing or not knowing what REST is
Taking a couple of REST features and saying you’re taking a Pragmatic approach to REST is not Pragmatism and it’s not REST, half-REST nor nearly-REST.

In the name of being Pragmatic, you should not redefine definitions. And what is worse, it should not be your carte blanche to mislead others. Be responsible.

Creating Builders in Kotlin– The Results of the Kotlin Workshop

At the beginning of May, I held a Kotlin workshop at Skills Matter in London. The attendees had to go through a series of exercises to get familiar with Kotlin’s language constructs and then do two larger exercises.


Seeing that one of Kotlin’s benefits is the ability to design nice DSL’s, I proposed that they write a JSON Builder and a Build System (i.e. the next Ant, MSBuild, Rake,…take your pick).

We divided up into groups of three people per team and each went off their own way to design their own DSL’s.

Most managed to finish both exercises, or at least finish one and start the second. We were meant to vote on the winning DSL and they’d then get a prize (namely each member of the team would get to choose a license of one of our IDE’s). Unfortunately, 30 minutes prior to ending the class, some had to leave and then I mistakenly mentioned that Beers were happening in the Slaughtered Lamb and all hell broke lose. Moral of the story: we didn’t vote.

But I’m going to keep my word. I’ve managed to collect the outcome of the different teams (or what they managed to complete). I’ve presented them below (anonymously) and leave you all to vote for which one you like the best. The winning team will then receive their prize.

Exercise JSON Builder: Create a DSL to express JSON in Kotlin and output the result to actual JSON.

Exercise BUILD Builder: Create a DSL to define Build Scripts in Kotlin

(Teams are randomly ordered and might not have resemblance with actual seating during the workshop)

Team 1 – Finished the JSON Builder


Team 2 – Finished the BUILD System


Team 3 – Finished the JSON Builder and the BUILD System



Team 4 – Finished the JSON Builder and the Build System




Team 5 – Have not received any entries unfortunately.



Realizing that some participants have submitted both, others only one, and a couple none, just vote for whatever you like the most, be it the JSON Builder or Build system.

Voting will end Thursday 6th of June at 12 pm CET.


Results are in:

Winning Team, with 44% of the votes is Team 3. Close in second with 39% of the votes is Team 1.

Congrats to Team 3. Your licenses will be on the way (contact me if you’re one of the team members).


Thank you

I’d like to extend a thank you to all the participants for having taken part and a big shout out to Skills Matters for facilitating this workshop. You’re doing great things for the community.

Android applications with Kotlin

Did you know you can write applications for Android using Kotlin instead of Java? Here’s how, in one minute!

Converting to Kotlin

IntelliJ offers a series of features targeted at Android development, among these is the ability to quickly create Android Components:


For instance, selecting to create a new Activity will generate the corresponding XML layout, source file and update and the application manifest. Quite useful. The problem is though that the source generated is in Java, which isn’t an issue of course unless you’re working with Kotlin. However, you can easily work around this. Simply use IntelliJ’s helper to create the necessary components, then select the generated Java file in the Project window and from the Code menu click on Convert Java File to Kotlin File (there’s a different shortcut depending on your keyboard layout).


All this functionality is available in both IntelliJ Ultimate as well as the free OSS IntelliJ Community Edition, the same one Android Studio is built on.

Freedom to work

Yahoo has called in all their remote workers. Come June, they’re either sitting at desk in Silicon Valley or they’re looking for another job.

I’d be looking for another job. Not because of having to go the office everyday, but because they’re trying to solve the wrong problem. It seems like they feel if people are bound to a schedule, working in an environment where they can be controlled, everything will sort itself out.

Were I work, people set their own schedules. Whether they’re working from home or in an office. There are no office hours, no controls, no micromanagement. And yet it works. It works because of two main cultural values: respect and care.

Respecting the individual. Caring for the individual

Respect is not limited to treating people politely. It is respecting them as individuals, it is understanding that each person is different, works in different ways, has different challenges or circumstances that need to be dealt with. However, it is more than just acknowledging it, it is doing something about it. It is caring enough to want help.

Applying these values in a work environment between employer/employee, between team members is what makes the difference. And it makes a very important difference.

An employee needing flexible hours can either be faced by an employer who makes excuses about why it won’t work out or someone that is willing to help accomodate the employee. Helping this person out shows them that their employer cares enough about them as an individual. And if there is respect, this behaviour then becomes reciprocal.

These values needs to be applied to all aspects: between colleagues, teams, an individual’s work, the collective work, the project and on a more global scale, the goals of the company.

The culture of mistrust.

It is the feeling of respect and caring for each other, and the things we do that builds up and creates a relationship of trust.

Mistrust on the other hand emerges  as soon as you ask someone to clock in/out. When you ask them for detailed daily reports, you’re saying that you’re not sure if they’ve actually been working all day.  When you micromanage, you’re telling them, that not only do you not trust them, but you don’t respect them enough to be more than an insignificant cog in the machinery.

This creates tension. It leads to parties disrespecting each other. And as this happens, people stop caring. Why care about something you don’t respect? As a result, efficiency drops. Employers lose. Teams lose. The company loses. The individual loses.

It becomes another 9 to 5 job for a pay check.

Perks don’t buy respect 

A spokesperson for Yahoo writes:

[Marissa] Mayer is happy to give Yahoo employees standard Silicon Valley benefits like free food and free smartphones…”

Free donuts, constant flow of coffee and sodas are great. But if there is no respect, it means very little. Perks alone don’t buy respect or fulfil individuals. They are the icing on the cake. But there needs to be a cake.

Taking freedom away from people by forcing them into a 9 to 5 schedule on-site and then saying you’ll give them a mobile phone is not going to solve anything.

Care for people. Respect them. Give them the freedom to work. They’ll give you their best.