Functional Programming

In contrast with object-oriented programming (OOP), functional programming (FP)—as the name implies—emphasizes functions over data. The basis for OOP is to define specialized data structures, classes, for the problem at hand and then tie functions to those structures in the form of methods. FP prefers more generic data structures and smarter functions that can operate on those structures. This along with the ability to treat functions as data and use them as input to other functions give a different kind of flexibility as compared to OOP. Either paradigm can be used to emulate the other, making them basically equivalent. Certain problems, however, might be easier to reason about and solve by using one or the other. “Traditional” OOP languages still rank high in various programming language popularity indices. This might change however, if the current trend towards functional programming continues. With Clojure and Scala on the JVM and F♯ on the .NET platform, interest in FP is definitely on the rise. Through the addition of lambdas—anonymous functions—to both Java and C++ FP concepts are creeping into OOP languages as well. Hybrid or multi-paradigm languages seem to be the next stage in the evolution of programming languages.

Important FP Concepts

All concepts mentioned below can be found in OOP as well, but they are generally more prominent in FP languages.

a. Higher order functions - A function that take other functions as input. An example is map that takes a list and a function as input, applies the function to each item in the list, and returns a list of the results. This is equivalent to an imperative for-loop that steps through each item in a list and applies a transformation.

b. Lambda - An anonymous function, often created on the spot as input to a higher order function. A convenient way to pass code around as data.

c. Recursion - Often the only way to perform iteration, or looping, in a functional language. Many language implementations provide tail call optimization, or tail recursion, which enables an iterative process to be written recursively while still only requiring constant memory. This also allows endless loops to be written in a recursive fashion. Some languages, for example Scheme mandate tail call optimization for all implementations.

d. Immutability - Once a value has been created, it cannot be changed by any means. The member data of OOP objects is often mutable, which means that querying the same object for its state at different times can give different answers. An immutable value on the other hand always guarantees the same answer. To “change” an immutable value, a copy must be made and the change performed as a transformation during the copy operation. Immutable data solves some of the problems related to concurrent programming, but it is not a silver bullet.

Erlang

The Erlang programming language has seen a relatively recent increase in popularity thanks to the likes of WhatsApp and Klarna. The language was developed at Ericsson in 1986 for use in telephone exchange systems. This specialized use case made certain properties highly
desirable: concurrency, asynchronous message passing, fault tolerance, and live updating of running systems. Erlang was designed with these properties in mind, which led to a language capable of creating highly reliable systems. Erlang began its life as a proprietary language, but was released as open source in 1998. The same features that made it a good fit for telephone exchanges also turned out to be useful for other massively concurrent systems. The WhatsApp messaging system, written in Erlang, can handle over two million concurrent TCP connections.

Language Features

Erlang code is compiled to bytecode and runs on a virtual machine. The de facto standard implementation is called BEAM (Bogdan/Björn’s Erlang Abstract Machine). The sequential parts of Erlang are functional. All values and variables are immutable and
recursion is the only loop construct. It is dynamically typed and garbage collected. Erlang has language level support for spawning concurrent processes (threads) within the virtual machine. These processes have no shared memory and can only communicate by sending
and receiving asynchronous messages. This communication works the same way for communication between networked Erlang nodes running on different computers, making distribution completely transparent. Processes are extremely lightweight and running upwards of 30000 concurrent processes is not uncommon.

Elixir

Elixir is a dynamic, functional programming language created by José Valim. It targets the Erlang virtual machine (BEAM), which gives it the same properties of scalability, distribution and fault-tolerance that has made Erlang famous. The language is very young, the first commit. in the Git repository is dated January 9th 2011 and version 1.0 was released as recently as September 18th 2014. Thanks to a solid foundation in form of the Erlang ecosystem and the addition of tools for building, testing, package management, and documentation, Elixir
already feels very polished and developer friendly. With Valim being a prolific Rubyist and one of the top contributors to Ruby on Rails it is not unexpected that Elixir’s syntax is heavily inspired by Ruby. Parenthesis on function calls can be omitted and blocks are delineated with do...end

The general structure still stays close to Erlang, making it easy to move between the two languages. On top of that Elixir adds macros in the lisp sense, which allows for advanced metaprogramming, and protocols for polymorphism. Another smaller addition that nonetheless can make Elixir code look quite different from Erlang is the pipe operator |>. The expression foo |> bar means to evaluate foo and add the result from that as the first argument to the function call bar. This makes it easier to chain function calls in a way similar to object-oriented method chains.

Concurrency

Like Erlang, Elixir provides concurrency through processes and message passing. The default position of no shared state between processes removes a whole class of problems traditionally associated with concurrent computing. No shared state means no need for explicit locking
through semaphores or other means. Unfortunately, problems such as deadlock and livelock still persists. Message passing also lends itself well to an asynchronous programming style. This does however mean that synchronous communication is harder, necessitating the creation of custom
message protocols.

References

http://elixir-lang.org/

https://redmonk.com/sogrady/2015/01/14/language-rankings-1-15/

http://www.langpop.com/

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

http://clojure.org/

http://www.scala-lang.org/

http://fsharp.org/

http://joeduffyblog.com/2010/07/11/thoughts-on-immutability-and-concurrency/

https://blog.whatsapp.com/196/1-million-is-so-2011

http://engineering.klarna.com/article/klarna-engineering-insights/

http://www.erlang.se/publications/bjarnelic.pdf

https://pragprog.com/articles/erlang

Highly Educative. Thanks