Programmation fonctionnelle: mesure sept fois, coupe une fois

Bon après-midi Récemment, j'entends très souvent que le coucher du soleil de l'OLP est arrivé. Aujourd'hui, de plus en plus de personnes évoluent vers un paradigme fonctionnel. Bientôt, les gens qui écrivent en C ++ / C # / Java ne seront plus du tout laissés. En est-il ainsi? Je ne pense pas. À mon avis, l'utilisation irréfléchie de la FP (programmation fonctionnelle) peut prendre du temps et devenir un casse-tête supplémentaire, ce qui est complètement incompatible avec les décisions de conception actuelles. Assurons-nous!



Je veux noter: il ne s'agit pas d'expressions lambda en Java / Python, mais d'un FP plus avancé comme Haskell ou Scala avec cats / scalaz.

Donc, j'affirme que:

1. La FA est loin d'être applicable partout.
2. Il apporte un casse-tête lorsqu'il est intégré à des solutions prêtes à l'emploi.
3. Passer du temps sur AF n'est pas toujours judicieux.

Nous analyserons ces points plus en détail et évaluerons l'ampleur de la tragédie.

1. La FA est loin d'être applicable partout

Cela semble surprenant, mais tout le monde ne le comprend pas. De plus, des langages comme C sont très loin du coucher du soleil. Beaucoup plus loin que Haskell ou Scala. Jetez un œil à n'importe quel moteur de jeu. Avec une probabilité de 90%, la majeure partie est écrite en C. Jetez un œil au firmware de n'importe quel appareil domestique de votre appartement. Très probablement, c'est encore C! Systèmes d'exploitation? Bien sûr C.

Pourquoi cela se produit-il? Le fait est que tout ce qui précède fonctionne directement avec le fer. Le fer ne connaît aucune fonction d'ordre supérieur. Le fer est un ensemble de registres (qui est déjà un état mutable), d'interruptions (encore une fois, qui changent d'état) et de commandes qui transfèrent les zéros et les uns d'une cellule à l'autre.

Bien sûr, vous pouvez utiliser l'abstraction et oublier toutes ces choses de fer. Mais tout d'abord, ce n'est pas toujours raisonnable. Si notre programme est assez simple, il ne sert à rien de clore avec quelques couches d'abstraction. Deuxièmement, souvent dans de tels programmes, la vitesse de travail est placée sur l'un des postes clés. Par conséquent, le coût supplémentaire d '«explication» de la glande FP ruinera complètement le bénéfice de votre développement. L'AF ne peut pas se manifester ici.

2. Il apporte un mal de tête lors de l'intégration avec des solutions clé en main

Chaque langage de programmation qui se respecte a un grand nombre de solutions toutes faites. En C #, c'est, par exemple, Entity Framework et .Net. En Java, ce sont Hibernate et Spring. Et presque tous les frameworks visent à fonctionner dans notre style OOP habituel. Presque toujours, ces solutions ont des états variables et sont totalement inadaptées pour travailler avec des transitions de phase pures.

Tout programmeur fonctionnel noyau dur dira que vous devez jeter ces solutions et travailler sans elles. Ok Disons simplement pour référence ce que nous perdrons d'une telle décision:

1. Presque toujours, ces décisions aboutissent à un code passe-partout.
2. Nous perdons une énorme couche de fonctionnalités. Bien sûr, nous pouvons prendre une bibliothèque prête à l'emploi pour travailler dans un paradigme fonctionnel. Mais presque toujours, une telle solution est beaucoup moins populaire, ce qui signifie qu'elle ne peut pas offrir la moitié de toutes les possibilités des solutions populaires.
3. Les produits finis qui utilisent cette solution devront être presque entièrement refactorisés.
4. Nous perdons une solution bien testée et hautement déterministe. Au lieu de cela, nous nous dirigeons vers l'inconnu. Y a-t-il des problèmes dans les solutions populaires? Bien sûr! Mais à leur sujet, en règle générale, tout est connu depuis longtemps. Dans notre nouvelle approche, cela ne se produira certainement pas.

En fait, la liste est longue. À mon avis, la totalité des pertes rend la FA, au moins, pas partout et pas toujours adaptée.

3. Passer du temps sur la FA n'est pas toujours judicieux

Ce qui est surprenant, cependant, souvent les programmeurs ne voient pas ce qui se cache derrière le code. Pas toujours un langage de programmation et un paradigme déterminent la qualité d'un produit. À l'arrière, tout va à la conteneurisation. Peu importe ce sur quoi vous écrivez: Python, Java, Scala. Le code dans l'une de ces langues peut être encapsulé dans une image et livré sous forme de conteneur.

Dans un tel monde, ce qui est à l'intérieur du conteneur n'est pas si important s'il répond à toutes les exigences définies. Il est plus important ici de savoir comment l'ensemble du système est organisé. La question se pose: êtes-vous vraiment sûr que votre temps devrait être investi dans l'étude de la PF avec sa théorie des catégories? Il peut être utile d'investir dans le développement de l'architecture globale du système. De plus, il est beaucoup plus facile de trouver des personnes sans connaissances en PF qui sont prêtes à vous fournir de tels conteneurs.

Imaginez cette situation. Vous vous asseyez la nuit et étudiez toute la théorie. Vous regardez des vidéos sur YouTube, lisez des livres, plongez dans les calculs mathématiques. Au fil du temps, vous pouvez déjà créer une petite application, mais tout n'est pas clair. Vous commencez à pratiquer plus loin: prenez des livres plus avancés, allez à des réunions, menez des conversations avec des collègues sur le high. Mais alors un vrai projet est apparu. Avec vos connaissances, vous tombez dans un rôle de premier plan dans ce projet. La vie est belle! Et vous avez donc écrit le service parfait. Un seul problème subsiste. Que faire ensuite? Comment configurer le processus d'automatisation? Comment configurer un équilibrage intelligent? Comment trouver votre autre service? Vous n'avez peut-être tout simplement pas de réponse à ces questions! Êtes-vous toujours sûr que la FA est si nécessaire pour vous?

Conclusions

En fait, j'ai une attitude extrêmement positive envers la FA. Tout ce que je veux dire, c'est un outil qui est loin d'être toujours et partout. À mon avis, un ingénieur ne devrait pas penser dans des catégories comme / n'aime pas. Au lieu de cela, il devrait y avoir les raisons les plus objectives d'utiliser telle ou telle solution.

Avant d'étudier / introduire un paradigme fonctionnel, il faut se poser au moins trois questions: la possibilité de postuler dans votre domaine professionnel, son impact sur l'intégration avec des solutions toutes faites et si le temps et les ressources dépensés seront récompensés. Si vous n'avez pas d'attaque de panique liée à l'un de ces problèmes, vous pouvez la mettre en service.

Merci de votre attention!