Functional programming: a wacky toy that kills labor productivity. Part 2
Today we bring to your attention the continued translation of material on the dangers of the so-called "functional" programming.
Let's admit that we programmers are paid for our time. Just like the builders who have been digging holes near my house for two years now (by the way, they are building a wall, that is, a road).
Let's look for the programmer’s productivity formula. Everyone who worked in any serious large corporation knows a simple formula for success:
The human brain is very poorly adapted to work with what is called “application state” in programming. We can, at some point in time, store only about five elements in our short-term memory. A “state” in programming is usually data stored in memory. In OOP, these are, for example, object fields or variables. Working with a mutable state is very similar to juggling. Few of my friends can juggle with three balls, not to mention five.
OOP makes good use of these weaknesses. In OOP, almost anything can mutate. I thank the higher forces for the fact that the creators of OOP have taken seriously into account what the developers' productivity depends on! In OOP, all mutable state is also available for use in different places of programs by reference. This means that the programmer needs not only to think about the mutable state of the object with which he is currently working. He needs to remember about the mutable states of another 10-50 objects with which this object interacts! It is like juggling 50 balls at once. This state of affairs also has added value. This is a great exercise for the brain.
Mistakes? Yes - during the juggling process, some balls fall. The programmer may miss some little things regarding the interaction of 50 objects. But who, frankly, cares? Production errors should be reported by users. This is how large, serious organizations work. Then the error messages are sent to the JIRA journal (this, as you understand, is a serious enterprise-level software product). Not even a few years will pass, and the errors will be corrected. The problem is solved!
Lord, how I love my mobile banking application. It is very functional, the bank values ​​my business and takes care of my personal data. Mistakes are just possibilities (I was told)!
The so-called "functional" programmers do not understand why isolate the state and make it immutable. This entails the sad consequences of reducing the complexity of programs and, consequently, reducing the number of errors. If there are fewer errors in the code base, this means that programmers will have to solve fewer problems. Developer companies will not be able to charge customers for fixing bugs. Using functional methods, programmers working in any large, serious company will look bad in the eyes of their managers, and at the same time, they will greatly harm their career chances.
The programmer needs the opportunity to demonstrate to the managers the results of his work, the results of moving towards the goal. What is the most effective way to express the results of a programmer? This, of course, is the number of lines of code he wrote! If we all switched to functional programming, then we would greatly upset the managers and raise serious suspicions in them of the effectiveness of our work. A “declarative” approach leads to writing more concise code. Its use greatly reduces the number of lines of code in programs. I believe that it is completely unacceptable that with a declarative approach, to achieve the same goal, up to 3-5 times less code is needed than when using OOP.
In other words, in the transition to functional programming, our productivity will literally collapse in the eyes of serious corporate managers. This, in turn, will put our jobs at risk. Therefore, it is in our best interest to stay away from "functional" programming.
The same advice applies to contractors who charge customers based on hours worked. Here is a simple success formula for them:
This success formula, of course, is also directly applicable to serious contractors who are paid for the number of lines of code:
Unlike functional programming, OOP offers us a consistent approach to writing spaghetti code. This is extremely beneficial for developer productivity. Writing a spaghetti code means spending more hours on writing the code. This is a direct benefit to any serious object-oriented programmer. Spaghetti is not only very tasty. It is also an extremely important concept for those who write in the style of OOP.
OOP is a real gift for contractors and employees of serious companies.
You should not be afraid to use OOP. I repeat - annoying mistakes are a trifle that you should not worry about. In any serious organization, there is a department for the prevention of mistakes (it is also called the department of user support), the main task of which is to protect the developers of the company from angry customers. In the end - if the client cannot use the application correctly - this is only his fault.
Developers should not be bothered by things that are not relevant to their business, such as bug reports. This allows us to ensure a state of affairs in which company resources are not wasted. As a result, developers get the opportunity to calmly implement new application features and direct all their attention to creating object-oriented abstractions of the enterprise class and to applying complex design patterns.
This carefully thought out and well-planned process usually exists to protect the human resources of organizations. As soon as the user encounters an error, he usually searches for the phone number of the customer support department. Then the user is presented with a large interactive telephone menu, which includes various options. It usually takes about 2-5 minutes to listen to information about the menu and select the desired option. This step allows you to filter out the least persistent customers.
Then the client is usually told that the company is faced with an “unusually large volume of calls” and that “the average waiting time is 56 minutes.” At the same time, they usually apologize to the client for the inconvenience and talk about how they value him and his business. At this step, most customers decide not to report an error. In order to entertain those who still dare to wait, they usually play inspirational music. In addition, they are offered to try a new wonderful application. This is the very application with which the client had a problem.
After the 56-minute waiting period has ended, the call is redirected to a call center located somewhere in North America. Employees of such call centers usually undergo special training that allows them to speak with a strong Indian or Bulgarian accent. The call center employee replies that the application in question is outside his area of ​​responsibility, but he will gladly switch the client to another department.
After another waiting period, which now lasts 42 minutes, another call center employee with notes of happiness in his voice tells the client that the error that he encountered is actually a feature of the application. After that, the client is advised to refer to the help section of the application. If the client continues to insist that he is dealing with an error, then they can even create a request for support. The client can even get an answer - something in the spirit of "Playback failed."
I hope you are now convinced that errors are not what the programmer should care about. Organizations usually take serious measures to protect developers from unnecessary waste of time.
If you are actively looking for work - make some effort to remove all “functional” nonsense from your resume. Otherwise, no one will take you seriously. No one in the real corporate world spends time studying children's toys like “composition of functions”, “purity”, “monads” or “immunity”. You hardly want to be like an outsider. If you start talking about such things, it will make the person who is interviewing you feel uncomfortable. And if a representative of a potential employer company feels that you are smarter than him - your chances of getting a job in this company will tend to zero.
HR specialists, recruiting technical personnel in large companies, in addition, undergo mandatory intensive training. This allows them to confidently distinguish between serious technologies - such as Java and JavaScript.
Make sure that your resume contains references to what demonstrates your extensive knowledge of technology that is valued by large companies. Include words and phrases such as “class,” “inheritance,” “design patterns,” “dependency injection,” “SOLID,” “abstract factory,” and “singleton.”
When you are asked to solve the FizzBuzz problem, which is often offered at interviews, on a piece of paper, you kindly recall the following recommendation, which is that you need to be prepared in advance for solving this problem. This is your chance to show off your deep knowledge in those areas of programming that are valued in the corporate world. You should start with a comprehensive draft solution that involves the use of design patterns and other OOP techniques. A good starting point in solving this problem can be FizzBuzzEnterpriseEdition . Many applicants make the same mistake that is typical for beginners. This mistake is that they rely on limited technologies like functions. After this, there is nothing to be surprised that after the interview, no one calls and writes to them.
Having considered the above arguments, serious and accurate, anyone can now clearly see that nothing good can be expected from the use of so-called "functional" programming. It is very clear that this programming approach must be avoided at all costs.
A lot of noise has been raised around “functional” programming over the past couple of years. But the good thing is that this short-term hobby of the community of programmers is already dying away! Big market players like Facebook and Microsoft have long realized the limitations of functional programming and the absolute superiority of object-oriented approaches to organizing code over it. They are directing their efforts toward a new generation of object-oriented languages, in particular ReasonML and BosqueOOP . Such languages ​​take the mutability of the application state to a whole new level, and, fortunately, they do not support useless functional nonsense like immutable data structures.
Here you may have a question about what alternatives the so-called "functional" programming has. This, of course, is object-oriented programming. OOP is sent to us by the true god of programming. OOP is a force to be reckoned with. This is a Capitalized Tool that makes programmers productive. Thanks to OOP, you and your team will always be busy with business (and you won’t lose your job). Here is my article in which I talk in detail about OOP.
May a (object-oriented) force be with you. And your code. I am one with strength. Peace to all.
As many of you have probably guessed, this is satirical material. If you are a beginner programmer, do not take all this to heart.
Functional programming is great. Spend some time exploring this programming paradigm and you will find yourself ahead of many of your teammates.
I hope you were as interested in reading this as I was writing.
Dear readers! What do you dislike most about OOP?
Success is the path, not the goal.
Let's admit that we programmers are paid for our time. Just like the builders who have been digging holes near my house for two years now (by the way, they are building a wall, that is, a road).
Let's look for the programmer’s productivity formula. Everyone who worked in any serious large corporation knows a simple formula for success:
= __ x __
â–ŤNumber of bugs fixed
The human brain is very poorly adapted to work with what is called “application state” in programming. We can, at some point in time, store only about five elements in our short-term memory. A “state” in programming is usually data stored in memory. In OOP, these are, for example, object fields or variables. Working with a mutable state is very similar to juggling. Few of my friends can juggle with three balls, not to mention five.
OOP makes good use of these weaknesses. In OOP, almost anything can mutate. I thank the higher forces for the fact that the creators of OOP have taken seriously into account what the developers' productivity depends on! In OOP, all mutable state is also available for use in different places of programs by reference. This means that the programmer needs not only to think about the mutable state of the object with which he is currently working. He needs to remember about the mutable states of another 10-50 objects with which this object interacts! It is like juggling 50 balls at once. This state of affairs also has added value. This is a great exercise for the brain.
Mistakes? Yes - during the juggling process, some balls fall. The programmer may miss some little things regarding the interaction of 50 objects. But who, frankly, cares? Production errors should be reported by users. This is how large, serious organizations work. Then the error messages are sent to the JIRA journal (this, as you understand, is a serious enterprise-level software product). Not even a few years will pass, and the errors will be corrected. The problem is solved!
Lord, how I love my mobile banking application. It is very functional, the bank values ​​my business and takes care of my personal data. Mistakes are just possibilities (I was told)!
The so-called "functional" programmers do not understand why isolate the state and make it immutable. This entails the sad consequences of reducing the complexity of programs and, consequently, reducing the number of errors. If there are fewer errors in the code base, this means that programmers will have to solve fewer problems. Developer companies will not be able to charge customers for fixing bugs. Using functional methods, programmers working in any large, serious company will look bad in the eyes of their managers, and at the same time, they will greatly harm their career chances.
â–ŤNumber of lines of code
The programmer needs the opportunity to demonstrate to the managers the results of his work, the results of moving towards the goal. What is the most effective way to express the results of a programmer? This, of course, is the number of lines of code he wrote! If we all switched to functional programming, then we would greatly upset the managers and raise serious suspicions in them of the effectiveness of our work. A “declarative” approach leads to writing more concise code. Its use greatly reduces the number of lines of code in programs. I believe that it is completely unacceptable that with a declarative approach, to achieve the same goal, up to 3-5 times less code is needed than when using OOP.
In other words, in the transition to functional programming, our productivity will literally collapse in the eyes of serious corporate managers. This, in turn, will put our jobs at risk. Therefore, it is in our best interest to stay away from "functional" programming.
The same advice applies to contractors who charge customers based on hours worked. Here is a simple success formula for them:
__ = ____ = $$$$$$
This success formula, of course, is also directly applicable to serious contractors who are paid for the number of lines of code:
if (1 == '1') { doStuff(); } else { // }
â–ŤSpaghetti code is our bread and butter
Unlike functional programming, OOP offers us a consistent approach to writing spaghetti code. This is extremely beneficial for developer productivity. Writing a spaghetti code means spending more hours on writing the code. This is a direct benefit to any serious object-oriented programmer. Spaghetti is not only very tasty. It is also an extremely important concept for those who write in the style of OOP.
OOP is a real gift for contractors and employees of serious companies.
Error Prevention Department
You should not be afraid to use OOP. I repeat - annoying mistakes are a trifle that you should not worry about. In any serious organization, there is a department for the prevention of mistakes (it is also called the department of user support), the main task of which is to protect the developers of the company from angry customers. In the end - if the client cannot use the application correctly - this is only his fault.
Developers should not be bothered by things that are not relevant to their business, such as bug reports. This allows us to ensure a state of affairs in which company resources are not wasted. As a result, developers get the opportunity to calmly implement new application features and direct all their attention to creating object-oriented abstractions of the enterprise class and to applying complex design patterns.
â–Ť Error reporting process
This carefully thought out and well-planned process usually exists to protect the human resources of organizations. As soon as the user encounters an error, he usually searches for the phone number of the customer support department. Then the user is presented with a large interactive telephone menu, which includes various options. It usually takes about 2-5 minutes to listen to information about the menu and select the desired option. This step allows you to filter out the least persistent customers.
Then the client is usually told that the company is faced with an “unusually large volume of calls” and that “the average waiting time is 56 minutes.” At the same time, they usually apologize to the client for the inconvenience and talk about how they value him and his business. At this step, most customers decide not to report an error. In order to entertain those who still dare to wait, they usually play inspirational music. In addition, they are offered to try a new wonderful application. This is the very application with which the client had a problem.
After the 56-minute waiting period has ended, the call is redirected to a call center located somewhere in North America. Employees of such call centers usually undergo special training that allows them to speak with a strong Indian or Bulgarian accent. The call center employee replies that the application in question is outside his area of ​​responsibility, but he will gladly switch the client to another department.
After another waiting period, which now lasts 42 minutes, another call center employee with notes of happiness in his voice tells the client that the error that he encountered is actually a feature of the application. After that, the client is advised to refer to the help section of the application. If the client continues to insist that he is dealing with an error, then they can even create a request for support. The client can even get an answer - something in the spirit of "Playback failed."
I hope you are now convinced that errors are not what the programmer should care about. Organizations usually take serious measures to protect developers from unnecessary waste of time.
Avoid “Beginner Mistakes” at Interviews
If you are actively looking for work - make some effort to remove all “functional” nonsense from your resume. Otherwise, no one will take you seriously. No one in the real corporate world spends time studying children's toys like “composition of functions”, “purity”, “monads” or “immunity”. You hardly want to be like an outsider. If you start talking about such things, it will make the person who is interviewing you feel uncomfortable. And if a representative of a potential employer company feels that you are smarter than him - your chances of getting a job in this company will tend to zero.
HR specialists, recruiting technical personnel in large companies, in addition, undergo mandatory intensive training. This allows them to confidently distinguish between serious technologies - such as Java and JavaScript.
Make sure that your resume contains references to what demonstrates your extensive knowledge of technology that is valued by large companies. Include words and phrases such as “class,” “inheritance,” “design patterns,” “dependency injection,” “SOLID,” “abstract factory,” and “singleton.”
When you are asked to solve the FizzBuzz problem, which is often offered at interviews, on a piece of paper, you kindly recall the following recommendation, which is that you need to be prepared in advance for solving this problem. This is your chance to show off your deep knowledge in those areas of programming that are valued in the corporate world. You should start with a comprehensive draft solution that involves the use of design patterns and other OOP techniques. A good starting point in solving this problem can be FizzBuzzEnterpriseEdition . Many applicants make the same mistake that is typical for beginners. This mistake is that they rely on limited technologies like functions. After this, there is nothing to be surprised that after the interview, no one calls and writes to them.
Functional programming probably cannot be used to develop serious software solutions.
Having considered the above arguments, serious and accurate, anyone can now clearly see that nothing good can be expected from the use of so-called "functional" programming. It is very clear that this programming approach must be avoided at all costs.
A lot of noise has been raised around “functional” programming over the past couple of years. But the good thing is that this short-term hobby of the community of programmers is already dying away! Big market players like Facebook and Microsoft have long realized the limitations of functional programming and the absolute superiority of object-oriented approaches to organizing code over it. They are directing their efforts toward a new generation of object-oriented languages, in particular ReasonML and BosqueOOP . Such languages ​​take the mutability of the application state to a whole new level, and, fortunately, they do not support useless functional nonsense like immutable data structures.
Summary: gift of the gods
Here you may have a question about what alternatives the so-called "functional" programming has. This, of course, is object-oriented programming. OOP is sent to us by the true god of programming. OOP is a force to be reckoned with. This is a Capitalized Tool that makes programmers productive. Thanks to OOP, you and your team will always be busy with business (and you won’t lose your job). Here is my article in which I talk in detail about OOP.
May a (object-oriented) force be with you. And your code. I am one with strength. Peace to all.
As many of you have probably guessed, this is satirical material. If you are a beginner programmer, do not take all this to heart.
Functional programming is great. Spend some time exploring this programming paradigm and you will find yourself ahead of many of your teammates.
I hope you were as interested in reading this as I was writing.
Dear readers! What do you dislike most about OOP?
All Articles