Why is functional programming mainstream?
Functional programming can hardly be called a new phenomenon. Back in the early 90s, when I was at university, we often had to write something on LISP. It would seem that 25 years have passed - but then already this programming language was older than me.
The benefits of functional programming have long been recognized by the general public. The successful development of software often comes down to the maximum simplification of existing mechanisms that allow new applications to adapt to the requirements of modern users. But at the same time, we have to hurry, managing to provide consumers with products with unlimited possibilities in a short time. It is much easier to cope with the task, when the developed applications can be divided into several pure functions, which are not difficult to verify. In such algorithms there are no tricky side effects and abstract formulations designed for results on a global scale.
But it seems that no functional language claims the title of a generally recognized one. I mean a kind of world hegemony C in the 70s, which later transferred the crown to C ++, Java, and eventually JavaScript. None of the second-tier candidates (Python, PHP, Perl, Ruby, C # ...) fell into the functional category.
And then something incredible happened. Yes, I'm talking about Clojure.
')
Just kidding No one says that a new functional language has emerged on the world stage, instantly becoming a leader, just this time we are clearly dealing with the growing potential of a champion who suddenly came to the fore. Now we are working on creating a mobile application on React / Redux, and this is how the code I write looks like:
So why did the experts lose sight of functional programming for so long? And why is it becoming so common today?
The answer to the first question is largely determined by one of the main trends in software development. After graduating from university, I was overwhelmed with waves of an object-oriented tsunami, and for more than 20 years I have not written a single line on LISP. The community of software developers recognized this methodology as the Last Stand - after several years with the advent of Java, the practice was only fixed - and for some reason, the collective mind persistently ignored the advantages of functional programming.
Armed with encapsulation, inheritance and polymorphism, the PLO gave hope to simplify the process of creating new programs. However, in recent years, the shortcomings of the method have become increasingly obvious. Rigid hierarchies of objects and the lack of clear characteristics of classes significantly hampered the evolution of the PLO. Gradually, uncertainty spreads to all the component elements of programming, without exception, and, therefore, does not do without undesirable interoperability and unpredictable side effects. This is how functional programming verbs supplanted the nouns on which the PLO was based.
I joked a little when I mentioned Clojure a bit earlier, but it was this dialect that contributed to the revival of functional programming lately. If we talk about a number of practical issues that could not be solved with the good old LISP, a whole generation of functional developers appeared along with Clojure. Thus, the Om was created, without which it is impossible to imagine the evolution of the modern JS ecosystem (more on this later).
In addition to the disappointment of the PLO, the two previously voiced questions are also related to several additional trends: the emergence of JavaScript as a full-fledged general-purpose programming language and the incorporation of functional programming methodology into the vast JavaScript ecosystem.
At the turn of the decade, it becomes obvious that the key role in most web development is still played by the server, while client scripts perform auxiliary functions. Yes, individual Ajax applications, such as Gmail, demonstrated how convenient it is to use applications as a separate page running in the browser itself, for which the server is primarily a centralized data repository. Fast web applications that resemble familiar stationary applications turned out to be an order of magnitude higher than bulky predecessors on CGI.
After the release of Google Chrome in 2008 and, in particular, after the presentation of the V8 engine from JavaScript, the trend only intensified. Creating super-fast JavaScript has become a prerequisite for developing full-fledged one-page applications. And again, Google is leading with its AngularJS. V8 also strengthened its position in Node.js, a separate JS platform used primarily for developing server products.
Suddenly JavaScript stopped appearing like a childish programming language. Thanks to AngularJS and a whole family of similar developments, and with them Node, interest in JS has grown immensely, which has caused an incredible demand for this programming language over the past few years.
And what does all this have to do with functional programming? Brendan Eich (creator of JS) recalls that in 1995 he was taken to Netscape to create a browser layout. Although I later had to agree to the persuasion of a guide set up to get a “similar to Java” product, the development retained a number of important features of functional programming languages (for example, first-class functions). She was christened (albeit with exaggeration) "LISP with syntax C."
On the Internet, a million examples, thanks to which it becomes clear that with the help of JS you can write an imperative, object-oriented, or simply disgusting spaghetti code. But, if you compare JavaScript with other programming languages resembling C, it can be an excellent prototype for creating a true functional language.
In 2011, functional commands “stalwarts map” and “reduce” were added to JS (technically ECMAScript). In ECMAScript 2015 (ECMAScript 6) with its concise syntax and a completely rational structure, a number of other functional tools have appeared, including the creation of objects and the fat arrow that users love. Not all features of ES2015 are supported by browsers, but thanks to the Babel transcompiler it doesn't matter, because you can use ES2015 functionality (and even ES2016), and then compile the results in the form of a universal ES5.
AngularJS marked the beginning of the JavaScript boom, but since the product is rooted in Java and OOP, you should not write it into the ranks of functional development. Over the past couple of years, Facebook React has become a great fast client JS framework. Yes, it was not without impressive indicators of the Flux architecture and the Immutable.js library, also listed among the merits of the Facebook team (I wonder how the development of functional JS coincides with the way Facebook is pushing Google out of the JS framework market).
It seems that React forms a very functional approach to the development of web applications. In fact, the latest version of React introduced a simplified syntax for pure components, the integration of which does not cause side effects.
React specializes exclusively in data display, however, this is why Facebook recommends using Flux to extend the application architecture. Since Flux is just a set of basic elements (repositories, actions, centralized service dispatcher, unidirectional data flow), at the same time with this development competitors were quick to create their own alternatives claiming to be the leader in their field. And before the appearance of Redux, the winner in such an equal battle did not exist.
The Redux mechanism is based on the following principles: a single centralized data repository, state change is possible only as a result of specific actions and the use of pure functions (reducers).
When used in conjunction with Immutable.js, Redux becomes almost the twin of Om from Clojure. Theoretically, it was always possible to combine functional programming and JavaScript, but React, Redux and Immutable.js finally offered JS developers a practical solution - developing clean viewers without side effects that allow you to change the usual state of the product within the hulk ES6 syntax - to create large-scale functional applications. The popularity of this approach (and, therefore, the wide spread of functional programming) is simply amazing: when I first noticed Redux a few months ago, it had about 500 stars on GitHub. Today - more than 11,000.
It is too early to say that interest in JavaScript functionality will continue to grow. Recently, JS has repeatedly encountered periods of instability, and therefore the sudden appearance of countless new frameworks claiming to be exclusive, looked pretty funny. But the rich pedigree of functional programming and the roots of the emerging trend look very convincing. And while individual projects fail, it seems that the future of software development will still be functional.
The benefits of functional programming have long been recognized by the general public. The successful development of software often comes down to the maximum simplification of existing mechanisms that allow new applications to adapt to the requirements of modern users. But at the same time, we have to hurry, managing to provide consumers with products with unlimited possibilities in a short time. It is much easier to cope with the task, when the developed applications can be divided into several pure functions, which are not difficult to verify. In such algorithms there are no tricky side effects and abstract formulations designed for results on a global scale.
But it seems that no functional language claims the title of a generally recognized one. I mean a kind of world hegemony C in the 70s, which later transferred the crown to C ++, Java, and eventually JavaScript. None of the second-tier candidates (Python, PHP, Perl, Ruby, C # ...) fell into the functional category.
And then something incredible happened. Yes, I'm talking about Clojure.
')
Just kidding No one says that a new functional language has emerged on the world stage, instantly becoming a leader, just this time we are clearly dealing with the growing potential of a champion who suddenly came to the fore. Now we are working on creating a mobile application on React / Redux, and this is how the code I write looks like:
aliasesList.reduce((allMatching, matching, index) => { if (matching.count() > 0) { const expanded = allAliases.take(index) .concat(List.of(matching)) .concat(allAliases.skip(index + 1)) .filter(aliases => aliases.count()) .reduce((current, aliases) => current ? current.flatMap( i1 => aliases.map(i2 => i1.concat(i2)) ) : aliases.map(alias => List.of(alias)), null); return allMatching.concat(expanded); } else { return allMatching; } }, new List()); So why did the experts lose sight of functional programming for so long? And why is it becoming so common today?
Down with the nouns
The answer to the first question is largely determined by one of the main trends in software development. After graduating from university, I was overwhelmed with waves of an object-oriented tsunami, and for more than 20 years I have not written a single line on LISP. The community of software developers recognized this methodology as the Last Stand - after several years with the advent of Java, the practice was only fixed - and for some reason, the collective mind persistently ignored the advantages of functional programming.
Armed with encapsulation, inheritance and polymorphism, the PLO gave hope to simplify the process of creating new programs. However, in recent years, the shortcomings of the method have become increasingly obvious. Rigid hierarchies of objects and the lack of clear characteristics of classes significantly hampered the evolution of the PLO. Gradually, uncertainty spreads to all the component elements of programming, without exception, and, therefore, does not do without undesirable interoperability and unpredictable side effects. This is how functional programming verbs supplanted the nouns on which the PLO was based.
I joked a little when I mentioned Clojure a bit earlier, but it was this dialect that contributed to the revival of functional programming lately. If we talk about a number of practical issues that could not be solved with the good old LISP, a whole generation of functional developers appeared along with Clojure. Thus, the Om was created, without which it is impossible to imagine the evolution of the modern JS ecosystem (more on this later).
JavaScript is growing in front of our eyes
In addition to the disappointment of the PLO, the two previously voiced questions are also related to several additional trends: the emergence of JavaScript as a full-fledged general-purpose programming language and the incorporation of functional programming methodology into the vast JavaScript ecosystem.
At the turn of the decade, it becomes obvious that the key role in most web development is still played by the server, while client scripts perform auxiliary functions. Yes, individual Ajax applications, such as Gmail, demonstrated how convenient it is to use applications as a separate page running in the browser itself, for which the server is primarily a centralized data repository. Fast web applications that resemble familiar stationary applications turned out to be an order of magnitude higher than bulky predecessors on CGI.
After the release of Google Chrome in 2008 and, in particular, after the presentation of the V8 engine from JavaScript, the trend only intensified. Creating super-fast JavaScript has become a prerequisite for developing full-fledged one-page applications. And again, Google is leading with its AngularJS. V8 also strengthened its position in Node.js, a separate JS platform used primarily for developing server products.
Suddenly JavaScript stopped appearing like a childish programming language. Thanks to AngularJS and a whole family of similar developments, and with them Node, interest in JS has grown immensely, which has caused an incredible demand for this programming language over the past few years.
Function and shape
And what does all this have to do with functional programming? Brendan Eich (creator of JS) recalls that in 1995 he was taken to Netscape to create a browser layout. Although I later had to agree to the persuasion of a guide set up to get a “similar to Java” product, the development retained a number of important features of functional programming languages (for example, first-class functions). She was christened (albeit with exaggeration) "LISP with syntax C."
On the Internet, a million examples, thanks to which it becomes clear that with the help of JS you can write an imperative, object-oriented, or simply disgusting spaghetti code. But, if you compare JavaScript with other programming languages resembling C, it can be an excellent prototype for creating a true functional language.
In 2011, functional commands “stalwarts map” and “reduce” were added to JS (technically ECMAScript). In ECMAScript 2015 (ECMAScript 6) with its concise syntax and a completely rational structure, a number of other functional tools have appeared, including the creation of objects and the fat arrow that users love. Not all features of ES2015 are supported by browsers, but thanks to the Babel transcompiler it doesn't matter, because you can use ES2015 functionality (and even ES2016), and then compile the results in the form of a universal ES5.
Normal reaction
AngularJS marked the beginning of the JavaScript boom, but since the product is rooted in Java and OOP, you should not write it into the ranks of functional development. Over the past couple of years, Facebook React has become a great fast client JS framework. Yes, it was not without impressive indicators of the Flux architecture and the Immutable.js library, also listed among the merits of the Facebook team (I wonder how the development of functional JS coincides with the way Facebook is pushing Google out of the JS framework market).
It seems that React forms a very functional approach to the development of web applications. In fact, the latest version of React introduced a simplified syntax for pure components, the integration of which does not cause side effects.
React specializes exclusively in data display, however, this is why Facebook recommends using Flux to extend the application architecture. Since Flux is just a set of basic elements (repositories, actions, centralized service dispatcher, unidirectional data flow), at the same time with this development competitors were quick to create their own alternatives claiming to be the leader in their field. And before the appearance of Redux, the winner in such an equal battle did not exist.
The Redux mechanism is based on the following principles: a single centralized data repository, state change is possible only as a result of specific actions and the use of pure functions (reducers).
When used in conjunction with Immutable.js, Redux becomes almost the twin of Om from Clojure. Theoretically, it was always possible to combine functional programming and JavaScript, but React, Redux and Immutable.js finally offered JS developers a practical solution - developing clean viewers without side effects that allow you to change the usual state of the product within the hulk ES6 syntax - to create large-scale functional applications. The popularity of this approach (and, therefore, the wide spread of functional programming) is simply amazing: when I first noticed Redux a few months ago, it had about 500 stars on GitHub. Today - more than 11,000.
Functional future?
It is too early to say that interest in JavaScript functionality will continue to grow. Recently, JS has repeatedly encountered periods of instability, and therefore the sudden appearance of countless new frameworks claiming to be exclusive, looked pretty funny. But the rich pedigree of functional programming and the roots of the emerging trend look very convincing. And while individual projects fail, it seems that the future of software development will still be functional.
According to tradition, a little advertising in the basement, where it does not hurt anyone. Our company launched a New Year sale of servers and VPS, within which you can get from 1 to 3 months of rent for free. The details of the action you can find here .
Source: https://habr.com/ru/post/274567/
All Articles