Purely Functional Programming Disadvantages

You may have read the stories in which “scala developers” explain how beneficial it is to rely on functional programming. But this post is different as developers will explain limitations of purely functional programming. Let’s read:

Persistent data structures or purely functional structures can be a great tool. They offer persistence which means developers have facility to reuse the old versions of collections with no worry about mutation.

But persistence comes at a great cost when we talk about performance.

For some applications, this is slower than the programmers believe.

#1. No availability of Functional Unsorted Dictionary / Set

There is no availability of functional unsorted dictionary or set. Since the 1990s, the use of dictionaries in development of software has gone through the roof. Today, dictionaries are a stock collection type that every developer/ programmer expects to have in his standard library.

Most functional programming languages including Scala, Haskell, and OCaml are unable to express a fast generic mutable hash table as these languages do not have the killer combo of reified generics, fast GC write barrier, and value types.

#2. No availability of Purely functional weak hash table

There is no availability of purely functional weak hash table. With garbage collected imperative language, developers and programmers are able to express the relationships between the edges and vertices of a graph with weak hash tables. There is no purely functional weak hash table available, so developers need to write their own garbage collector.

#3. No purely functional concurrent collections

Immutable collections cannot support concurrent mutation. If programmers require a shared mutable collection like in-memory database, there is no such efficient purely functional solution available for them.

#4. Traditional imperative data structure inertia & algorithms

Imperative programmers have facility to build upon the backs of giants but purely functional programmers are those who start from scratch.

#5 Purely functional programming is bad

Purely functional programming is bad for parallelism performance in practice. Programmers have two reasons to write parallel programs today. One is to write objectively fast solutions and other is to make a slow solution less slow.

Programmers need to ensure in parallel programming that the gain from parallelization compensate the admin overheads of running code in parallel. With Haskell, it becomes tough.

You need to beware of the people who only know to talk about scalability and forget the absolute performance. Scalability can be enhanced by redundantly recomputing the Mandelbrot set after each code line for no reason as maximum time will be spent in parallel code.

#6 A lot of myths about functional programming

Turning off the garbage collection to enhance performance of hash tables in Haskell is one of these myths.

For more information about the subject, you can Ask Scala Programmers. This article was issued by proficient programmers who code and design great applications for businesses. You can share your thoughts and views about this post with the author. If you have any doubt or did not get any point in the post, kindly comment and tell the professionals.