Get best of the week

Evangelists vs. Werewolves


The name could pretend to be a B-movie, but in fact it will be about much more mundane things, namely: passionate and sometimes completely unreasonable love of programmers and other people who are promoting technology solutions for the “silver pool” - the belief that it The solution has a wide range of applications.

Programs are particular


I'll start a little from afar: program code in the broad sense is always a particular function that works strictly in a certain range of possible values. Any way out of the range is an emergency situation and a serious problem, most often leading to a halt (however, there are other points of view on these issues, see, for example, the Rust ideology). In modern electronics, much more code works in fenced sandboxes managed by a different code, and thus relieves itself of the responsibility of "serious" crashes: your phone will most likely not get corrupted and will not even require a reboot if one of the applications crashes. But this does not change the specifics of each individual block of code, nor does it change the need for exact correspondence of the hardware on which the program runs to the expectations of this program: no matter how secure Rust is, you will not be able to execute its code,compiled for a different processor architecture. And any extensions to the range of acceptable values ​​for processing - say, the ability of browsers to ignore and skip the "bad" html, processing and showing all the "good" - they must be described explicitly in the same code.

The program code does not have the ability to replicate, thanks to which we live more or less normally for 60-90 years, despite the trillions of minor breakdowns in our bodies at the cellular level, and cannot even naturally “win” from the laws of physics, say, from the second law of thermodynamics and weak interaction, thanks to which you can inadvertently drop something from your hands, but pick it up from the ground or floor - because it will not fly beyond the floor. If the program code breaks, it breaks.

Of course, this is all in opposition to our objective reality. If the code works (let's not talk about quantum computing here) in a set of certain discrete states, even if there are very, very many of them, then the real world works on an infinite number of states in certain ranges. Or in a much larger (astronomical order) more discrete states, if you believe that reality has a discrete nature.

Well, why was all this?


No, not to the fact that the default code is more “fragile” than much more in reality - although this is so, it is not the main thing. And the main thing here is that from the fact that your software solution can theoretically work in a certain range of values ​​(i.e., solve certain specific problems), it does not follow that it will solve them in reality - possible states much more, and the theoretical suitability of the program among them may be completely irrelevant.

For example, the signal language in the game Factorio is Turing-complete:


And with it you can even show clips. Now raise your hand, who believes that commercial software will be written on it - despite the fact that in theory this is entirely possible?

Nevertheless, when reading articles about technologies, I very often meet with the fact that people who write them prefer to be solid mathematicians and to die technically correct (the best worst kind of correct).

In theory, theory is no different from practice


Why are they doing this? This is an excellent question, and I personally came across two versions: firstly, some fairly honestly understand the difference between “maybe in theory” and “maybe in practice,” but they prefer to ignore it in articles quite intentionally, guided by the principle “you shout out loud - more he will find out about people. ” True, the irony here is that this principle is also not a silver bullet, and if you shout very loudly without reason, most people will not know flattering things about you.

Well, and secondly, some really do not quite understand the difference, which gives rise to a whole set of bad situations, from “a scientist raped a journalist”, when a person who writes articles is not a direct author of technology and, in general, even happy to be raped, so how he believes that a more radical and “convex” description is in his interests or in the interests of the described technology; to situations where the author simply believes in his own broad theses, even though there are basically no grounds for such a belief.

And it would be very good if the thesis of the article would remain a not too important theoretical problem, but alas, it very much translates into reality. From my personal: not so long ago I spent more than one working day explaining to my colleague that removing unused code in webpack (tree-shaking) exists, but it works on fairly primitive principles, which is why the scope of this thing is quite modest , and you can’t blindly rely on it without a bunch of additional tricks and checks(an excellent article, by the way, but I myself was digging this material long before it). You can, of course, blame a colleague - but I myself remember the great number of articles and materials on the topic "now there is tree-shaking in webpack, banzai!" the fact that now our assemblies will become small and all this is absolutely automatic due to the "magic" of the webpack.

Who is to blame and what to do?


Of course, I don’t think at all that the voice of one crying in the desert (and even on the habr) will change something dramatically, and in the end - there is a fairly large proportion of those who completely intentionally broadly describe the scope of their technologies to look more attractive . But if someone does this on purpose - THINKplease think about it. At least be aware that if your program or technology is capable of doing something - from that to the fact that with the help of your program or technology it would really be possible to do something in practice, especially for those who are not the authors - a very long way. Recognize that if you have done something that works in a specific case on a project of a specific subject with a specific list of problems, this does not give you any reason to automatically assume that your technology will be useful everywhere. Finally, be aware that the code for “your own” and the code for everyone are two big differences, and if you put the code “for your own” in the open source, this does not automatically make it a code useful to other developers.

More articles:


All Articles