TODAY SOFTWARE MAGAZINE
working with binary protocols which is one of Erlang’s strong points. All the above techniques give us the possibility to write a very clear and concise code. This is the reason why the modern imperative languages have adopted functional techniques.
Purely Functional Languages
A purely functional language is a functional language where data structures are immutable and the functions don’t produce undeclared side effects. Languages such as Haskell or Clean separate the pure functions from the impure ones, but they use different approaches. In Haskell, a monad describes the way in which a sequence of impure functions having a certain type of side effects is executed. There is a different monad for every type of side effects. Therefore all the functions having input/output effects are executed in IO monad; all the functions modifying external state are executed in State monad etc. In order to get side effects, a function needs to be executed in that particular monad. As a result, the compiler returns an error if a function which is not in monad X calls another function with side effects of type X. In Clean, the impure functions which alter object state get those objects as “unique objects”. A unique object can be used only once. Consequently, once a function has altered a unique object, it returns the new version of the altered object, besides the normal return value. The function caller continues to use the new object, the compiler forbids the use of the old one.
Conclusion Advantages
First, functional languages make available several high level tools that increase productivity. Then, in purely functional languages, the fact that side effects are very clearly localized help the programmers write more robust code. This prevents from discovering that, besides returning arguments product, a “product” function also writes the result in a file. This separation can be guaranteed by a compiler. As a result, the clarity and quality of the written code is improved. They say, in Haskell compilation is the most difficult part, and once a code is compiled, it is bug free. Surely
it is an exaggeration, but partly it’s true. The typing system is so well designed that errors which are normal for other languages are spotted at the compile time. With impure functional languages, side effects may appear, but generally they are deterred, and the functional work style makes developers aware of their presence. Another advantage of working with pure functions is that testing, refactoring, parallelism and various optimizations become much easier. This issue was discussed upon in the previous article of this series. Even if we don’t use purely functional languages, parallelism is much easier if a functional working style is adopted. Languages such as Erlang, Clojure, F#, Haskell are known for the easiness of writing parallel application. The “many-core” tendency in nowadays hardware architectures asks for more parallelism and estimations show the numbers of cores in a “standard” processor will double every 2 years. This means that in a very near future we will be working on systems with tens or hundreds of cores. The applications will only be able to take advantage of the large number of cores if their architecture allows massive parallelism and processing on tens, hundreds or thousands of execute strings. As an example, in Erlang, applications with tens or hundreds of thousands of threads occur frequently during production. It’s pretty obvious that the most appropriate languages for writing heavily parallel applications are functional languages which frequently make parallelism almost trivial.
Disadvantages
The general perception is that functional languages have a lower performance. It’s only partially true. Generally, using a functional working style, structures of immutable data are used, which are less efficient. For example, modifying an element in a list implies: 1. Creating a new list with the same elements from start until before the modified element. 2. Creating a new loop with the new value of the element. 3. Integrating the new loop on the existing list. Modifying the immutable list is more expensive both in CPU time and in memory usage. On the other hand, there
is the advantage of not needing the synchronization. The original list stays the same and its other users are not affected at all. This is a benefit if those users are in different execution threads or on different machines. Though, we have the possibility to use mutable data structures where necessary even in a functional language. So we can identify areas with performance problems and change the elegance and the robustness of the functional code for the performance of the imperative code, when it is really needed. So the statement that functional languages are weaker from the performance’s point of view is false. The data structures used make the difference. Regarding the performance, there are pretty frequent the situations when the applications originally written in imperative languages and then rewritten in functional languages such as Haskell, Ocaml or F# are at least as fast as the original implementation, but with a smaller and more robust code. Another problem would be the fact that in the “lazy” functional languages (ex Haskell) it is difficult to estimate how long a certain operation will take. This is a problem especially in soft-real-time systems. Yet, the main problem which slows down the adoption of functional languages is the fact that programmers have to change their way of thinking. In the functional approach the problem is “what does the application?” and not “how it does it?” Thinking like this, the need to produce side effects disappears in most of the code, excepting those components that interact with the surrounding imperative world. In spite of that the industry makes more and more space for functional languages. These are a few examples: very popular applications like RabbitMQ, CouchDb, Riak or Ejabberd have been written in Erlang, Haskell which is used more and more frequently in applications in which code quality is essential and on JVM and .NET platforms F# and Clojure have a growing user base.
www.todaysoftmag.com | nr. 2/2012
17