Preuve empirique du choix du paradigme de programmation pour résoudre un problème

Le wiki C2 a une discussion sur les preuves empiriques pour la programmation orientée objet qui conclut essentiellement qu'il n'y a rien au-delà de l'appel à l'autorité. Ceci a été édité pour la dernière fois en 2008. La discussion ici semble le confirmer : les questions de savoir si OO est obsolète , quand la programmation fonctionnelle est un mauvais choix et les avantages et les inconvénients de l'AOP sont toutes répondues avec les opinions des contributeurs sans s'appuyer sur des preuves.

Bien sûr, les opinions de praticiens établis et réputés sont les bienvenues et précieuses, mais elles sont plus plausibles lorsqu'elles sont cohérentes avec les données expérimentales. Ces preuves existent-elles? Je sais que le génie logiciel basé sur des preuves est une chose, mais puis-je le pratiquer dans ce contexte? Plus précisément, si j'ai un problème particulier Pque je veux résoudre en écrivant un logiciel, existe-t-il un ensemble de connaissances, d'études et de recherches qui me permettraient de voir comment le résultat de la résolution de problèmes tels que Pdépend du choix du paradigme de programmation?

Je sais que le paradigme qui apparaît comme «la bonne réponse» peut dépendre des paramètres auxquels une étude particulière prête attention, des conditions dans lesquelles l'étude reste constante ou varie, et sans doute également d'autres facteurs. Cela n'affecte pas mon désir de trouver ces informations et de les évaluer de manière critique.

Il devient clair que certaines personnes pensent que je recherche une solution "tourner la manivelle" - une machine à saucisse dans laquelle je mets des informations sur mon problème et d'où sort un mot comme "fonctionnel" ou "structuré". Ce n'est pas mon intention. Ce que je recherche, c'est une recherche sur la façon dont - avec beaucoup d'avertissements et d'hypothèses que je ne vais pas aborder ici, mais une bonne littérature sur le sujet - certaines propriétés du logiciel varient en fonction du problème et du choix du paradigme.

En d'autres termes: certaines personnes disent que "OO donne une meilleure flexibilité" ou "les programmes fonctionnels ont moins de bugs" - (une partie de) ce que je demande en est la preuve. Le reste demande des preuves contre cela, ou les hypothèses sous lesquelles ces déclarations sont vraies, ou des preuves montrant que ces considérations ne sont pas importantes. Il existe de nombreuses opinions sur la raison pour laquelle un paradigme est meilleur qu'un autre; y a-t-il quelque chose d'objectif derrière tout cela?

Pour la prise précédente, voir la révision 1 de cette réponse . Cependant, les commentaires et les modifications à la question clarifient davantage ce que la question cherche et me permettent d'être plus clair.

