Functional Programming

When you start learning a programming language(or just programming in general), usually there are first few chapters in books that introduce us such thing like data types (or just types). And we don't focus on this subject as much as we should because it's so simple, right? Well… I think that there is one little detail which can lead to big mistakes of understanding what really data type is.

Recently I wrote an article What is Reactive Programming? iOS Edition where in a simple way I described how to build your own Reactive Framework, and helped you to understand that no-one should be scared by the reactive approach. The previous article could now be named How to cook reactive programming. Part 0., since this is a continuation. I would recommend reading the previous article if you are not familiar with the reactive programming concepts.

Being a developer, I love to code especially in JavaScript. As per my experience, using reduce function is one of the toughest tasks in JS. Let me first elaborate on the Reduce concept!

In Wikipedia, it has many names viz.

Reduce
Fold
Accumulate
Aggregate
Compress

It is a function that folds a list into any data type. It's all about breaking a structure down into a single value. It's like folding a box! With reduce, you can turn an array [1,2,3,4,5] into the number 15 by adding them all up.

In this article, I would like to propose an alternative to the traditional test design style using functional programming concepts in Scala. This approach was inspired by many months of pain from maintaining dozens of failing tests and a burning desire to make them more straightforward and more comprehensible.

Even though the code is in Scala, the proposed ideas are appropriate for developers and QA engineers who use languages supporting functional programming. You can find a Github link with the full solution and an example at the end of the article.

In my previous article I described how to achieve the "Maybe" monad behavior using async/await operators. This time I am going to show how to implement another popular design pattern "Reader Monad" using the same techniques.

That pattern allows implicit passing some context into some function without using function parameters or shared global objects and it can be considered as yet another way to implement dependency injection. For example:

class Config { public string Template; }

public static async Task Main()
{
    Console.WriteLine(await GreetGuys().Apply(new Config {Template = "Hi, {0}!"}));
    //(Hi, John!, Hi, Jose!)

    Console.WriteLine(await GreetGuys().Apply(new Config {Template = "¡Hola, {0}!" }));
    //(¡Hola, John!, ¡Hola, Jose!)
}

//These functions do not have any link to any instance of the Config class.
public static async Reader<(string gJohn, string gJose)> GreetGuys() 
    => (await Greet("John"), await Greet("Jose"));

static async Reader<string> Greet(string name) 
    => string.Format(await ExtractTemplate(), name);

static async Reader<string> ExtractTemplate() 
    => await Reader<string>.Read<Config>(c => c.Template);

Generalized async return types — it is a new C#7 feature that allows using not only Task as a return type of async methods but also other types (classes or structures) that satisfy some specific requirements.

At the same time, async/await is a way to call a set of "continuation" functions inside some context which is an essence of another design pattern — Monad. So, can we use async/await to write a code which will behave in the same way like if we used monads? It turns out that — yes (with some reservations). For example, the code below is compilable and working:

async Task Main()
{
  foreach (var s in new[] { "1,2", "3,7,1", null, "1" })
  {
      var res = await Sum(s).GetMaybeResult();
      Console.WriteLine(res.IsNothing ? "Nothing" : res.GetValue().ToString());
  }
  // 3, 11, Nothing, Nothing
}

async Maybe<int> Sum(string input)
{
    var args = await Split(input);//No result checking
    var result = 0;
    foreach (var arg in args)
        result += await Parse(arg);//No result checking
    return result;
}

Maybe<string[]> Split(string str)
{
  var parts = str?.Split(',').Where(s=>!string.IsNullOrWhiteSpace(s)).ToArray();
  return parts == null || parts.Length < 2 ? Maybe<string[]>.Nothing() : parts;
}

Maybe<int> Parse(string str)
    => int.TryParse(str, out var result) ? result : Maybe<int>.Nothing();

Further, I will explain how the code works...

I once had a discussion with a founder of an Israeli startup developing a GPU-based database with a focus on speed. The work stack included Haskell and C++, among others, and the founder was complaining about how hard it is to find competent programmers. Which was part of the reason he came to Moscow.

I carefully asked if they considered using something more popular and new. And even though the answer was rather polite and well-supported with arguments, it still sounded like “Come on, don’t even bring up these toys”.

Until then, all I heard about Haskell could be summarized as “be VERY careful in dealing with it”. To get to know Haskell programmers better, I came to a topical Telegram chat with some questions. I was quite afraid at first, and, as it turned out, I was right.

Haskell doesn’t lend itself to popular explanation, and people seemingly don’t even try. If the topic is ever brought up, it’s only talked about in full depth and as objectively as possible. Someone wrote to me: “One of the defining features of both Haskell itself and its community is that they didn’t try to achieve any kind of mainstream recognition. Instead, they focused on building a logical, principal way of solving real problems over trying to appease the widest audience possible”

Nevertheless, a couple of people did tell me about their experiences, which are shown below.

We’re excited to announce that Visual Studio 2019 will ship a new version of F# when it releases: F# 4.6!

F# 4.6 is a smaller update to the F# language, making it a “true” point-release. As with previous versions of F#, F# 4.6 was developed entirely via an open RFC (requests for comments) process. The F# community has offered very detailed feedback in discussions for this version of the language. You can view all RFCs that correspond with this release here:

• F# 4.6 RFCs
• FSharp.Core 4.6.0 RFCs

This post will detail the feature set and how to get started.

In this article I'm going to tell you about one of the currying options and partial application of the functions in C++ which is my personal favourite. I'm also going to show my own pilot implementation of this thing and explain the point of currying without complex mathematical formula, making it really simple for you. We'll also see what's under the hood of kari.hpp library which we'll be using for currying functions. Anyway, there are lots of fascinating stuff inside, so welcome!