DragonFly BSD est le dernier rejeton de la famille des Unix BSD libres. Il est issu du désaccord de Matthew Dillon sur les choix d’architecture SMP de FreeBSD 5 en vue de supprimer le Giant Lock. Créé en 2003 à partir de FreeBSD 4.8 pour initialement proposer une autre implémentation du multi-threading (multiflot en français), plus originale, il devient l’opportunité, pour l’équipe de DragonFly BSD, d’emprunter des directions différentes, voir innovantes, de celles des autres systèmes Unix.

L’amélioration de la structuration du code d’un programme, la séparation du métier et des concepts manipulés d’avec les aspects techniques, est le Saint Graal que poursuivent sans fin les développeurs. Dans ce but, 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.

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 fonctionnelle ? 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.

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 fonctionnelle ? 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.

La Programmation Orienté Objet (POO pour les intimes) est de nos jours la lingua franca de la programmation dite impérative. Pourtant, fort est de constater que celle couramment usitée est loin de l’approche définie par son auteur, Alan Kay, au point que l’on peut dire qu’il existe actuellement en fait deux approches orientées objet !

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.

James Roper a publié sur son blog un billet qui compare les performances de Java et de Scala via une réalisation du tri rapide d’une liste ou d’un tableau (quicksort). J’ai trouvé l’article intéressant pour deux raisons principales et qui sont liées à la nature particulière de ces deux langages.