Oui, l'ingénierie logicielle basée sur des preuves (EBSE) est une chose. Il semble y avoir quelques efforts vers les bases de données EBSE, comme celle-ci à l'Université de Durham et SEED, qui a été lancée par un professeur à Cal Poly . Tous ces efforts, ainsi que ceux discutés dans un certain nombre d'articles qui peuvent être trouvés via le serveur IEEE Xplore ou la bibliothèque numérique ACM(abonnement ou achat requis pour de nombreux articles dans les deux), sont basés sur la médecine factuelle. Ils fournissent une revue de la littérature des données empiriques publiées (observation et expérience). En fait, l'inclusion de la «revue de la littérature» dans une chaîne de recherche sur n'importe quelle recherche de publication donne des informations sur la plupart des sujets - plus de 14 000 visites sur l'ACM et plus de 1 000 sur la base de données IEEE (lorsqu'elle est limitée aux seuls sujets informatiques).

En regardant les types généraux de sujets abordés dans ces bases de données EBSE et revues de littérature, je vois un fil conducteur - ils ont tendance à être indépendants de la technologie. L'accent semble être principalement centré sur les processus et la méthodologie plutôt que sur les outils spécifiques utilisés pour effectuer le génie logiciel.

Donc, ce concept existe en génie logiciel. Le milieu universitaire connaît le concept fondé sur des preuves et peut l'appliquer avec succès au génie logiciel.

Plus précisément, la question porte sur l'application des techniques EBSE à la sélection d'un paradigme semble difficile, en raison du grand nombre de variables impliquées, obligeant à faire des hypothèses ainsi qu'à réduire la capacité de répéter l'expérience ou l'observation. Il est dit juste dans la question - "quel paradigme apparaît comme" la bonne réponse "peut dépendre des paramètres auxquels une étude particulière prête attention, des conditions dans lesquelles l'étude reste constante ou varie, et sans doute également d'autres facteurs" . Bien que cela ne signifie pas qu'étudier quel paradigme est le "meilleur" dans une situation donnée, cela rend toute sorte de revue de la littérature de ces documents incroyablement difficile à compléter et à extraire des informations à travers eux.

Il n'y a certainement pas de solution "tourner la manivelle" pour choisir un paradigme.

Étant donné un paradigme de programmation, vous pouvez trouver des études dans les différentes bases de données universitaires et industrielles sur la façon dont ce paradigme influence divers aspects du développement de logiciels - qualité, défauts, efficacité, etc. - dans diverses conditions spécifiques, allant de la connaissance et de l'expérience du équipe au domaine du problème. Tout document rigoureux doit clairement identifier les conditions dans lesquelles les données ont été collectées et les hypothèses. Le problème devient d'essayer d'isoler les facteurs qui le rendent bon dans chacune de ces conditions.

D'un point de vue académique, certaines déclarations sont faciles à rechercher. Par exemple, l'affirmation selon laquelle le paradigme fonctionnel est bien adapté aux applications qui nécessitent une concurrence provient du théorème de Church-Rosser . Pour cette raison, il est probable qu'un système logiciel écrit dans un langage fonctionnel aura moins de défauts liés à la concurrence que le même système écrit dans un langage procédural ou orienté objet.

Cependant, d'un point de vue pratique, une équipe logicielle ne peut pas toujours utiliser "le meilleur" outil ou technique pour le travail simplement parce que la recherche l'indique. Bien que nous nous efforçons de produire des systèmes logiciels de la plus haute qualité, nous opérons dans les limites des contraintes. Souvent, je vois ces contraintes minimisées (ou même supprimées de l'équation) lorsque je discute de l'efficacité de toute méthodologie.

En tant que praticien, lorsque je suis impliqué dans le choix des technologies à utiliser, j'essaie d'identifier les meilleurs outils possibles. Mais ensuite je me contrains à ce qui est connu et bien compris par l'équipe que j'ai. Pour revenir à mon exemple précédent, si j'ai une équipe qui connaît bien la construction d'applications simultanées en C ++ et aucune expérience en Haskell, cela n'a pas de sens de proposer de construire le système dans Haskell car je ne serai probablement pas en mesure de faire calendrier et contraintes budgétaires, et ma qualité souffrira probablement en raison d'un manque d'expérience dans la chaîne d'outils.

Pour récapituler, le génie logiciel fondé sur des données probantes est généralement une bonne chose qui existe et des analyses documentaires existent et sont facilement disponibles. Cependant, il existe des aspects de l'ingénierie logicielle où l'application d'approches fondées sur des preuves offre peu de valeur. La sélection d'un paradigme de programmation pour un effort de développement à grande échelle en fait partie.

Si vous souhaitez savoir comment l'orientation objet résout la réutilisation ou les défauts de programmation fonctionnelle, vous trouverez facilement des publications à ce sujet. Cependant, je n'ai pas trouvé (et je ne ferais pas confiance à) une publication capable de traiter efficacement la sélection de paradigmes dans le large éventail de projets d'ingénierie logicielle du monde réel.

J'ai lu The Art of Unix Programming par Eric S. Raymond. Il contient des informations historiques très intéressantes sur les choses que nous tenons maintenant pour acquises. Il cite quelques bonnes études du logiciel IEEE qui utilisent des preuves empiriques comme la densité des défauts. Cela pourrait être une bonne source si vous recherchez des études de style académique.

Même des techniques comme la modularisation à l'aide de fonctions n'étaient pas toujours une pratique courante. Une de mes citations préférées du livre jusqu'à présent:

Dennis Ritchie a encouragé la modularité en disant à tout le monde que les appels de fonction étaient vraiment, vraiment bon marché en C. Tout le monde a commencé à écrire de petites fonctions et à modulariser. Des années plus tard, nous avons découvert que les appels de fonction étaient encore chers sur le PDP-11 et que le code VAX passait souvent 50% de son temps dans l'instruction CALLS. Dennis nous avait menti! Mais c'était trop tard; nous étions tous accrochés ...

- Steve Johnson

Cependant, il y a vraiment deux problèmes à devenir trop empirique. La première est que la qualité du code est une chose très subjective. Le code peut être terrible et toujours correct. La perception qu'ont les gens d'un paradigme de programmation est une mesure très valable, car le code est écrit pour que les gens lisent autant que pour les ordinateurs, sinon plus.

Le deuxième problème est que 50% des développeurs ont un talent de programmation inférieur à la moyenne. Peu importe si votre développeur principal est plus productif en utilisant la programmation fonctionnelle si le "rabble" a du mal à écrire un logiciel de travail en l'utilisant, sans parler de beaux logiciels bien architecturés. De même avec les langages de programmation TMTOWTDI , votre développeur principal va toujours écrire du code propre et modulaire, mais des codeurs moins talentueux écrivent du bruit de ligne en raison du manque de structure imposée.

C'est pourquoi je pense que la POO a atteint le sommet de la popularité malgré ses lacunes. Ce n'est pas si restrictif qu'il entrave les plus talentueux, mais sa structure offre un moyen concis de communiquer et d'imposer de bons principes de conception aux moins talentueux.

Dans notre ligne de travail, nous avons tendance à évaluer une solution trop basée sur ses seuls mérites techniques. Une entreprise réussie doit également tenir compte du côté humain de l'équation.

Il existe des concours de programmation qui utilisent un système de notation informatique et vous permettent d'écrire dans différentes langues et de publier toutes sortes de résultats et de choses. Je parie qu'ils ont de bonnes données pour vous. Voici une liste de 8: http://www.makeuseof.com/tag/8-onlineprogramming-contests-challenge-win/

J'imagine que vous pouvez faire des comparaisons significatives de solutions à des problèmes très simples et clairs, comme la somme des carrés ou la série de Fibonacci, ou tracer une ligne droite en utilisant l'algorithme de ligne de Bresenham. La plupart des tâches de programmation du monde réel n'ont pas de tels objectifs clairement définis et chaque langue a ses points faibles. La plupart des avantages d'une langue sont subjectifs. Vous pouvez trouver des données plus significatives en sondant le bonheur du programmeur et du client qu'en comptant des lignes de code ou des nombres de défauts.

Je me souviens que lorsque j'ai passé une demi-journée à écrire l'un de mes premiers programmes Awk, je pensais que cela m'aurait pris une semaine entière pour faire la "même" chose en Java. Mais c'est parce que ma solution Java se serait concentrée sur la robustesse alors que la solution Awk était rapide et sale et nécessitait quelques ajustements manuels sur l'entrée et la sortie et était vraiment jetable quand j'avais fini. Awk et Java sont tous les deux géniaux, mais pas pour les mêmes choses.

Je suppose que ce que je dis, c'est que pour les applications du monde réel, comparer les langues ou les outils de manière significative est extrêmement difficile - le problème des vieilles pommes et oranges. Bonne chance! J'adorerais voir ce que vous découvrirez.

J'étudie différentes façons de développer des logiciels depuis plus de 30 ans. Il y a un manque de bonnes preuves publiées sur le choix d'un paradigme.

J'ai rassemblé une grande bibliographie ASCII consultable. Cela comprend de nombreux articles et articles IEEE et ACM. J'étiquette les articles avec le type de preuve fourni. Voici les balises les plus courantes:

...
133 =EXPERIMENT
177 =HISTORY
233 =IDEA
267 =SURVEY
338 =ESSAY
395 =THEORY
454 =ADVERT
491 =EXPERIENCE
500 =DEMO

Maintenant, recherchez PARADIGM et comptez les balises

  1 =ESSAY
  1 =EXPERIENCE
  1 =HISTORY
  1 =IDEA
  1 =POLEMIC
  1 =SURVEY
  1 =TALK

Si vous souhaitez creuser plus profondément, http://cse.csusb.edu/dick/lab.html et j'espère que cela vous aidera ...

Il semble que dans de nombreux cas, il n'y a pas de corpus de recherche suffisamment important ou de qualité suffisante pour permettre de tirer des conclusions générales sur la question de savoir si une pratique en génie logiciel est meilleure qu'une autre. Je cherchais spécifiquement des recherches sur le travail dans différents paradigmes, mais le manque de disponibilité ne se limite pas à ce domaine, donc je vais cadrer ma réponse dans un sens plus large.

Un article de 2004, Evidence-Based Software Engineering par Kitchenham et al , couvre assez succinctement les avantages à tirer d'une approche factuelle et les problèmes de sa mise en œuvre en génie logiciel. Je ne vais pas discuter du côté des avantages ici (il ressort clairement de la question que j'aimerais pouvoir travailler de cette façon), mais les problèmes sont pertinents en tant que réponse à la question que j'ai posée.

• Premièrement, si vous n'êtes pas membre de l'ACM, vous ne pouvez probablement pas lire le lien ci-dessus, qui couvre le premier problème: toutes les recherches existantes ne sont pas réellement disponibles pour les praticiens.
• une grande partie de la pratique du génie logiciel se déroule en secret dans le cadre de processus commercialement confidentiels, il n'y a donc aucune visibilité sur ce qui a fonctionné ou non pour ces personnes.
• le génie logiciel est une pratique qualifiée, il est donc difficile (pas impossible, simplement difficile) d'organiser une étude en aveugle.
• les différentes parties du cycle de vie du logiciel affectent les résultats des autres dans une mesure difficile à contrôler dans toute expérience.
• comme en témoignent les discussions ici, de nombreux praticiens ne considèrent pas «la littérature» (ou l'aspect académique du génie logiciel en général) comme pertinent pour leur travail.

Donc la réponse que je recherche est "non", les preuves que je recherche n'existent probablement pas. Je devrais choisir mon paradigme en fonction des critères populaires existants de ce que je sais, de ce qui est cool et de l'opinion d'experts.

Je ne crois pas que ce type d'étude existe. On pourrait croire que ce n'est pas le paradigme de programmation qui compte autant que l'algorithme réel qui est utilisé. Par exemple, étant donné tout système non trivial qui s'appuie sur des algorithmes à petit espace, un qui s'appuie sur des algorithmes à petit temps générerait des métriques différentes. Celui qui a le meilleur temps serait probablement jugé plus valide, sauf si l'espace est un problème, alors l'inverse est vrai. Je trouve cela similaire à paver une route. Bien que l'algorithme ou la recette de fabrication des matériaux soit constant tout au long de tous les processus, il serait possible qu'une entreprise pense que paver deux voies à la fois (une de chaque côté de la route) est mieux que de paver deux voies du même côté de la route à la fois . À la fin de la journée, cela n'a pas d'importance car le processus de fabrication du haut noir est toujours le même, la seule différence est l'approche. Pour en revenir à la programmation, si vous avez une équipe de développeurs C, écrivez le code de manière procédurale, si vous avez une équipe de développeurs Java, écrivez-le en OO. Ne vous accrochez pas tant au paradigme qu'à l'implémentation de l'algorithme. Parce qu'à la fin de la journée, vous pouvez écrire Java comme C et vous pouvez essayer d'écrire C comme Java.

METTRE À JOUR

Pour répondre au commentaire, Graham m'a laissé:
Je suppose que par architecture, vous entendez le paradigme de programmation. Si vous comptez utiliser Clojure, vous devriez peut-être embaucher une équipe de programmeurs Clojure. Cependant, basé sur une recherche rapide, Clojure est un langage basé sur Java, il se trouve qu'il est fonctionnel. Étant donné ces informations, je prendrais les programmeurs Java (car techniquement, ils peuvent simplement écrire Java et cela vous donnera les mêmes résultats) ou chercher des programmeurs fonctionnels tels que les développeurs Haskell. Maintenant, en termes de choix de ce qui est le mieux, cela dépend complètement de votre équipe. Je n'aurais jamais une équipe d'experts en bases de données relationnelles pour organiser une solution cloud pour moi ni une équipe de programmeurs fonctionnels pour construire une solution orientée objet pour moi. Vous devez utiliser les forces de l'équipe, vous n'avez pas la vision glorifiée que vous avez dans votre tête pour ce qu'une équipe "devrait"

Différents paradigmes conduisent à des solutions différentes. Le meilleur ajustement dépend en grande partie:

• la solution
• l'équipe de développement
• l'environnement opérationnel

Je ne connais aucune étude aussi définitive, et même s'il y en avait une, je n'y ferais pas confiance.

C'est le travail de l'architecte.

Remplacer la sagesse de l'architecte par les conclusions éventuellement non pertinentes d'une étude est une recette pour un désastre.

Remarque: un commentaire mentionne le choix de "l'algorithme" puis le choix de la langue. Les algorithmes sont le mécanisme structurel central des langages procéduraux. Les langages orientés objet se concentrent sur les classes et les modèles de collaboration / communication. Si vous êtes convaincu (en tant qu'architecte) qu'une solution centrée sur l'algorithme est «la meilleure», alors restez avec des langages procéduraux ou fonctionnels.

Addendum: ne pas se fier aux études n'est pas de la «superstition», c'est du bon sens. Les expériences scientifiques doivent être objectives et reproductibles. Les projets logiciels sont très subjectifs, mais pire encore, ce sont des expériences irremplaçables . Vous ne pouvez tout simplement pas implémenter un projet X avec l'équipe Y, mesurer les résultats, puis revenir en arrière, effacer les souvenirs et refaire le même projet avec la même équipe. Les informations découvertes ou sous-entendues par les études peuvent être utiles à l'architecte, mais elles ne peuvent jamais être définitives.