Skip to main content

Functional Programming in Scala for Working Class OOP Java Programmers - Part 1

Have you ever been to a scala conf and told yourself "I have no idea what this guy talks about?" did you look nervously around and see all people smiling saying "yeah that's obvious " only to get you even more nervous? . If so this post is for you, otherwise just skip it, you already know fp in scala ;)
This post is optimistic, although I'm going to say functional programming in scala is not easy, our target is to understand it, so bare with me. Let's face the truth functional programmin in scala is difficult if is difficult if you are just another working class programmer coming mainly from java background. If you came from haskell background then hell it's easy. If you come from heavy math background then hell yes it's easy. But if you are a standard working class java backend engineer with previous OOP design background then hell yeah it's difficult.
Scala and Design Patterns
An interesting point of view on scala, is looking at it's set of features as design patterns. This is exactly what Ivan Nikolov says in Scala Design Patterns . He actually shows how the hybrid nature of the scala programming language also makes some of the traditional object-oriented design patterns obsolete, or possible, using other cleaner techniques in his great book. While I fully agree with him, I recognize that it's going to take lot of time going over all the standard design patterns and not only the standard ones but also many of th enon written patterns, best practices, and seeing how the match in the scala programming language.
Scala Design Patterns
Let's start with the terminology, monad, semigroup, functor, typeclass, higher order functions, higher order types, partially applied functions, partial functions, are you still with us? If you already know the above concepts then this post is not for you but if you don't then heck yeah, but I have no chance of going through them in a single post, so stay tuned for the next post.
Example, is it simple
Question, is the below code easy?
  object Request {
    def pure[A](a: A): Free[Requestable, A] =
      Free.liftFC(Pure(a) : Request[A])

    def fetch[A](service: Service[A]): Free[Requestable, A] =
      Free.liftFC(Fetch(service) : Request[A])
Not for me, what are all those "Free", "lift", "pure", what are the generics doing there? I can find thousands of examples like this, just search google for the cool FP terminology, this is our target to decompose this structure, to clear out the fog.
I think if you want to learn scala you first need to learn haskell or something else and only then get to scala. It looks like its very difficult to first get to these concepts by scala. And yes when I need to learn a concept in scala guess what I first learn it in haskell and only then get to scala. if haskell would only have all java libraries and run on jvm...
FP is very important
But FP is very important, concurrency, better code, big data, parallel computing, better testing. I mean FP is the thing for a programmer who want's to write clean code with a clean pure core and all the IO surrounding it, it's the dream of clean code, so we are going to make that effort.
The good thing about FB
The good thing about FP is what makes all the problem and noise. With FP you use pure functions, this I assume we all know what it means. The problem is that real world applications are not pure, they have side effects. And this is where much of the complexity comes into play, this is the challenge, in addition you don't mutate things, so you start using recursion :)
The benefits of imperative programmers
Before i'm getting assassinated by functional programmers I want to tell you this, there are good things about imperative programming. If you have some basic sanity of clean code practices and you write well organized and clean code with imperative programming, (small functions, mutation where needed but not always), you use for loops instead of map/flatMap twin brothers. Then you know what? you use the java util concurrency building blocks and non blocking io also with multithreading, you can write excellent applications which have high performance utilization, I know this from first hand, I wrote many such apps some with very high scale demand, and i have to say that for other programmers without majour knowledge in FP those imperative programs were much easier to understand than their FP mirror brothers and sisters programs. So imperative is also good. But we are here to get to FP not to imperative. And this is the route we are going to take.
Declarative vs Imperative
So the first step is to understand what declarative code means.
I like jenkov article "The illusion of declarative code". He presents the below imperative code:
function capitalWithInterest(capital, interest, periods) {
    var result = capital;
    for(var i = 0; i < periods; i++) {
        result = result * (1 + interest);
    return result;
Now he asks what is the declarative version of that code? and he answers:
var result = capitalWithInterest(100, 0.1, 5);
Here - it's declarative we didn't say imperatively how we want to calculate capital with interest we have just told the computer that we want it to calculate for us the capital with interest.
Declarative code with scala
So in scala the most common example of declarative code is by using "map" and friends instead of for loops, for loops are the explicit imperative way to tell the computer how to do the loop and map and friends are declarative you just tell the computer go over the items on this list and subtract 2 from each
val listOfNumbers = List(1,2,3) - 2).foreach(println) 
So in this case instead of imperatively going through the list and printing each we tell odersky, hey please for each item in the list (map) please subtract two and for each item print it (after you subtracted 2 from it)
Functional Programming and Immutability
Because in functional programming we would rather have pure functions, then, there is a consequence to that the consequence, is that we use immutability more nad more, as much as we can in favour of mutable data structures. In the great book Scala Design Patterns by Ivan Nikolov, the author says, quote: "Immutability is an important principle in Scala and it should be preferred. The builder design pattern with case classes uses immutable fields and this is considered a good practice.". And yes case classes which inherit from sealed traits are not only a great way to model your data, they help extensively with using immutable data structures instead of mutable.
We have just touched the tip of the iceberg here, but don't worry before global warming takes it's place and metls the iceberg we are going to hit upon all the concepts you wanted to know about scala but had nightmares about free monad, managing state, functors and friends.


  1. Thanks for spending all your pleasant time to make such a Creative content for us. AWS Training in Chennai


Post a Comment

Popular posts from this blog

Dev OnCall Patterns

Introduction Being On-Call is not easy. So does writing software. Being On-Call is not just a magic solution, anyone who has been On-Call can tell you that, it's a stressful, you could be woken up at the middle of the night, and be undress stress, there are way's to mitigate that. White having software developers as On-Calls has its benefits, in order to preserve the benefits you should take special measurements in order to mitigate the stress and lack of sleep missing work-life balance that comes along with it. Many software developers can tell you that even if they were not being contacted the thought of being available 24/7 had its toll on them. But on the contrary a software developer who is an On-Call's gains many insights into troubleshooting, responsibility and deeper understanding of the code that he and his peers wrote. Being an On-Call all has become a natural part of software development. Please note I do not call software development software engineering b

Containers - Quick Low Level Guide

Containers Kernel, namespace, cgroups Kernel space and user space Before we actually get to explain containers let's define what is a kernel.  Because you know there is no such thing in reality as a kernel it's only how we name things, and different people name things differently. cgroups, namespaces, UFS We are going to discuss containers, cgroups, namespace, UFS, hypervisor, user space, kernetl space and more.   When we say "kernel" we mean this.  We have the hardware, this is not the kernel, now above the hardware we have a few layers of software, imagine now two boxes. User mode is all the application you run while the kernel is the lower level is all the virtual memory management scheduling, connection to hardware devices, network drivers, it's basically the abstraction on top of the hardware + the basic services which allow this. One box is closer to the hardware and contains a few layers, the second box sits on top of the kernel box and contains

Recursion Trees Primer

Recursion trees. Controlling the fundamentals stands at the cornerstone of controlling a topic.  In our case in order to be a good developer its not enough or even not at all important to control the latest Java/JavaScript/big data technology but what's really important is the basics.  And the basics in computer science are maths, stats, algorithms and computer structure. Steve wosniak the co-founder of apple said the same, what gave him his relative advantage was his deep understanding of programming and computer structure, this is what gave him the ability to create computer's which are less costly than the competitors (not that there were many) and by the way there were 3 founders to apple company one responsible for the technical side, one for the product and sales (Steve Jobs) and the third responsible for the company structure and growth, each of the three extremely important, it was not only the two Steve's but that's a topic for another episode. And with t