Why I write my algorithms in 95% of cases, and I will continue to develop code bikes
This is a response to the publication “Does a programmer need to know algorithms?” .
So why do I write my algorithms in 95% of cases and will continue to write them?
In order to be brief, I will immediately cite the specifics in my case (very exotic), but I note that there are many cases of analogs. If there is no analogy in your practice - congratulations, you do not need to bother with bicycles.Take the cake from the shelf ... Take the ready code, this is really a great option for RAD, and just for streaming development, where time is money, and there are no special requirements.
')
I am the developer of an experimental control system for a winged drone.
It is not even about compiled libraries (they are taboo from the beginning: inefficient and dirty code is very likely, and “bookmarks” in it are potentially possible). Speech about code snippets found on the Internet, which I do not fully understand. My system should be absolutely clear on the algorithm of work, first of all, to me, as a leading developer, since it is I who will have to find the problem place and fix it.
I can not afford to spend in the first place megahertz, and in the second kilobytes.
Modern developers under the "big machines" are spoiled by an abundance of resources. They do not optimize the code and tend to make redundant constructions in the style of "and so it works smartly / the compiler optimizes everything." This relaxes, and often makes more or less normal code for large computers, unviable in a foreign ecosystem (for example, on microcontrollers (MC)).
The code for MK must therefore fully disclose and count everything that is used more than once in the code. Something like a very global optimization. Therefore, even if the solution “from forums and stackoverflow” is taken, it is checked and optimized (the simplest example of such optimization is the replacement of ordinary trigonometric functions with tabular, pre-calculated).
Inside my code, a lot of absolute goto transitions are used, and all unnecessary calculations are cut off to the maximum. A good alien code is usually slow and slow. For example, technical vision. Excellent library OpenCV - but where should I shove it? This is a code monster! From all the wealth of technical vision functions, I just need to determine the distance to moving objects and their boundaries. And at high frequency. Learn someone else's experience, but write your own.
It is very hard to check other people's codes for security and stability. And any cppcheck will not help. These are good tools, but they reveal only technical, but not algorithmic errors that occur in other people's codes. More often, it is easier to write from scratch, understanding the idea and solution, than adapting and rewriting someone else’s to your requirements. Yes, it takes time, but the output is a very efficient and secure code. Sharpened just under the desired task.
And a little bit of personal experience on the topic under study.
In my industry, there are no ready (open) solutions, as soon as we move away from the beaten open source by autopilot track. For example, the problem of flight control at a low level (when we already know what the trajectory should be and just need to combine the position of the board with it) is described in theoretical works as an ordinary PID chain. In general, everything is simple, but el diablo is in the details. In hundreds of small parts. What if the engine failed? If the GPS side went for a walk at + -150m? If the inertial horizon sensor due to vibration shows the direction of the horizon in the region of the polar star? And so on and so forth. You can say: where does the PID come from? It goes beyond it! And you will be right, but the task is final - it is management, because you mix different algorithms and their elements in different functions. And because all the algorithms are created from scratch, polished and idealized just for a specific task in the context of the automatic control of the UAV. It turns out to be a rather vigorous spaghetti mix of codes, which is very difficult to change, but extremely effective in solving the problem.
The well-known truth that is often forgotten (or too lazy to remember): efficiency / speed is the opposite of universalization. Not a direct opposition, but they are not on the same side of the scale. When software is created for a very economical ecosystem, figuratively speaking, every sine is counted. And even more so the use of delay (), for which some authors of libraries must be “shot” (creative allegory) with this very delay (), in order to stretch the process. Therefore, all fast functions are written in situ, with limited universality, and not taken as ready-made universal ones.
Colleagues, feel free to create bikes. This keeps the brain in good shape and often allows you to get non-trivial solutions.
PS: The opinion of the author may not coincide with yours.
So why do I write my algorithms in 95% of cases and will continue to write them?
In order to be brief, I will immediately cite the specifics in my case (very exotic), but I note that there are many cases of analogs. If there is no analogy in your practice - congratulations, you do not need to bother with bicycles.
')
I am the developer of an experimental control system for a winged drone.
1. There should not be any black boxes in my code.
It is not even about compiled libraries (they are taboo from the beginning: inefficient and dirty code is very likely, and “bookmarks” in it are potentially possible). Speech about code snippets found on the Internet, which I do not fully understand. My system should be absolutely clear on the algorithm of work, first of all, to me, as a leading developer, since it is I who will have to find the problem place and fix it.
2. I have only 160 megahertz and 300 kb of ram
I can not afford to spend in the first place megahertz, and in the second kilobytes.
Modern developers under the "big machines" are spoiled by an abundance of resources. They do not optimize the code and tend to make redundant constructions in the style of "and so it works smartly / the compiler optimizes everything." This relaxes, and often makes more or less normal code for large computers, unviable in a foreign ecosystem (for example, on microcontrollers (MC)).
The code for MK must therefore fully disclose and count everything that is used more than once in the code. Something like a very global optimization. Therefore, even if the solution “from forums and stackoverflow” is taken, it is checked and optimized (the simplest example of such optimization is the replacement of ordinary trigonometric functions with tabular, pre-calculated).
Inside my code, a lot of absolute goto transitions are used, and all unnecessary calculations are cut off to the maximum. A good alien code is usually slow and slow. For example, technical vision. Excellent library OpenCV - but where should I shove it? This is a code monster! From all the wealth of technical vision functions, I just need to determine the distance to moving objects and their boundaries. And at high frequency. Learn someone else's experience, but write your own.
3. My code should be fast and safe in terms of errors in logic
It is very hard to check other people's codes for security and stability. And any cppcheck will not help. These are good tools, but they reveal only technical, but not algorithmic errors that occur in other people's codes. More often, it is easier to write from scratch, understanding the idea and solution, than adapting and rewriting someone else’s to your requirements. Yes, it takes time, but the output is a very efficient and secure code. Sharpened just under the desired task.
And a little bit of personal experience on the topic under study.
4. Another reason for working with bikes is purely sectoral
In my industry, there are no ready (open) solutions, as soon as we move away from the beaten open source by autopilot track. For example, the problem of flight control at a low level (when we already know what the trajectory should be and just need to combine the position of the board with it) is described in theoretical works as an ordinary PID chain. In general, everything is simple, but el diablo is in the details. In hundreds of small parts. What if the engine failed? If the GPS side went for a walk at + -150m? If the inertial horizon sensor due to vibration shows the direction of the horizon in the region of the polar star? And so on and so forth. You can say: where does the PID come from? It goes beyond it! And you will be right, but the task is final - it is management, because you mix different algorithms and their elements in different functions. And because all the algorithms are created from scratch, polished and idealized just for a specific task in the context of the automatic control of the UAV. It turns out to be a rather vigorous spaghetti mix of codes, which is very difficult to change, but extremely effective in solving the problem.
The well-known truth that is often forgotten (or too lazy to remember): efficiency / speed is the opposite of universalization. Not a direct opposition, but they are not on the same side of the scale. When software is created for a very economical ecosystem, figuratively speaking, every sine is counted. And even more so the use of delay (), for which some authors of libraries must be “shot” (creative allegory) with this very delay (), in order to stretch the process. Therefore, all fast functions are written in situ, with limited universality, and not taken as ready-made universal ones.
Colleagues, feel free to create bikes. This keeps the brain in good shape and often allows you to get non-trivial solutions.
PS: The opinion of the author may not coincide with yours.
Source: https://habr.com/ru/post/279419/
All Articles