Thanks i will watch it and come back with my impressions, if that is alright.
wolfiton
wolfiton
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
wolfiton
Also if someone can point out the elixir equivalents in this talk i would be very grateful.
1
kokolegorille
The author of the talk is also the author of…
After watching this talk, I bought the book, even if it has only F# code
I tried to translate types in this post Type and spec - Dialyzer not detecting error
But it’s hard to compare type_spec with F# type system 
3
wolfiton
mkunikow
kokolegorille
We don’t
the Elixir way is to use with do… end
As mentionned, F# belongs to ML family, while Erlang is FP only to facilitate CSP.
To quote Joe Armstrong in a previous post, Forget about monads, at least in Erlang/Elixir.
0
dch
The most significant thing I have learned is to understand the concurrent flow of data through your system – a common mistake is to throw GenThingies at every piece of data; Elixir is not an OOP environment.
So, for example, data flows into your system from HTTP request, or from some database call. At this point, your DB layer or HTTP server will probably have a function invocation per request.
Ensure that each request can be processed through as many functions as possible – not processes as possible. Each move of data between processes, and possibly GenServers, is another opportunity for copying data, moving things into mailboxes (a singleton queue), and slows you down.
Make sure you know what each function is doing, for example ConCache is excellent, but you need to be aware that it is using ETS tables behind the scenes. ETS requires copying data in & out of the heap. Other modules will have GenServers with a functional interface - usually for good reason, but again, another opportunity to block things in mailboxes/queues if that GenServer is handling multiple user requests itself.
If all your data flows smoothly through functions, minimising process changes, then this allows the BEAM to maximise its performance without needing to shuffle data around in memory.
Make it work, then make it beautiful, then if you really, really have to, make it fast. 90% of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!
—Joe Armstrong
Wiser words than that are harder to find around here.
1