Get best of the week

Évangélistes contre loups-garous


Le nom pourrait prétendre être un film B, mais en fait, il s'agira de choses beaucoup plus banales, à savoir: l'amour passionné et parfois complètement déraisonnable des programmeurs et d'autres personnes qui promeuvent des solutions technologiques pour le «pool d'argent» - la conviction qu'il La solution a un large éventail d'applications.

Les programmes sont particuliers


Je vais commencer un peu à distance: le code de programme au sens large est toujours une fonction particulière qui fonctionne strictement dans une certaine plage de valeurs possibles. Toute sortie de gamme est une situation d'urgence et un problème grave, conduisant le plus souvent à un arrêt (cependant, il existe d'autres points de vue sur ces questions, voir, par exemple, l'idéologie Rust). Dans l'électronique moderne, beaucoup plus de code fonctionne dans des bacs à sable clôturés gérés par un code différent, et se décharge ainsi de la responsabilité des plantages "graves": votre téléphone ne sera probablement pas corrompu et ne nécessitera même pas de redémarrage si l'une des applications se bloque. Mais cela ne change pas les spécificités de chaque bloc de code individuel, ni la nécessité d'une correspondance exacte du matériel sur lequel le programme s'exécute aux attentes de ce programme: peu importe la sécurité de Rust, vous ne pourrez pas exécuter son code,compilé pour une architecture de processeur différente. Et toutes les extensions de la plage de valeurs acceptables pour le traitement - par exemple, la capacité des navigateurs à ignorer et à ignorer le «mauvais» HTML, à traiter et à afficher tout le «bon» - elles doivent être décrites explicitement dans le même code.

Le code du programme n'a pas la capacité de se reproduire, grâce auquel nous vivons plus ou moins normalement pendant 60 à 90 ans, malgré des milliards de pannes mineures dans notre corps au niveau cellulaire, et ne peut même pas naturellement «gagner» des lois de la physique, disons, de la deuxième loi de la thermodynamique et de l'interaction faible, grâce à laquelle vous pouvez laisser tomber par inadvertance quelque chose de vos mains, mais le ramasser au sol ou au sol - car il ne volera pas au-delà du sol. Si le code de programme se casse, il se casse.

Bien sûr, tout cela s'oppose à notre réalité objective. Si le code fonctionne (ne parlons pas ici d'informatique quantique) dans un ensemble de certains états discrets, même s'il y en a très, très grand nombre, alors le monde réel fonctionne sur un nombre infini d'états dans certaines plages. Ou dans des états beaucoup plus grands (ordre astronomique) plus discrets, si vous croyez que la réalité a une nature discrète.

Eh bien, pourquoi tout ça?


Non, pas au fait que le code par défaut est plus «fragile» que beaucoup plus en réalité - bien que ce soit le cas, ce n'est pas l'essentiel. Et l'essentiel ici est que, du fait que votre solution logicielle peut théoriquement fonctionner dans une certaine plage de valeurs (c'est-à-dire résoudre certains problèmes spécifiques), il ne s'ensuit pas qu'elle les résoudra en réalité - états possibles beaucoup plus, et la pertinence théorique du programme parmi eux peut être complètement hors de propos.

Par exemple, le langage du signal dans le jeu Factorio est Turing-complete:


Et avec lui, vous pouvez même montrer des clips. Maintenant, levez la main, qui croit que des logiciels commerciaux y seront écrits - malgré le fait qu'en théorie, cela soit tout à fait possible?

Néanmoins, en lisant des articles sur les technologies, je rencontre très souvent le fait que les personnes qui les écrivent préfèrent être de solides mathématiciens et mourir techniquement correct (le meilleur pire type de correct).

En théorie, la théorie n'est pas différente de la pratique


Pourquoi font-ils ça? C'est une excellente question, et j'ai personnellement rencontré deux versions: premièrement, certains comprennent assez honnêtement la différence entre «peut-être en théorie» et «peut-être en pratique», mais ils préfèrent l'ignorer dans des articles assez intentionnellement, guidés par le principe «si vous criez le tonnerre - plus il découvrira les gens. » Il est vrai que l'ironie est que ce principe est également pas une balle d'argent, et si vous criez très fort sans raison, la plupart des gens ne savent pas flatteur choses sur vous.

Eh bien, et deuxièmement, certains ne comprennent vraiment pas très bien la différence, qui donne lieu à toute une série de mauvaises situations, de «un scientifique a violé un journaliste», lorsqu'une personne qui écrit des articles n'est pas un auteur direct de la technologie et, en général, même heureuse d'être violée, donc comment il pense qu'une description plus radicale et «convexe» est dans son intérêt ou dans l'intérêt de la technologie décrite; aux situations où l'auteur croit simplement en ses propres thèses générales, même s'il n'y a fondamentalement aucun motif pour une telle croyance.

Et ce serait très bien si la thèse de l'article restait un problème théorique pas trop important, mais hélas, cela se traduit en réalité. De mon côté personnel: il n'y a pas si longtemps, j'ai passé plus d'une journée de travail à expliquer à mon collègue que la suppression du code inutilisé dans webpack (tremblement d'arbre) existe, mais cela fonctionne sur des principes assez primitifs, c'est pourquoi la portée de cette chose est assez modeste , et vous ne pouvez pas vous y fier aveuglément sans un tas de trucs et de contrôles supplémentaires(un excellent article, soit dit en passant, mais j'ai moi-même creusé ce matériau bien avant). Vous pourriez, bien sûr, blâmer un collègue - mais je me souviens moi-même du grand nombre d'articles et de documents sur le sujet «maintenant il y a des tremblements d'arbres dans le webpack, banzai! le fait que maintenant nos assemblages deviendront petits et tout cela est absolument automatique en raison de la "magie" du webpack.

Qui est à blâmer et que faire?


Bien sûr, je ne pense pas du tout que la voix de quelqu'un qui pleure dans le désert (et même sur le habr) changera quelque chose de façon spectaculaire, et à la fin - il y a une assez grande proportion de ceux qui décrivent complètement et intentionnellement la portée de leurs technologies pour paraître plus attrayantes . Mais si quelqu'un le fait exprès - PENSEZS'il te plait penses-y. Sachez au moins que si votre programme ou votre technologie est capable de faire quelque chose - de cela au fait qu'avec l'aide de votre programme ou de votre technologie, il serait vraiment possible de faire quelque chose dans la pratique, en particulier pour ceux qui ne sont pas les auteurs - très longtemps façon. Reconnaissez que si vous avez fait quelque chose qui fonctionne dans un cas spécifique sur un projet d'un sujet spécifique avec une liste spécifique de problèmes, cela ne vous donne aucune raison de supposer automatiquement que votre technologie sera utile partout. Enfin, sachez que le code pour «le vôtre» et le code pour tout le monde sont deux grandes différences, et si vous mettez le code «pour le vôtre» dans l'open source, cela ne fait pas automatiquement un code utile pour les autres développeurs.

More articles:


All Articles