points de vue

Dans ce premier billet de l’année 2018, je vais m’essayer de vous présenter ce que sont les foncteurs, les foncteurs applicatifs et les monades de façon simple, sans étalage de la théorie mathématique derrière (celle des catégories) dont, de toute manière, je ne maîtrise pas. Bien que ce soient des constructions utilisées dans la programmation fonctionnelle, elles peuvent aussi être utilisées dans d’autres approches de programmation et avec d’autres langages que ceux fonctionnels. C’est pourquoi je présenterai chacun des concepts non seulement avec du code en Haskell mais aussi en Java.

Il arrive dans un projet en Java de se trouver, selon le métier ou le domaine adressé, avec des classes d’objets obèses en méthodes qu’elles soient publics ou propres aux objets de la classe. Or, sachant que l’on passe plus de temps à lire, voir à toucher du code existant qu’à en écrire de nouveaux, ceci peut vite devenir pénible. Evidemment, avec nos IDE actuels, il est facile de naviguer entre les différentes méthodes et propriétés d’une classe. Mais en général ceci signifie que l’on sait, déjà, à peu près ce que l’on cherche ou que l’on connait a minima les responsabilités ou certaines particularités d’implémentation de la classe. Lorsqu’on doit toucher du code inconnu ou au mieux revenir sur du code au bout de 6 mois, nous aimons bien identifier aisément les parties à utiliser ou à retoucher et accéder à l’essentiel sans se perdre dans les méandres de la ou des classes inspectées. En effet, il peut être difficile, avec de telles classes, de démêler le comportement de l’objet, ce qui le caractérise, du reste. En tout cas c’est mon cas. Pour éviter de tels embonpoints, je vous propose d’utiliser les approches de certains langages fonctionnels comme Haskell (ou OCaml), dans lesquels les types et les fonctions sur ces types sont séparés (au sein d’un même module tout de même).

Dans certains langages de programmation, comme Java, il n’y a pas de méthodes ou d’opérateurs distincts entre l’égalité d’identité et celle de valeur. Si, dans un programme classique écrit dans un langage comme Java, l’égalité d’identité (de l’OID pour Object IDentifier) pourrait se faire avec l’opérateur == et celle de valeur avec la méthode equals surchargée, il n’en va plus de même dès qu’il s’agit d’objets persistés. Et là, in fine, c’est le drame : que compare t’on avec la méthode equals ? la valeur des objets ou leur identité ?

J’aime à dire que l’évolution en informatique ne connait que très peu de ruptures et ressemble à une grande spirale dans laquelle les nouvelles technologies et approches ne sont que des reprises de plus anciennes que l’on a dépoussiéré et adapté aux attentes et au temps actuels ; c’est ce que l’on appelle l’innovation. Les micro-services, le grand buzz de l’année 2015, n’échappent pas à cette régle. (On est friand aussi de buzz en informatique). Mais qu’est-ce que les micro-services ? En fait, rien de spécial. Ce n’est ni plus ni moins que le découpage des responsabilités des applications dans des services Web dédiés et qui communiquent entre eux par messages. Du SOA ? Du REST ? … Oui, tout ça mais ce n’est plus à la mode, il faut parler maintenant de micro-services.

Le Devoxx France est, à l’image de son parent le Devoxx, une conférence à caractère technologique qui s’étale sur trois jours. Bien que axé sur l’écosystème Java, on y trouve aussi des tracks sur d’autres langages (comme Erlang ou Go), et sur d’autres technologies (programmation système sur Raspberry Pi ou sur Arduino). C’est la troisième année et le cru 2014 a été, à mes yeux, excellents. Ce que j’aime dans cette conférence est son caractère technique ; les tracks sont animés par les programmeurs pour les programmeurs. Foin donc de toute propagande sur tel outil, tel framework ou tel autre produit. Ici, l’accent est mis sur la présentation avant tout technique, le plus souvent illustrée par une démonstration qui, je l’avoue, me parle beaucoup plus qu’une suite ininterrompue de slides et de blabla.

L’amélioration de la structuration du code d’un programme, avec la distinction des considérations techniques de celles métier, est le Saint Graal que poursuivent sans fins les développeurs. A cette fin, de nombreuses techniques ont fait leur apparition dont nous pouvons citer les traits ou les annotations. A côté de ceux-ci, il existe une technique élégante et uniforme que sont les slots. Mais, que sont ces derniers et en quoi peuvent ils nous aider dans notre quête ?

Actuellement, la programmation relève de l’ingénierie qui consiste en la conceptualisation et en la réalisation d’ouvrage d’art fonctionnel et qui repose sur une méthodologie et une rigueur toute scientifique. Paradoxalement, dans l’industrie, l’activité d’ingénierie dans le développement logiciel manque de rigueur scientifique et sa méthodologie s’apparente souvent à de la planification et à de la gestion des activités.

Un logiciel n’est jamais terminé. Il ne fini pas d’évoluer pour satisfaire aussi bien de nouveaux besoins que de nouveaux enjeux technologiques. Un logiciel qui ne change pas, qui ne vit pas un refactoring continue, est un logiciel qui se meurt jusqu’à disparaître du marché parce que dépassé. Nous savons faire évoluer une application écrite selon la POO en jouant sur les propriétés de rétention, de composition, et d’extension des objets, ces entités logicielles qui représentent les concepts adressés par le programme. Mais qu’en est-il en programmation fonctionnel ? Comment peuvent être représentés les concepts ? Comment un code, écrit avec un langage fonctionnel, peut-il évoluer face aux changements ? Je vous propose de montrer ces aspects par un petit tour d’horizon d’un programme écrit en Haskell.

L’article de James Roper sur les performances de Scala et de Java via l’exemple du tri rapide m’a donnée l’idée, juste pour amusement, de réaliser le même benchmark mais avec 5 langages différents : C, Go, Java, Scala et Haskell ; on y retrouve donc ici à la fois des langages à orientation impérative et d’autres à orientation fonctionnelle. L’implémentation de l’algorithme est celui utilisé dans son article mais déclinée selon deux axes pour les langages de nature impérative : un axe plus classique dans lequel la récursivité est utilisée, et un autre bien moins traditionnel dans lequel la récursivité est, au contraire, évitée.

Mon ancien site personnel commençait à prendre de l’âge et n’était plus maintenu pour cause de manque de temps. Il en était de même de mon blog personnel. J’ai donc décidé de fusionner les deux en un...