Functional thinking: Why functional programming is getting more attention

So far, in each installment of this series, I've explained why it's important to understand functional programming. However, some of the reasons are explained in a number of articles, and only in the larger context of a comprehensive approach can we fully understand these reasons. In this installment, I'll explore all the reasons why functional programming is in the ascendant and synthesize some of the personal lessons from previous installments.

In the short History of computer science, the mainstream of technology sometimes produces branches, including practical branches and academic branches. The 4GL (fourth generation language) of the the 1990s is a practical branch, and functional programming is an example from academia. Every once in a while, there are branches to mainstream, as is the case with functional programming. The functional language is not only on the JVM's feet (two of the most interesting new languages are Scala and Clojure), but it is also starting to be applied on the. NET platform, where F # is a first-class citizen. Why is it that all platforms welcome functional programming? The answer is that, over time, developers have been able to cede more control over their day-to-day tasks as the runtime is able to handle more busy work.

Control of cession of power

In the early 1980s, when I was in college, we used a development environment called Pecan Pascal. Its unique feature is that the same Pascal code can be run on the Apple II or IBM PC. Pecan engineers used something called "bytecode" to achieve this feat. The developer compiles Pascal code to "bytecode", which can be run on a "virtual machine" that is written locally on each platform. This is a terrible experience! The generated code is painfully slow, and even a simple class assignment is very slow. The hardware was not ready to meet the challenge.

In the decade following the release of Pecan Pascal, Sun released Java,java using the same architecture, which was a bit strained to run the code for the the mid 1990s hardware environment, but eventually succeeded. Java also adds other developer-friendly features, such as automated garbage collection. After using a language like C + +, I never want to write code in a language that has no garbage collection. I would rather spend my time on abstraction at a higher level, thinking of ways to solve complex business problems, than wasting time on complex plumbing issues such as memory management.

Java eases our interaction with memory management; The functional programming language enables us to replace other core building blocks with high-level abstractions and to focus more on results rather than steps.

Results are more important than steps

One of the features of functional programming is the existence of powerful abstractions that hide many of the day-to-day operational details (such as iterations). One example I've been using in this series of articles is a numeric taxonomy: Determining whether a number is perfect, abundant, or deficient (see the first installment for a complete definition). The Java implementation shown in Listing 1 solves this problem:

Listing 1. Java Digital classifier with a total cache size

Import static java.lang.Math.sqrt;
    public class Impnumberclassifier {private set<integer> _factors;
    private int _number;
    
    private int _sum;
        public impnumberclassifier (int number) {_number = number;
        _factors = new hashset<integer> ();
        _factors.add (1);
        _factors.add (_number);
    _sum = 0;
    Private Boolean isfactor (int factor) {return _number% factor = 0; private void Calculatefactors () {for (int i = 1; I <= sqrt (_number) + 1; i++) if (ISFAC
    Tor (i)) addfactor (i);
        } private void Addfactor (int factor) {_factors.add (factor);
    _factors.add (_number/factor);
        private void Sumfactors () {calculatefactors ();
    for (int i: _factors) _sum + = i;
        private int Getsum () {if (_sum = 0) sumfactors ();
    return _sum; } public BoOlean Isperfect () {return getsum ()-_number = = _number;
    public Boolean isabundant () {return getsum ()-_number > _number;
    public Boolean isdeficient () {return getsum ()-_number < _number; }
}

The code in Listing 1 is a typical Java code that uses iterations to determine and summarize the coefficients. When working with functional programming languages, developers rarely care about details (such as iterations, used by calculatefactors) and transformations (such as summarizing a list that is used by sumfactors ()), preferring to leave these details to higher-order functions and coarse-grained abstractions.