Quels seraient les bons arguments factuels pour convaincre la haute direction de considérer la programmation fonctionnelle? [fermé]


15

Il y a des tonnes d'arguments «théoriques» pour expliquer pourquoi la programmation fonctionnelle est une bonne idée (trop pour que cela soit resté une question ouverte, et correctement).

Cependant, la plupart d'entre eux sont des arguments soit issus de la théorie ("élégance", etc ...), soit destinés aux développeurs.

Le problème est que la plupart d'entre eux sont totalement inutiles lorsque l'on a pour objectif de présenter l'idée à la direction d'une grande entreprise , dont certains ne sont même pas développeurs, et qui se soucient tous principalement d'arguments commerciaux : coût, gestion du capital humain , livraison de produits, service à la clientèle et revenus; ainsi que des faits quantitatifs sur des points théoriques qui ne peuvent tout à fait être étayés par des faits.

Y a-t-il des arguments convaincants à présenter pour répondre à ces préoccupations commerciales en ce qui concerne l'adoption de la programmation fonctionnelle en tant que concept (pas de langage spécifique), par rapport à la combinaison typique de procédures / POO, par exemple Java / C ++ / (Perl | Python) .

De préférence, je recherche des arguments quantitatifs et / ou basés sur des recherches ou des études de cas. Par exemple "selon cette référence, le taux de bogues des systèmes multithread en Lisp / F # est de 10% celui de Java" ou "80% des meilleurs diplômés exprimant les préférences de la technologie souhaitée nommée programmation fonctionnelle comme étant parmi les 3 principaux intérêts".

Je sais que Graham a présenté des cas d'utilisation de programmation fonctionnelle pour une starup et serait ouvert à certains de ses arguments en supposant qu'ils peuvent être valables pour une grande entreprise établie.

Je suis parfaitement conscient que vous pouvez faire quelque chose de proche de la programmation fonctionnelle en Perl, probablement Python, et (peut-être) même Java 8 ou C ++ 14. Mais cela ne signifie pas qu'une organisation utilisant Perl, C ++ ou Java approuverait la fonction vs POO / approches procédurales même dans ces langues

Pour les besoins de ce langage, "large" est défini comme suffisamment grand pour avoir un groupe dédié d'ingénierie / outils de développement, qui dicte ce que tous les développeurs sont autorisés à utiliser / faire; et au moins des centaines de développeurs bas de gamme .


1
Vous recherchez celui-ci, je suppose? paulgraham.com/avg.html En fait, je pense que l'article est un peu dépassé, entre de nombreux concepts fonctionnels sont entrés dans les langages traditionnels.
Doc Brown

34
Pourquoi la gestion de haut niveau devrait-elle se soucier des langages et méthodes de programmation utilisés? Pourquoi seraient-ils impliqués dans une telle décision? C'est sûrement l'affaire des responsables techniques?
High Performance Mark

8
@HighPerformanceMark: remplacez les "responsables techniques" par "la gestion de haut niveau" et réévaluez la question.
Robert Harvey

2
Dans quel domaine travaillez vous? Si vous faites de la programmation et du conseil en sous-traitance, la programmation fonctionnelle peut être un mot à la mode qui, selon la direction, impressionnera vos clients.
JeffO

3
Quels arguments commerciaux la direction vous a-t-elle donnés pour les langues que vous utilisez actuellement?
JeffO

Réponses:


7

Il y a un argument très simple, qui pourrait au moins amuser la direction.

Il est bien connu que les ordinateurs modernes ne deviennent pas "plus rapides" qu'avant, car la mise à l'échelle des fréquences, pour l'instant, atteint la limite. Ils augmentent leur productivité potentielle en ajoutant des cœurs.

Cela implique que pour bénéficier au maximum de cette architecture, les programmes doivent être parallélisés. Mais la programmation parallèle est beaucoup plus difficile que la programmation séquentielle, en raison de nombreux nouveaux défis qu'elle apporte (consultez l' article Wiki pour une vue d'ensemble complète).

La programmation fonctionnelle permet de se débarrasser de certains de ces défis, par exemple les conditions de concurrence ne s'appliquent pas si vous utilisez uniquement des variables et des méthodes immuables sans effets secondaires. La courbe d'apprentissage de la programmation fonctionnelle est souvent abrupte, mais la courbe d'apprentissage de la programmation parallèle peut être encore plus abrupte et pas du tout intuitive.

