It's not about functions!
Several definitions of functional programming. There are two big approaches to programming - imperative and functional. They differ significantly in the logic of work, and also create confusion in the names.
Now let's explain:
No, functionality is not about functions. Almost all programming languages have functions, both functional and imperative.
The difference between functional programming and imperative programming lies in the general approach. Metaphor:
Instruction or rule book.
Imagine that you are opening a coffee shop. Now you have two types of employees there: cooks and administrators.
For chefs, you write clear step-by-step instructions for each dish.
For example:
1. Pour water into the pan
2. Put a pot of water on the fire
3. Add so much salt to a pot of water
4. If you need to cook 10 servings, take one beetroot. If you need to cook 20 servings, take two beets.
5. Peel all the beets you took
6. …
The cook must follow these instructions exactly in the order in which you wrote them. You cannot first clean the beets, and then take them. You can't fill the water without a saucepan.
The order of actions is important and is determined by you. This is an example of imperative programming. You control the performer. We can say that the performers carry out your tasks. For the administrator, you do not write instructions, but as a set of rules:
• We cannot bring our own food. If the guests came with food, then make them such and such a remark.
• The hall must be clean. If the hall is dirty, call the cleaning lady.
• If there is a queue, open an additional cash desk.
These are also commands, but the administrator will not execute them in such a sequence, but in any at his discretion. We can say that the task of this person is to perform the functions of an administrator, and we have described the rules by which these functions are performed. This is an example of functional programming.
It turns out that the meaning of functional programming is not in describing the clear steps themselves to the goal, but in the rules by which the compiler itself must achieve the desired result.
Programmers, please don't bomb.
Of course, this is simplified to understand. You yourself try to explain this normally (you can directly in the comments). Abstraction. Imagine that you asked several people to describe in general terms what a telephone is and how to use it:
let them be a grandmother, a mother, and a friend. Grandmother will remember about rotary telephones and tubes with twisted cable. Mom will tell about radiotelephones, which have a base and a handset with which you can walk around the apartment, and a friend will begin to describe a mobile phone.
Although the stories will be very different from each other, they will have a few things in common about the phone:
• the phone has a handset;
• we speak into the receiver, listen from the receiver;
• you can dial the number of the desired person and call him;
• If someone calls you on the phone, you will hear it and take the call.
It turns out that if you imagine an abstract phone, you get such a device with a speaker, a microphone and a dialer.
So, abstraction is:
when we describe only the most essential details that are important for the task. In our case, the task is to understand what a telephone is and how to use it. Therefore, the microphone and speaker are important for this task, but the way the phone communicates with the network is not. The dialer is important, but what ringtone plays when you call is not. Abstraction is when we focus only on the details that are necessary for the task and ignore everything else.
In Object-Oriented Programming (OOP), abstraction means that for each object we set the minimum number of methods, fields, and descriptions that will solve the problem. The fewer characteristics, the better the abstraction, but the key characteristics cannot be removed. Interfaces are used to work with abstractions.
Interface.
So, we have a device with a handset, a microphone, a speaker and a dialer. But if you remember the stories of your mother, grandmother and girlfriend, you will find this:
• speak into the microphone so that the interlocutor can hear you;
• to hear the interlocutor, put your ear to the speaker;
• to dial a number, you need to dial the desired sequence of numbers using the dialer;
• When a call comes in, the speaker beeps.
All of these are interfaces.
They allow you to work with an object without delving into how it is arranged inside. If you know how to work with the dialer interface, then you don't care whether you need to turn the dial, press the physical buttons on the radiotelephone, or press your finger on the touch screen.
Such an interface, as it were, tells us - I will enter any numbers you want into the phone. It doesn't matter how I do it and how they will be processed, just dial the number, and then the phone will figure it out.
Interfaces are actions on an object that are available to other objects (which is why they are called public).
There are also encapsulated, that is, internal methods. For example, a microphone has a public method "Listen to voice" and an internal method "Convert voice to electrical signal protocol". With it, it interacts with other parts of our abstract phone with support for encapsulation tools. Complicated terminology. Strictly speaking, interfaces are not actions, but methods. Now let's explain.
In programming, there are operations - these are the simplest actions, for example, copying a value from one variable to another.
Functions are made up of simple actions - this is when several operations are “glued” into something single. We give this gluing a name and get a function. For example, there may be a function "check the correctness of the email address", which consists of several dozen simple operations.
In OOP language, functions attached to objects are called methods. Just such a term. In fact, these are functions, that is, operations glued together.
So, a method is a set of simple actions that are glued together and put into an object. What is all this for. And all because no one cares how that programmer implemented his part, if everything works fine through the interface at the hardware level. It does not matter how it generates a logical binary signal, what is guided by when it sets the clock frequency in cycles, how it builds a trigger call or how the script is saved.
If a logical core with such an abstraction of the interface provides the developer with a more comfortable achievement of the ultimate goal, then such an environment rightfully deserves mass recognition and a course for its further scaling among a wider community of specialists.
And as a result - The category of such developers will pay more attention to the functionality of the algorithms of their ideas and get rid of the routine work that is present in imperative programming. Where it is applied and to whom it is suitable.
The most suitable place for application is startups and small projects.
Startups will benefit from high development speed and instant user feedback, which is why most new pilot projects are done this way. It is important to note that in small projects it is often more important to meet the budget, quickly respond and resolve customer complaints. Instead of an epilogue. Based on the foregoing, the our logical core of the tool BEEPTOOLKIT with interface abstraction was developed for functional programming of hardware component control processes on binary logic, including media encapsulation of commands: