lambda.png

I don’t know if it is only me who is feeling like this, but my personal career shows me a hype back and forth in the last 15 years.

I started my career with C/C++ but mostly writing C on Linux, Solaris, and HP/AIX machines. So programming mostly functional, but we do not have these great lambda functions or super-duper data structures.

After 5/6 years, everybody was talking about the OOP and SOLID principles. So, I was pulled by JAVA first to build some UI driven applications. In 3-3 years later C#/.NET is another hype and I find myself writing WebForms applications using C# and WebAPIs using JAVA. It continued like these for about 5 years.

Nowadays, mostly writing JavaScript and NodeJS applications. Reading articles about Pure Functions, Closure, Lexical Scope, and Composition in Functional Programming everywhere. Those topics were mostly discussed when I was writing C.

So for me, it is the Rise of Functional Programming or FP strikes back. In good old days, we did not have arrow functions in C like in JavaScript but, we can mimic all the way down with pure ANSI C. OR a great map function but we do have for loops anyway.

I am not a computer scientist but a software engineer, so my general purpose is not investigating what are the best implementation of Pure functions or Closure. I need to make use of them in practical applications and provide reasonable quality, for a reasonable price in a reasonable time period.

OOP vs FP

For me, it is not the war between FP and OOP, it is not my concern which one is best. The best one depends on the requirement of the application and only be driven by it. I saw badly implemented classes and also seemingly bad implemented functions. So it is not the programming paradigm that makes the application bad, but it is us, the programmers.

Now, as a relatively experienced Software Engineer, I have issues to tell these functional programming concepts to developers, who are born into Object-Oriented programming.

Let’s consider a practical example of closure and lexical scope in JavaScript. (ES5 Version)

1
2
3
4
5
6
7
8
function Greet(name){
return function Punctuate(punctuation){
return `Hello ${name}${punctuation}`;
}
}
const greetVolkan = Greet('Volkan');
console.log(greetVolkan('!'));

Here for an unexperienced - born into OOP - JAVA or C# developer, this implementation looks like impossible. For an experienced one, they can implement this but with a cost which does not make much sense for them, if they do not know the primary concepts like curry functions. I mean no blame or offense here, OOP does not generally drive this.

Here let me show you what I mean by looking at the same implementation of above code with C#

1
2
3
4
5
6
7
public Func<string, string> Greet(string name)
{
return new Func<string, string>((punctiation) =>
{
return $"Hello {name}{punctiation}";
});
}

Still easier for a C# developer to read but I haven’t seen anyone using this at all. Generally, if I ask a functionality like this, I would probably get the below code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Greeter
{
public string Name { get; private set; }
public string Punctuation { get; private set; }
public Greeter(string name, string punctuation)
{
this.Name = name;
this.Punctuation = Punctuation;
}
public string Greet()
{
return $"Hello! {Name} {Punctuation}";
}
}

Here the disadvantage is that in this C# code the Greet or Greeter is not reusable enough, but it doesn’t matter for most of the C# people since the name is a parameter and this is an ok enough implementation. We can discuss this on comments but I will switch to the topic of how hard to tell a developer who hasn’t seen Functional Programming times.

Consider the ES6 version of the same implementation, which totally does not make any sense at all to a C# dev. Here by means of functionality of functions, ES6 version exactly does the same thing as the first ES6 version. Although, there is a big difference on how they handle the this. This is for another post though.

1
const GreetES6 = (name) => (punctuation) => `Hello ${name}${punctuation}`;

I hear from C# devs that this is not readable at all. If you have not done any functional programming in the past, it is not. But for those who had, it is even much more readable than the first JavaScript version.

Another important part of this is, in C#, since it is compiled and scope is validated while you are building the code, you do not need to consider how the name parameter is available in your Greet method. (Consider first C# version of Greet) Even worse, most inexperienced OOP guys using JAVA or C# doesn’t even know about scope let alone this is lexical scope. This makes life hard when you start working with pure OOP developers.

So let’s look at our code and try to understand the lexical scope.

Lexical Scope

In our Javascript code, we have a function that returns a function. More specifically Greet function returns a Punctuate function. The problem here is that the returned function uses the name parameter of the Greet function. If you only consider the block scope, the name is undefined for our returned function. So, how this is happening… Basically, JavaScript is handling the problem for us and even the scope of Greet and Punctuate finalized, JavaScript still enables the name variable for the returned Punctuate function.

Summary

Functional and Object Oriented Programming is a totally different way of thinking and the understanding of scope differences is only one of the milestones. I will try to clarify more concepts for pure object oriented mindsets since nowadays Functional Programming strikes back.