Donc, si le défi est d'écrire des programmes plus efficaces de manière plus efficace, on peut comparer les coûts de formation des gens à écrire des programmes parallèles avec les coûts de formation des gens à apprendre la programmation fonctionnelle, et les risques que les deux approches peuvent entraîner.

Concernant les langages mixtes (qui prennent en charge à la fois le style de programmation fonctionnel et impératif): à partir d'un certain point, ils pourraient être utiles pour la transition (les gens pourraient commencer à les utiliser de manière "familière" et apprendre progressivement de nouvelles approches). D'un autre point, cela pourrait être une bénédiction déguisée, car les avantages potentiels de la programmation fonctionnelle peuvent être annulés avec le code maladroit de quelqu'un. On peut atténuer cela en établissant des directives de codage claires (voir par exemple " Scala efficace " par Twitter), bien que suivre les directives nécessite un certain niveau de maturité d'équipe. De ce point de vue, les langages fonctionnels purs pourraient être "plus faciles" pour le développement de logiciels en raison des règles plus strictes qu'ils imposent par conception.


Si vous pouvez trouver des recherches / preuves réelles pour ces assertions pour les soutenir - en particulier "Les langages fonctionnels aident à se débarrasser de certains de ces défis" - jusqu'à présent, cela est sur le point d'être la meilleure réponse disponible.
DVK

Cette question a déjà été discutée à plusieurs reprises, par exemple quora.com/Why-does-functional-programming-favor-concurrency ou stackoverflow.com/questions/474497/…
Ashalynd

3
Sauf que de nombreux langages OOP prennent également en charge la programmation fonctionnelle, vous pouvez donc utiliser les aspects fonctionnels pour jeter le bébé avec l'eau du bain.
Andy

1
À droite, la question portait sur la "programmation fonctionnelle" et non sur les "langages fonctionnels". Va changer le libellé.
Ashalynd

40

Vous approchez cela du mauvais côté. Dans la plupart des entreprises, la direction n'est pas responsable du "choix du paradigme de programmation", elle est (ou du moins devrait être) responsable de l'efficacité du travail d'équipe. Si toute votre équipe est convaincue que la programmation fonctionnelle améliorera la vitesse ou la qualité de votre travail, il ne devrait pas être trop difficile de convaincre la direction également. De plus, si votre équipe commence tout juste à utiliser des constructions fonctionnelles dans vos langages de programmation établis, et tout le monde en est satisfait, vous ne devriez même pas avoir à demander une autorisation (diable, un non-programmeur pourrait même ne pas comprendre la différence entre les non constructions fonctionnelles et fonctionnelles, alors pourquoi voulez-vous discuter de ce problème avec lui?).

Mais attention, si le reste de votre équipe a une opinion différente sur la PF, et qu'ils commencent à se plaindre de votre code fonctionnel que les autres membres de l'équipe ne comprennent pas, vous pourriez avoir des problèmes avec la direction - pour une bonne raison, car dans un tel cas, l'équipe perd de son efficacité.

L'essentiel est donc de convaincre les autres membres de l'équipe ou vos chefs d'équipe, mais pas la gestion de haut niveau!

EDIT: en raison de votre commentaire - en fait, c'est une réponse à votre question ;-). Le seul argument factuel dont je parle est "toute l'équipe pense que la PF est utile pour faire le travail . À mon humble avis, c'est l'argument qui a le plus de chances d'être accepté par la direction de haut niveau, et il est très pratique à appliquer. Essayer d'utiliser des arguments techniques aux personnes non techniques travaillent directement rarement, non pas parce qu'elles sont "trop ​​stupides pour comprendre le raisonnement technique", mais parce qu'elles sont assez intelligentes pour savoir que les décisions techniques doivent être prises par des experts techniques, et elles sont également assez intelligentes pour ne pas se fier sur l'avis d'un seul expert.


7
Je suis étonné que 19 personnes aient voté pour une réponse qui ne répond pas du tout à la question . C'est une question pratique, dans une situation pratique. Les membres de l'équipe n'ont PAS de voix et n'ont pas besoin d'être convaincus. Ils ne travailleront pas non plus - et moi non plus d'ailleurs - sur une technologie / un langage non approuvé, comme la question est claire.
DVK

