Impossible d'expliquer la monade

Non, ce n'est pas une autre tentative d'expliquer les monades. Je ne sais pas comment faire et je ne peux pas imaginer comment, par exemple, à partir du présent, je pourrais m'expliquer cela à partir du passé.

Il en va de même pour les autres concepts de PF. Je comprends leur valeur, comment les utiliser. Mais je ne sais pas comment transmettre cela à des personnes initialement négativement enclines à une approche fonctionnelle. Je ne pense pas que cela soit possible. La pratique résout facilement ce problème, mais les gens y parviennent rarement.

Je ne sais même pas comment répondre à des questions plus simples. Malgré le fait que j'écris sur Scala depuis plus de 3 ans, je ne peux pas expliquer sur les doigts les avantages de la langue pour une personne extérieure. Par exemple, il y a quelques mois, j'ai eu une bonne discussion.

Tout a commencé par la question: «Et pour qui votre langue est-elle écrite?» .
Toutes ces immunités, fonctions d'ordre supérieur, système de type génial, effets secondaires et autres monades tournaient dans ma tête, mais j'ai compris que ce n'était pas tout ça. La clarification suivante m'a finalement envoyé un KO: "Ici, par exemple, Java est un langage pour les cols blancs . " Ce dialogue s'est terminé par un non-sens incohérent sur l'incapacité d'expliquer la différence sans pratique.

Nous ne savons pas comment vendre FP

Il ne s'agit pas seulement d'une nouvelle version de l'expérience personnelle. Nous tous, utilisateurs de langages fonctionnels, sommes à peu près dans la même situation. Nous comprenons parfaitement l'énorme différence par rapport aux langages Blub , mais le reste du monde ne veut pas nous entendre. Bien sûr, on peut être en colère contre les conservateurs limités qui colportent «G», portent calmement des bêtises, se racontent des mythes et des contes de fées, entrent fermement et avec confiance dans des discussions sur des choses sur lesquelles ils n'ont même pas passé quelques heures. Vous pouvez également blâmer les grandes sociétés avec leurs équipes de marketing.

Mais il me semble tout d'abord que le problème est que nous ne savons pas nous-mêmes comment vendre la PF. Oui, ce n'est pas une tâche facile. Bien que, quand je me souviens comment les gens prennent des décisions, comment et quelles choses sont incluses dans les tendances, je commence à penser que c'est possible.

Il y a toujours quelque chose qui ne va pas avec le développement.

• Les processus sont lents! Et maintenant, après quelques années, tous les matins, dans tous les bureaux du pays, les gens debout au tableau noir font glisser les autocollants d'une colonne à l'autre.
• Le déploiement est lent! Et armé de valeurs devops, nous faisons 10 versions par jour, tandis qu'une nouvelle génération d'admin les inonde de tonnes de rubis, de python et de yaml.
• Les applications sont compliquées! Ainsi, des équipes de 2-3 développeurs construisent une nouvelle architecture de microservices, réfléchissent en détail aux responsabilités de chaque service et effectuent 10 demandes de pool pour une petite révision.

Non pas que je considère tous ces engouements pour l'industrie comme mauvais. Ils ont aussi beaucoup de défauts. Et tout le monde ne savait pas comment ni comment les cuisiner correctement. Réglage pratique manquant ou manquant. Cependant, ces approches sont devenues la norme «de facto» pour l'industrie. Et bien que la discussion sur le docker en production semble pour certains une question ouverte, tout est déjà arrivé.

Je suis sûr que la même chose peut arriver avec les langages fonctionnels. Oui, ce n'est pas tout à fait correct - comparer les langages de programmation avec les méthodologies et les approches. Mais nous avons quelque chose à emprunter dans leur positionnement pour nous-mêmes. Tous ont un problème strictement défini qu'ils résolvent. Et c'est la vitesse: développement, communications, planification, déploiement, changements ...

Pourquoi oublions-nous de dire la chose la plus importante?

Dans le même temps, du point de vue du positionnement des langages de programmation fonctionnels, il est difficile de dire qu'ils ont un objectif clair et compréhensible. Les spécialistes en linguistique « FP vs OOP » glissent généralement rapidement dans une mesure de caractéristiques et de concepts dont la valeur n'est pas bien comprise par le camp OOP. Les articles et rapports du format « Vous voyez comment ces monades sont superbement composées » renforcent souvent chez les gens l’opinion qu’ils n’en ont pas besoin, qu’ils s’inspirent pour essayer. Toutes ces interactions répondent rarement à la question « Pourquoi est-ce tout? " Beau et concis? Eh bien, au mieux, moins d'erreurs seront mentionnées.

La chose la plus importante dans l'utilisation des langages fonctionnels est la même vitesse de développement! Et cette vitesse est atteinte par tous ces termes, concepts et propriétés ennuyeux et effrayants qui en découlent. Composition plus légère grâce à des fonctions d'ordre supérieur - plus à la vitesse de développement. L'immunité, en plus de la fiabilité et moins d'erreurs, équivaut à donner plus de temps pour les choses utiles, au lieu de le consacrer au débogage, aux correctifs et au support. Eh bien et ainsi de suite, je pense que la logique est claire.

Oui, cela semble trop simple et même évident.

Oui, je n'ai rien dit de nouveau ici. Mais l'importance de la formulation et de l'accent est importante. Malheureusement, c'est ainsi que fonctionne notre pensée. Pour faire tomber les barrières, les explications seules ne suffisent pas. Besoin de pratique! Il est nécessaire qu'une personne ou une entreprise veuille y consacrer du temps. Les références à «l'académicité» ou à la beauté relative inciteront peu de gens à passer plusieurs jours à se sentir idiots.

Il vaut la peine d'arrêter de vous construire en tant que gars sages, dispersant immédiatement les termes gauche et droite, prouvant la supériorité de votre PJ préféré sur Blub . Au lieu de prouver l'utilité de la fonctionnalité X, il est beaucoup plus facile de l'utiliser comme explication d'une propriété plus compréhensible. Si d’autres techniciens ont réussi, il est peut-être temps que nous prenions également nos responsabilités et que nous intervenions fermement avec des choses évidentes et simples.

Alors la prochaine fois, avec les difficultés de répondre à la question « Pourquoi? », N'hésitez pas à opter pour des atouts, tels que: vitesse de développement plus élevée , support moins cher , moins de développeurs .

Ah, et plus. Les événements communautaires jouent également un rôle important dans le positionnement!
Par conséquent, nous attendons tous ceux qui ne sont pas indifférents à la PF lors de la seule conférence fonctionnelle en Russie - FPURE - Kazan - 24-25 mai .
Le programme comprend: Haskell, Scala, Elixir, Clojure, théorie et pratique, et bien sûr de nombreuses personnes partageant les mêmes idées avec qui il y a de quoi parler!