Bonjour, Habr!
J'attire votre attention sur une traduction de l'article «
Trois paradigmes » de Robert C. Martin (oncle Bob).
Au cours des 40 dernières années, les technologies matérielles ont augmenté la puissance de calcul de nos appareils de plus de vingt ordres de grandeur. Maintenant, nous jouons Angry Birds sur nos téléphones, qui ont la puissance de traitement d'un superordinateur refroidi au fréon des années 70 du siècle dernier.
Mais au cours des 40 mêmes années, la technologie logicielle n'a pas beaucoup changé. En fin de compte, nous utilisons toujours les boucles if, while et les opérateurs d'affectation que nous utilisions dans les années 60. Si je prenais un programmeur de 1960 et que je le amenais ici pour qu'il puisse s'asseoir devant mon ordinateur portable et écrire du code, il lui faudrait 24 heures pour se remettre du choc, mais il pourrait écrire ce code. Les principes n'ont pas tellement changé.
Dans le processus d'écriture des programmes, trois choses ont changé. Je ne parle pas de matériel, pas de vitesse d'ordinateur et pas des outils incroyables que nous avons. Je veux dire le code lui-même. Trois choses ont changé dans le code. Vous pouvez les appeler des paradigmes. Et ils ont tous été «découverts» il y a plus d'une décennie, il y a plus de 40 ans.
* 1968 -
Programmation structurelle .
Edsger Dijkstra a écrit son article: «Sur les dangers de l'opérateur Go To» et un certain nombre d'autres documents et articles proposant d'abandonner l'approche Go To débridée, en la remplaçant par des outils tels que les boucles if / then / else et while.
* 1966 -
Programmation orientée objet .
Ole-Johan Dahl et
Kristen Nyugor , étudiant le langage
algol , «découvrent» les objets et créent le premier langage orienté objet, Simula-67. Bien que cette réalisation ait de nombreuses perspectives, elle n'a apporté aucune nouvelle fonctionnalité à notre code. De plus, il en a supprimé un. Après tout, avec l'avènement du polymorphisme, le besoin de pointeurs sur les fonctions a disparu, mais a en fait disparu.
* 1957 -
Programmation fonctionnelle .
John McCarthy crée Lisp, le premier langage fonctionnel. Lisp était basé sur
le calcul lambda créé par Alonzo Church dans les années 30. Bien qu'il existe de nombreuses perspectives pour la programmation fonctionnelle, il existe une énorme limitation dans tous les programmes fonctionnels. Ils n'utilisent pas d'affectation.
Trois paradigmes. Trois limitations. La programmation structurelle établit les règles du transfert de contrôle direct. La programmation orientée objet introduit des règles pour le transfert indirect de contrôle. La programmation fonctionnelle introduit des restrictions sur l'affectation. Tous ces paradigmes ont emporté quelque chose. Aucun d'eux n'a ajouté de nouvelles fonctionnalités. Chacun d'eux a augmenté les exigences et réduit les opportunités.
Pouvons-nous créer un autre paradigme? Y a-t-il autre chose qui peut être supprimé?
Depuis 40 ans, il n'y a pas eu de nouveau paradigme, donc c'est peut-être un bon signe qu'il n'y a plus rien à rechercher.
Faut-il utiliser tous ces paradigmes, ou pouvons-nous choisir?
Au fil du temps, nous avons décidé de les mettre en œuvre. L'introduction de la première programmation structurée a été rendue possible par l'abolition du principe Go To (comme le recommandait Dijkstra dans son article). La POO a été mise en œuvre avec succès en remplaçant les pointeurs par des fonctions dans nos langages modernes utilisant le polymorphisme (par exemple Java, C #, Ruby). Par conséquent, au moins pour ces deux, la réponse à cette question est que nous devons les utiliser. Toutes les autres options ont été exclues ou du moins sévèrement limitées.
Mais qu'en est-il de la programmation fonctionnelle? Faut-il utiliser des langues qui n'ont pas d'opérateur d'affectation? Probablement oui! Nous écrivons déjà du code qui devrait bien fonctionner sur plusieurs cœurs, et ces cœurs se multiplient comme des lapins. Mon ordinateur portable a 4 cœurs. Mon prochain en aura probablement 8. Celui après 16. Comment allez-vous écrire du code fiable avec 4096 processeurs luttant pour le droit d'accéder au bus?
Nous pouvons difficilement faire fonctionner deux threads parallèles, sans parler des processeurs 2 ^ n.
Pourquoi la programmation fonctionnelle est-elle un élément important pour résoudre ce problème? Parce que ces programmes n'utilisent pas d'affectation, ce qui signifie qu'ils n'ont pas d'effets secondaires et, par conséquent, n'ont pas de problèmes associés avec la mise à jour - du moins c'est la théorie.
Nous parlerons davantage de programmation fonctionnelle dans les prochains blogs. Ce qui me frappe dans les trois paradigmes mentionnés ci-dessus, ce sont leurs dates. Ils sont anciens, presque plus vieux que moi. Et depuis que j'ai eu 16 ans, il y a 42 ans, il n'y en a pas eu de nouveaux.