1
@DVK si personne d'autre ne verra votre code, vous n'avez pas besoin de convaincre quelqu'un d'autre que votre langue est bonne. Commencez simplement à l'utiliser.
user253751

2
@DVK - vous devez fournir plus d'informations sur la manière dont la direction contrôle les langues utilisées dans votre entreprise. Dans la plupart des cas, la direction a peu de contribution dans ce domaine car elle laisse le soin aux équipes et à leurs dirigeants.
JeffO

3
@DVK: Les personnes qui votent pour les réponses aux questions qu'ils trouvent sont les plus utiles pour la question posée. Si la plupart des gens votent pour des réponses qui indiquent que vous vous approchez du mauvais problème, cela pourrait suggérer qu'un grand nombre de programmeurs ont été des situations similaires et ont trouvé ces "non-réponses" utiles. La plupart conviennent qu'il y a quelque chose de fondamentalement malsain dans votre entreprise, et cela n'a rien à voir avec les choix linguistiques. La plupart conviennent que cela doit être abordé, toute tentative d'aller directement après le choix de la langue vous mènera simplement à l'obstacle suivant, plutôt qu'à une série de solutions.
Cort Ammon - Rétablir Monica le

1
@CortAmmon Bien que je convienne avec plaisir que la question indique un problème avec la façon dont la société du demandeur est gérée, il est très peu probable qu'il soit en mesure de résoudre de tels problèmes. J'ai vu de première main les problèmes que peut causer un CTO avisé (en fait, hier, j'ai dû consacrer beaucoup de temps à contourner un problème causé par une règle interdisant à notre entreprise de déployer des logiciels en dehors des "fichiers programme"). "répertoires sur les machines Windows, mais Ruby n'installera pas dans un répertoire avec un espace dans son nom.
Jules

16

Pour comprendre pourquoi la programmation fonctionnelle n'a pas envahi le monde, vous devez comprendre la pensée d'entreprise derrière les décisions de langage de programmation. Pour choisir Java pendant un moment:

  1. Il existe des armées de programmeurs disponibles qui peuvent écrire des rames de code Java ordinaire. Ce n'est pas le cas des programmeurs Lisp ou Haskell (ou même Scala).
  2. Tout le monde utilise Java, donc ça doit être bon. Corrolary: les gestionnaires n'ont pas à justifier leur choix de Java par rapport à un langage obscur dont personne dans la structure de commande n'a jamais entendu parler.

Si votre organisation est déjà ancrée dans le royaume des noms , il ne sera tout simplement pas possible de procéder à une modification complète de la programmation fonctionnelle. Le choix de la langue (et tous les autres choix qui l'entourent) est déjà profondément ancré dans la culture d'entreprise.

En supposant que votre objectif est de grandir en tant que développeur de logiciels, votre meilleur pari est de

  1. Intégrez des concepts fonctionnels à vos programmes existants là où ils sont utiles et appropriés,
  2. Utiliser les nouvelles fonctionnalités du langage fonctionnel au fur et à mesure qu'elles sont ajoutées au langage, et
  3. Apprenez les modèles de conception orientés objet, dont certains existent pour surmonter les carences du langage dans les langages OO qui ne sont pas présents dans les langages fonctionnels.

Les arguments de Paul Graham ne s'appliquent vraiment qu'aux startups, et il y a eu un certain nombre d'histoires de mise en garde d'entreprises qui ont commencé à utiliser des langages purement fonctionnels, mais elles ont ensuite été rachetées par une autre société dont le premier objectif était de convertir immédiatement la base de code fonctionnelle vers un langage OO afin que leurs développeurs de logiciels existants puissent le comprendre.


1
Non, mon objectif n'est PAS (aux fins de cette question) de "grandir en tant que développeur de logiciels". Mon objectif est de rassembler un meilleur ensemble d'arguments à présenter aux personnes qui prennent des décisions, ce qui les inciterait à autoriser la PF comme approche approuvée. Rien de plus et rien de moins. Mettez en évidence les avantages de la PF, en particulier par rapport à la pile standard de POO / procédure.
DVK

De plus, à moins que je ne fasse une erreur de formulation majeure, la question ne voulait certainement pas faire allusion au "changement en gros" comme résultat escompté des arguments recherchés.
DVK

+1 pour Kingdom of Nouns. Je l'ai appelé "La guerre entre les noms et les verbes".
Rob

4
@DVK: La façon de convaincre la direction de tout est la même depuis le début: montrez-leur comment cela leur fera économiser de l'argent.
Robert Harvey

9

Dans mon expérience (un peu cynique), ayant travaillé pour un magasin où nous avons utilisé la programmation fonctionnelle, et interviewé dans plusieurs autres:

  1. Il y avait toujours un CTO et d'autres techniciens de haut niveau qui avaient de l'expérience avec la programmation fonctionnelle et ont réussi à en convaincre les cadres non techniques. (Et d'ailleurs, ces gens sont mieux qualifiés que moi pour répondre à votre question.)
  2. Une fois que ces gens quitteront l'entreprise et seront remplacés par des gens qui n'ont pas cette inclination, les choses iront vers le sud. Les nouveaux gars imputeront tout ce qui ne va pas (y compris, et en particulier leurs propres échecs) au langage de programmation et au paradigme étranges utilisés pour construire ce qui a précédé. Ils marginaliseront les personnes restantes avec des compétences en programmation fonctionnelle, les expulsant de l'entreprise. Le système construit sur le langage fonctionnel se détériorera sans entretien. Ce genre de chose, à mon avis, le plus grand risque qu'une entreprise prend si elle adopte un langage fonctionnel, et ne doit pas être sous-estimé.
  3. L'organisation doit avoir une culture «construire au lieu d'acheter» pour que cela fonctionne. Parce que l'adoption d'un langage fonctionnel signifiera moins d'options "d'achat".
  4. Il y avait presque toujours un compromis sur les détracteurs techniques et non techniques de l'idée. Le plus commun de ces compromis est que tout langage non JVM était tout simplement hors de considération; Clojure et Scala ont été proposés, Haskell et O'Caml étaient tout de suite sortis du lot.

4

Éléments à prendre en compte pour la haute direction lorsque / si la haute direction est impliquée dans la sélection des langages de programmation (ce qui est étrange, ils devraient laisser cela à des personnes compétentes et compétentes (à la fois en technologie et en affaires):

  • Productivité
    • Employés actuels et futurs
    • Tous les rôles (architectes, développeurs, testeurs, OP, ...)
  • Plateformes prises en charge
    • Systèmes d'exploitation, (matériel?)
  • Editeur de la langue / plateforme
    • Licences
  • Maturité de la langue / plateforme
    • Support de / par l'éditeur et / ou la communauté
    • Bibliothèques
  • Migration de la base de code actuelle
    • Ou intégration avec

Notez que ceux-ci ne sont pas spécifiques aux langages de programmation fonctionnels. Ce ne sont pas non plus des arguments sauf si vous fournissez des données avec ceux-ci. Nous ne pouvons pas vous donner les données car elles dépendent complètement de l'environnement de votre entreprise. La seule chose que nous pourrions faire est de collecter des données sur le Web pour montrer combien de connaissances et d'intérêt il y a pour une langue spécifique. Soyez prudent lorsque vous traduisez de nombreuses questions sur StackOverflow ou de nombreuses balises sur Linkedin dans une langue populaire.


1
Les entreprises sont également préoccupées par l'embauche de personnes, donc s'il est plus difficile de remplacer un développeur fonctionnel, je dirais que c'est une bonne raison pour qu'elles soient impliquées dans de telles décisions.
Andy

1
@Andy - Oui, c'est pourquoi je ne réfute pas la question et je pense que les managers devraient s'intéresser aux sujets que j'ai énoncés. Mon souci est plus ou moins que la solution (Functional Programming Language) soit choisie AVANT que le problème (???) ne soit défini.
Erno

Est-il vraiment si difficile de remplacer un développeur fonctionnel? Par le nombre de développeurs informés qui publient ici et sur d'autres sites sur Internet, je soupçonne qu'il y a beaucoup plus de développeurs fonctionnels que ne le pensent les gestionnaires.
Giorgio

@Giorgio - Je n'ai jamais dit qu'il était difficile de les remplacer, mais d'après mon expérience, la disponibilité peut varier d'un endroit à l'autre. Certains diplômés des collèges n'ont même jamais appris les bases alors que certaines universités se spécialisent dans ces disciplines. Pour une entreprise, il est très important de regarder vers le long terme et le besoin attendu de nouvelles embauches.
Erno

@Erno: Je partage votre avis. Je commentais le commentaire d'Andy. Quoi qu'il en soit, j'ai toujours supposé qu'il y avait très peu de programmeurs fonctionnels et que FP était considéré comme quelque chose d'ésotérique. Dernièrement, mon impression est plutôt qu'il y a beaucoup plus de développeurs FP que d'emplois FP.
Giorgio

3

Je ne pense pas que les arguments ou les faits aideront. Et certainement pas sans énoncer les problèmes que vous souhaitez résoudre.

Contre la croyance commune et l'auto-évaluation typique, de nombreuses décisions sont prises en fonction du sentiment intestinal. Et souvent, ces décisions sont de très bonnes décisions, car elles intègrent à un niveau subconscient beaucoup d'expérience de la personne qui prend la décision.

Si vous voulez contester une telle décision comme "Nous nous en tiendrons au langage C jusqu'à la fin de tous les ordinateurs", vous devez faire plus que simplement fournir quelques arguments.

La première étape consiste probablement à découvrir les personnes et les raisons de la décision selon laquelle la haute direction devrait avoir son mot à dire dans ces décisions techniques. Bien sûr, je ne peux que deviner ici, mais il est très probable qu'ils aient un historique de décisions prises par des techniciens qui ont mal tourné. Avouons-le: la plupart des développeurs ne sont pas très bons pour prendre des décisions (même techniques) au niveau de l'entreprise.

Une fois que vous avez trouvé ces personnes, parlez-leur pour gagner leur confiance. La meilleure approche est peut-être de les écouter. De quoi s'inquiètent-ils, quels sont les risques et les chances qu'ils voient? Quels sont les problèmes auxquels ils sont confrontés. À partir de là, vous pourriez vous déplacer pour impliquer les techniciens dans ce type de décision. Souvent, la direction ne veut pas vraiment prendre ces décisions, mais ne lui fait pas confiance. Donc, si votre équipe commence à s'impliquer dans la décision architecturale et à démontrer que les décisions que vous proposez sont une bonne gestion, vous serez peut-être prêt à faire confiance à vous / à votre équipe.

Il est important de prendre de bonnes décisions architecturales:

  • Recueillir les contributions des parties prenantes (Management, Utilisateurs, Administrateurs, Ventes, Clients ...)
  • Baser les décisions sur cette entrée
  • Communiquer clairement: quelles sont les décisions (proposées); Quel risque ils visent à atténuer; Quels sont les intérêts contradictoires et avec un certain retard: leur efficacité.

Si vous travaillez pour une grande entreprise avec par exemple 10 000 employés, préparez-vous à apprendre certaines des leçons suivantes.

  • la vitesse de codage n'est pas vraiment pertinente pour le résultat final.
  • des choses comme la maintenabilité à l'échelle des décennies est.
  • les problèmes que vous pensez pouvoir résoudre en utilisant des langages fonctionnels ne sont pas vraiment pertinents pour les résultats
  • des problèmes comme la formation de 1000 développeurs, la résistance naturelle au changement et le maintien d'une base de code écrite par des développeurs ayant moins de 5 ans d'expérience dans la technologie utilisée sont.

Une fois que vous avez atteint un niveau de confiance que vos arguments sont entendus et considérés, vous aurez également établi un moyen de rassembler et de prendre en compte les exigences que vous, votre équipe et la direction avez confiance.

Si ce processus produit la recommandation d'utiliser une approche fonctionnelle dans certains domaines, vous avez terminé.

Si ce processus produit la recommandation d'ignorer les approches fonctionnelles allant au-delà de ce que propose le langage de programmation principal actuel, vous avez également terminé.

La mauvaise nouvelle est la suivante: selon la taille et le style de l'entreprise, cela peut facilement prendre quelques années ou décennies.

La bonne nouvelle est: vous apprendrez beaucoup en chemin.

Étant donné que la première étape consiste à commencer à parler et surtout à écouter la haute direction, je recommanderais de commencer par lire Just Listen .


3

Une bonne approche serait de montrer qu'elle a montré de bons résultats dans l'industrie et qu'elle a été adoptée.

Vous pouvez obtenir des données de:

Idéalement, essayez de parler aux gestionnaires de certaines sociétés cotées, surtout si vous êtes dans votre secteur, et obtenez des chiffres et des témoignages de leur part.

Google a de nombreux autres liens similaires pour Haskell, OCaml, etc.


3
Certaines entreprises vont voir cela comme une affaire contre, depuis plus nombreux que OO praticiens adhérents FP par une large marge .
Robert Harvey

1
@RobertHarvey - c'est un peu un argument de hareng rouge, au moins dans mon cas spécifique. Ils sont déjà assez intelligents pour savoir CELA. Ce qu'ils ne savent PAS (et ce que j'ai appris de cette réponse), c'est qu'Eaton Vance utilise Scheme et, plus important encore, Faceboook , BoA / ML, Deutsche Bank et Google [utilisez Haskell]. Ce qui signifie que c'est quelque chose qu'ils PEUVENT envisager de tremper un orteil, car d'autres dignes ont décidé de le faire. Étonnant que la seule réponse réellement utile qui ait essayé de répondre à la question que j'ai posée (et non celle à laquelle les gens avaient envie de répondre) soit celle avec le moins de votes
DVK

1
@dvk: La question que vous avez posée (si je comprends bien) est "Comment puis-je convaincre mes patrons que la FP est une bonne chose?" Eh bien, parfois ce n'est pas le cas. Nous vivons dans un monde mutable, et la programmation fonctionnelle est, en toute honnêteté, un peu bizarre. Si vous ne me croyez pas, jetez un œil aux monades. Les réponses qui traitent de ces bizarreries (et comment elles affectent le processus de conception et de développement de logiciels) sont utiles, que vous les pensiez ou non.
Robert Harvey

@RobertHarvey (1) Je reprends cela. Maintenant, DEUX réponses utiles sont les moins votées :) (une nouvelle qui vient d'être publiée pourrait être améliorée avec des faits, mais c'est un bon début).
DVK

@RobertHarvey - oui. La question n'était PAS "La PF est-elle une bonne chose" ou "Est-il possible de convaincre les gens que la PF est une bonne chose". La question était très précisément "Quels arguments peuvent être utilisés pour soutenir QUAND essayer de convaincre que c'est une bonne chose". Ce n'était PAS non plus "Comment puis-je introduire furtivement la PF dans mon travail / codage d'une manière positive", c'est ce que vous avez répondu - si c'était une option que je ne demanderais pas en premier lieu, je coderais: )
DVK

2

Vous arrivez à cela dans la mauvaise direction.

Vous essayez de convaincre la direction d'un passage à un paradigme fonctionnel pour votre propre amusement et vous essayez de saisir des arguments pour soutenir cela qui n'ont rien à voir avec la vraie raison pour laquelle vous le souhaitez. Sinon, vous n'auriez pas besoin de poser la question, car vous seriez en mesure d'énumérer vos arguments du haut de votre tête.

Ce à quoi vous devriez plutôt penser, c'est ce dont le besoin commercial actuel est et comment il est le mieux servi. S'il arrive qu'il soit mieux servi en utilisant un paradigme fonctionnel, alors - ouais! - vous pouvez jouer. Mais si vous faites une analyse juste, en tenant compte des besoins opérationnels opérationnels, de la formation nécessaire des collègues, des antécédents des futurs programmeurs, de la maintenance, etc., souvent, ce ne sera pas le cas.


2
C'est un peu pédant, et pas trop utile pour répondre à la question, qui devrait être abstraite en aidant simplement OP à sortir de son «approche».
VF1

1

La haute direction sans compétences techniques ne devrait pas se soucier d'aspects techniques tels que l'utilisation de paradigmes fonctionnels. Ce n'est pas leur domaine d'expertise et ça sent la microgestion. Pourquoi ne délèguent-ils pas ces décisions à des personnes qui ont effectivement les compétences requises?

Ceci étant dit, voici quelques conseils pour convaincre les personnes ayant des connaissances techniques (premier cas) et celles qui n'en ont pas (deuxième cas).

Premier cas

Si vous parlez à des gens qui connaissent la programmation , comparer le code écrit sans paradigmes de programmation fonctionnelle et le même code écrit dans un style fonctionnel peut être suffisamment convaincant:

Exemple de code C # qui utilise un style impératif:

var categorizedProducts = new Dictionary<string, List<Product>>();

// Get only enabled products, filtering the disabled ones, and group them by categories.
foreach (var product in this.Data.Products)
{
    if (product.IsEnabled)
    {
        if (!categorizedProducts.ContainsKey(product.Category))
        {
            // The category is missing. Create one.
            categorizedProducts.Add(product.Category, new List<Product>());
        }

        categorizedProducts[product.Category].Add(product);
    }
}

// Walk through the categories.
foreach (var productsInCategory in categorizedProducts)
{
    var minimumPrice = double.MaxValue;
    var maximumPrice = double.MinValue;

    // Walk through the products in a category to search for the maximum and minimum prices.
    foreach (var product in productsInCategory.Value)
    {
        if (product.Price < minimumPrice)
        {
            minimumPrice = product.Price;
        }

        if (product.Price > maximumPrice)
        {
            maximumPrice = product.Price;
        }
    }

    yield return new PricesPerCategory(category: productsInCategory.Key, minimum: minimumPrice, maximum: maximumPrice);
}

Même code réécrit avec la programmation fonctionnelle à l'esprit:

return this.Data.Products
    .Where(product => product.IsEnabled)
    .GroupBy(product => product.Category)
    .Select(productsInCategory => new PricesPerCategory(
              category: productsInCategory.Key, 
              minimum:  productsInCategory.Value.Min(product => product.Price), 
              maximum:  productsInCategory.Value.Max(product => product.Price))
    );

Demandez-leur ensuite:

  1. Combien d'erreurs un programmeur peut-il commettre dans le premier échantillon? Et le deuxième?

  2. Est-il difficile de repérer les erreurs?

  3. Est-il difficile de modifier le code?

Ces trois facteurs influencent la productivité, et donc le coût du produit.

Deuxième cas

Si vous avez affaire à des gens qui ne connaissent pas la programmation, il n'y a pas grand chose de technique à leur dire. L'une des façons d'être convaincant est de montrer l'impact réel des paradigmes fonctionnels sur votre travail et le travail de vos collègues.

Par exemple, comparez deux projets réalisés par la même équipe, l'un utilisant la PF, l'autre ne l'utilisant pas. Montrer que le nombre de bogues est beaucoup plus faible ou que c'était le premier projet que la société a réellement livré à temps devrait être suffisamment convaincant.


3
Je vois ce que vous avez fait là-bas, mais votre exemple n'est pas entièrement convaincant. Vous avez essentiellement déroulé votre exemple fonctionnel en un impératif, ce qui ne se produirait dans aucune entreprise pratique. Votre yield returnest un peu une triche, c'est un exemple de la façon dont vous prépareriez le code à utiliser dans un scénario Linq de toute façon, et vos ifdéclarations pourraient être écrites plus succinctement avec des opérateurs ternaires. Tout votre premier exemple pourrait être refactorisé en fonctions impératives, afin que la complexité soit cachée.
Robert Harvey

@RobertHarvey Vous pourriez refactoriser le premier exemple en un tas de fonctions impératives, mais ce seraient des fonctions impératives personnalisées qui sont spécifiques à cette requête; il vous faudrait tout de même le voir pour vous convaincre que la requête est correcte. Cette refactorisation ferait exploser encore plus la taille du code impératif. Même si vous pouviez l'écrire de manière aussi compacte, vous devez toujours lire attentivement le code car tout le travail se fait par le biais d'effets secondaires; vous ne voudriez pas manquer un effet secondaire en cours dans la deuxième partie d'un opérateur ternaire à la fin d'une ligne.
Doval

1
@RobertHarvey Je ne suis même pas sûr que les deux extraits de code soient équivalents, car l'impératif "filtre" en créant une deuxième liste au lieu de simplement sauter l'itération. Le véritable équivalent n'utiliserait-il qu'une seule boucle et serait-il donc encore plus profondément imbriqué?
Doval

5
Il ne fait aucun doute que vous faites un bon argument pour incorporer des concepts fonctionnels dans un langage par ailleurs impératif / OO, mais pas nécessairement un bon argument pour utiliser des langages entièrement fonctionnels dans un environnement d'entreprise qui est déjà impératif / OO.
Robert Harvey

Un autre problème (peut-être moins valable) avec votre exemple: je pourrais écrire le premier exemple en Perl pour la plupart non-FP entièrement lisible dans - je suppose - 30% du volume. Peut-être moins. Dépend si vous acceptez map/ grepcomme non-FP. IOW, vous présentez des arguments selon lesquels Java est un mauvais langage, pas que FP est une bonne approche.
DVK
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.