Performance guide and a design pattern, learning path

Learning Questions & Discussions Resources Chat/Questions
, , , ,
13

I will update this as I am watching because it’s a lot of info to cover:

This is my personal opinion on the video provided by @kokolegorille with the title Functional Design Patterns

Also feel free to offer feedback on this as i am editing thanks.

So I like very much how the gentleman Scott Wlaschin uses a Summary for his presentation and explains what to expect from his talk and what not. Then he uses familiar concepts to present what you can learn and how much deep, he will cover the topics that were in the summary.

Summary of the talk:

  • Core principles of Functional Programming design

    • Functions types and composition

  • Functions as parameters

    • Functions as interfaces
    • Partial application & dependency injection
    • Continuations, chaining & the pyramid of doom

  • Monads

    • Error handling, Async

  • Maps

    • Dealing with wrapped data

  • Monoids

    • Aggregating data and operations

So let’s start with the first part of the summary:

Core principles of Functional Programming design

  • Functions types and composition

The introduction to functions and the possibility of using them as input and an output was made very easy by using the analogy of fruits and also by providing an real world example later on.

Also the use of diagrams to represent the functions and how the data flows helped me understand better the principles of function composition.

Thus the following quote is born:

Composition can only be achieved using a single parameter function

The real world example was how an web application can be built from multiple functions that were composited together to form the final application.

I think a good analogy to composition would be building a snow man from snow. You can make different parts and then glue them together. Too form the whole snow man.

Types can also be put together or composited in a single big function and the analogy of the salad made this very easy to understand the function of AND. The OR function was also easy to grasp when the analogy of the snack was used to show the difference between the two.

The use case of OR and AND was present in a real world example related to card processing scenario which made the whole theory go into practice really nice.

Then we go to THE DESIGN BY TOTALITY

Using the types to enforce some rules really helped me to see the usefulness of guards from elixir here and also the need of constraints on data to handle each possible scenario so that my application doesn’t return unexpected results.

The second part:

  • Functions as parameters
    • Functions as interfaces
    • Partial application & dependency injection
    • Continuations, chaining & the pyramid of doom

Creating function using generic and parameter-ize everything for a dry code really impressed me and offered a good example of what decoupling can do.As a result the function become much more flexible and the DRY principle took charge.

The functions as interfaces part really change the way I was thinking about sharing the same functions with other functions. Basically if we have multiple functions that need the same data types then an interface is a good way to keep the code DRY. Probably that the equivalent in elixir for this part would be the behaviors specifications.

Then we go to THE STRATEGY PATTERN

That adds and extra parameter to function that leads to another function that contains the strategy.

Then we go to THE DECORATOR PATTERN

That makes sure that the first function and the last function keep there expect types. An example offered in this talk was like this

int is_even bool

So between the int there is a function is_even and it expects a result in a type of the bool true or false. But it’s can’t return a result of a different type like string or int.

And no matter how many compositions o function i make the input should be an int and the result should also be returned as a bool.

I think this part is similar to guard in elixir where only certain types can be returned.

So every function is a single parameter function in functional programming

Then the author provides some examples to prove that what he stated above is true and the following qoute is born:

Every multiple parameter function can be converted into a single parameter function

Then we go to THE PARTIAL APPLICATION PATTERN & DEPENDENCY INJECTION

Chunks of the function are taken out and converted once again into a SINGLE PARAMETER FUNCTION

Then to demonstrate this pattern in a real example using the retrieval of a customer from the database.

Also in this example appears the PERSISTENCE IGNORANCE, which can be translated as I don’t care from which source my data comes. In our example we don’t care if the Customer comes from server or a cache.
As far as i know elixir doesn’t have something similar for dependency injection. The closest Thing i could find was this post How to use dependency injection pattern in Elixir? - #3 by kostonstyle.

Then we go to the sow on the road with THE HOLLYWOOD PRINCIPLE’*': continuation PATTERN

Also known as DON’T CALL US WILL CALL YOU

Then we visit the pyramids of doom, doesn’t sound like dungeon of the game, weird right? But it is not game, it’s the multiple null check hell or nested null. In elixir we use a monad every time when we define a module or a function and that is the… you guessed it the DO.

Also monads can be defined as chaining continuation.

Then this hit me in the video:

How do we combine mismatch functions?

We glue them together using bind

Bind all the things

So transforming a one input and 2 outputs in match of 2 inputs and 2 outputs will allow us to convert the pyramid of doom into single parameter function. Well that is good but what do we do in elixir, we don;t have bind could we use cond?

Then the author goes in demonstrating this principle using an error validation on certain database transactions.

OK so now we go on a train ride because this type of solving this particular problem is called by the author Railway Oriented Programming

So what can I say as an ending. Definitely a nice talk in an easy and fun way to look at FP principles and some patterns that could be used in different situations.

A must see video for an easy introduction to FP(Functional Programming) Programming

Thanks @kokolegorille for showing to me this video.

Also If i made some mistakes let me know and i will correct them.

Time for me to fly, I hope that my insight would be enjoyed by others.

3 Likes