Discussion :

[Arsene Newman]

IMVU revient sur la supplantation partielle du langage PHP par Haskell
Une année après, l’équipe semble satisfaite de ce choix

Depuis 2013, IMVU le célèbre chat/jeu 3D qui vous plonge dans un monde virtuel a entamé un processus pour supplanter partiellement le langage de programmation utilisé pour coder le backend de son application (le langage PHP), par un autre plus adapté en terme de performance et de passage à l’échelle, vu le succès d’IMVU. C’est ainsi que les développeurs ont étudié longuement la question pour conclure à l’utilisation du langage fonctionnel Haskell.

Une année après, l’équipe de développement revient sur ce passage du langage PHP vers Haskell en livrant des détails basés sur cette expérience et sur certains critères comme : le passage à l’échelle, la fiabilité, l’apprentissage, les tests, le déploiement et certains enseignements conclus suite à tout cela.

Passage à l’échelle :
La première expérience au sein de l’équipe d’IMVU fut le remplacement d’un service non critique brassant une quantité importante de données, par une implémentation en Haskell. Le résultat fut alors assez éloquent. En effet sans aucune optimisation du service, l’implémentation Haskell a été en mesure de traiter 20 fois plus de requêtes, tout en tournant sur des serveurs moins performants (serveurs de secours en voie d’être retirés) que ceux de l’implémentation PHP.

Fiabilité :
Par la suite et dans la continuité de la première expérience, l’équipe d’IMVU a décidé de faire tourner l’implémentation Haskell sans aucune intervention, jusqu’au plantage du service, résultat des courses : aucune intervention pendant plusieurs mois.

Apprentissage :
L’expérience suivante fut le développement d’un nouveau projet avec deux équipes, une pour la partie frontend en PHP et la seconde pour la partie backend en Haskell. Ainsi au cours des premiers jours, ce fut laborieux pour cette dernière équipe de développer une implémentation équivalente à tant d’autres réalisées par le passé en PHP. Toutefois, après avoir jeté les bases, le développement était devenu plus facile et l’unique facteur limitant la livraison du projet fut la partie frontend.

Aujourd’hui, pour les développeurs d’IMVU, être productif avec le langage Haskell ne diffère pas vraiment d’être productif en PHP. De plus, les développeurs habitués aux concepts de la programmation fonctionnelle ont un certain avantage, ce qui leur permet une prise en main rapide en quelques jours seulement.

Tests :
Une des conséquences de l’utilisation d’un langage fonctionnel comme Haskell est la suppression des effets de bord, qui nuisent tant aux applications développées. De ce fait, au sein de l’éditeur d’IMVU, les tests unitaires et le Test Driven Development (TDD) ont été facilités avec Haskell. D'ailleurs, les développeurs ont conclu que « Haskell est meilleur avec le TDD, mais aussi le TDD est meilleur avec Haskell. Cela ne prend que quelques tests pour atteindre le même degré de fiabilité avec Haskell. La vérification statique prend soin de vérifier l’existence d’erreur, ce qui doit être implémenté manuellement (ou oublié) en PHP. L’outil QuickCheck est d’une grande aide pour les développeurs ».

Au final, le recours à Haskell a permis aux développeurs de supprimer des classes dédiées aux tests et d’écrire moins de code. De plus, ce langage se veut plus rigoureux, ce qui ne laisse pas de place aux échecs intermittents des tests.

Déploiement :
En termes de déploiement, les développeurs n’ont pas rencontré de difficultés. En outre, il a été nécessaire d’utiliser un client Memcached pour le code Haskell. Toutefois, au lieu d’utiliser un client écrit en C, ils ont développé leur propre client en Haskell, avec quelques effets secondaires insoupçonnés. Quant à la refactorisation, l’équipe d’IMVU estime que cette tâche est devenue un jeu d’enfant.

Quelques enseignements tirés :
L’un des plus gros soucis des développeurs d’IMVU est le manque de ressources, de documentations vu que ce langage est rarement utilisé dans le monde professionnel, de ce fait certains bugs sont plus difficiles à résoudre, ce qui en fait l’un des inconvénients majeurs du langage.

L’autre inquiétude était le recrutement d’un développeur Haskell. Néanmoins, cela se révéla un faux débat, car l’utilisation de ce langage a agi à double sens. Les développeurs en Haskell ne sont pas nombreux, mais lorsqu’un développeur maitrise le langage, celui-ci souhaite le plus souvent développer avec.

Mis à part cela, l’équipe d’IMVU semble être satisfaite de ce choix, qui offre de meilleures performances, améliore la productivité et facilite la refactorisation, ce qui permet de mesurer en toute objectivité le changement apporté.

Source : Blog d’IMVU
Et vous ?

Qu’en pensez-vous ?

Est-ce que vous envisagez de remplacer certains codes par du code écrit en Haskell ? Pourquoi ?

[Pierre Louis Chevalier]

Haskell c'est très bien pour écrire du code obfusqué impossible à lire par d'autres, si tant est que tu puisses trouver un jour un développeur Haskell
Donc parfait pour pas se faire virer.

Sinon à part ça Haskell à de très bonnes perfs c'est pas négligeable quand on doit supporter des milliers de connexions.

[Trademark]

Haskell c'est très bien pour écrire du code obfusqué impossible à lire par d'autres, si tant est que tu puisses trouver un jour un développeur Haskell
Donc parfait pour pas se faire virer.

Faut pas avoir essayé longtemps de programmer en Haskell pour en tirer des conclusions pareils. La programmation fonctionnelle a beaucoup à offrir et les langages plus utilisés comme Java ou C++ ne cesse d'ajouter des traits fonctionnels, suffit de voir l'ajout des lambda.

C'est impossible à lire par la plupart des autres développeurs car ceux-ci n'ont jamais eu l'opportunité (ou au choix, l'ouverture d'esprit) d'apprendre un langage fonctionnel.

En tout cas, c'est bien d'avoir des retours sur de tels expériences, nombreux ceux qui n'aurait même pas tenté ! Peut-être que d'autres embrayeront...

[tomlev]

Haskell c'est très bien pour écrire du code obfusqué impossible à lire par d'autres

J'étais un peu de ton avis avant de regarder Haskell de plus près, mais en fait c'est juste la syntaxe qui est un peu effrayante au premier abord... En suivant un bon tutoriel comme celui-ci, c'est finalement tout à fait abordable. Je dois dire que ce langage m'a pas mal impressionné, même si j'ai encore un peu de mal à imaginer de développer une application complète avec.

[yannickt]

Je suis d'accord avec Pierre Louis. Je trouve que les langages qui utilisent beaucoup les caractères symboliques à la place de mots clefs, sont quand même plus indigeste à lire. C'est un jugement juste sur la syntaxe. Ça ne retire en rien toutes les autres qualités.
Après, je pense qu'effectivement, on va lentement glisser vers les langages fonctionnels, par dose homéopathique...

[tomlev]

Après, je pense qu'effectivement, on va lentement glisser vers les langages fonctionnels, par dose homéopathique...

En fait les concepts de programmation fonctionnelle ont déjà commencé à s'immiscer dans des langages OO/impératifs, par exemple en C# et en Java (depuis Java 8). Pour moi en C# les avantages sont évidents : les parties du code écrites en style fonctionnel ont généralement beaucoup moins de bugs que les autres...

[DonQuiche]

Je suis d'accord avec Pierre Louis. Je trouve que les langages qui utilisent beaucoup les caractères symboliques à la place de mots clefs, sont quand même plus indigeste à lire. C'est un jugement juste sur la syntaxe. Ça ne retire en rien toutes les autres qualités.

Pour moi les mots-clés facilitent l'apprentissage mais deviennent pénibles par la suite s'il faut souvent les répéter. Pour un langage rarement utilisé (shell, fichier de config, etc) je privilégie de loin les mots-clés. Mais au quotidien, vive la concision, il y a d'autres moyens de faciliter la lecture (indentation, idiosyncrasies comme le | facilement repérable en début de ligne, etc).

[Gugelhupf]

A vrai dire je ne comprend pas trop le rapprochement que vous faite entre les lambdas et le paradigme fonctionnel.
Un lambda peut contenir des instructions, on reste sur de l'impératif (ou procédurale si vous voulez).
Il y a plus de paradigme fonctionnel dans une requête de sélection SQL, qu'en Java ou C#...

Aussi, je pense que rare sont les personnes qui font du web sans jamais avoir fait de PHP, donc normal que les gens passent plus souvent de PHP vers autres chose, que d'autre chose vers du PHP.

[DonQuiche]

A vrai dire je ne comprend pas trop le rapprochement que vous faite entre les lambdas et le paradigme fonctionnel.

Si tu prends linq par exemple, ça te rappellera fichtrement les compréhensions : myList.Where(x => x.Expiration > DateTime.Now).OrderBy(x => x.Value).GroupBy(x => x.Category)
Et si en plus tu sais que ceci est évalué de façon paresseuse... Certes ce n'est pas exactement la même chose mais l'usage est très analogue.

Autre exemple, le fait qu'un lambda puisse être passé en C# non pas comme un simple délégué (une référence invocable vers une fonction) mais comme un arbre d'expressions qui peut être transformé et compilé. Autrement dit je peux écrire une fonction qui prend en argument un lambda et renvoie un autre lambda dont l'arbre d'expressions est dérivé de celui reçu.

[tomlev]

A vrai dire je ne comprend pas trop le rapprochement que vous faite entre les lambdas et le paradigme fonctionnel.
Un lambda peut contenir des instructions, on reste sur de l'impératif (ou procédurale si vous voulez).

Bah c'est sûr que si tu mets du code impératif dans une lambda, c'est plus très fonctionnel, mais dans les usages les plus fréquents (Linq par exemple), on s'en sert pour exprimer un prédicat, une projection, un critère de tri, etc. Les méthodes Where, Select, Aggregate, etc. de Linq correspondent exactement aux filter, map, reduce (ou fold), etc. des "vrais" langages fonctionnels (y compris la lazy evaluation, comme l'a mentionné DonQuiche).

[Luckyluke34]

A vrai dire je ne comprend pas trop le rapprochement que vous faite entre les lambdas et le paradigme fonctionnel.

Fonctionnel veut dire traiter les fonctions comme des "citoyens de première classe". Il n'y a pas les données d'une part et les fonctions de l'autre, les fonctions peuvent être manipulées comme des données, donc passées en paramètre à d'autres fonctions, retournées, combinées à l'aide d'opérateurs, etc.

Les expressions lambda sont une des manières les plus pratiques (et LA manière en paradigme fonctionnel) d'exprimer des fonctions de manière concise pour les manipuler ainsi un peu partout. Leur notation est tirée du lambda calcul formulé par Alonzo Church au début du siècle dernier. Il est considéré comme un des grands inspirateurs de la programmation fonctionnelle.

=> les lambdas sont un des traits caractéristiques de la programmation fonctionnelle sans en être le seul. Le fait que des langages orienté objet (C# puis Java) les aient reprises de manière privilégiée parmi les pratiques fonctionnelles ne change rien à leur origine.

Un lambda peut contenir des instructions, on reste sur de l'impératif (ou procédurale si vous voulez).

Possible, mais ce n'est pas recommandé car on mélange les styles fonctionnel et impératif. Tant qu'à utiliser une approche issue du fonctionnel, autant le faire dans un style à peu près "idiomatique".

[Sarwen]

Haskell c'est très bien pour écrire du code obfusqué impossible à lire par d'autres

C'est bien souvent le contraire. Quand j'ai débuté en Haskell, j'avais déjà quelques années d'O'Caml dans les pattes et je pensais connaitre ce qu'était la programmation fonctionnelle. J'y ai découvert ce qu'était un foncteur, une arrow, une monade, un combinateur, les types d'ordre supérieur, le polymorphisme de rang n, ... Toutes ces choses qui rendent Haskell extrêmement concis mais mais malheureusement très différent des autres langages (mis à part Scala bien entendu). Haskell est contraignant, c'est certain, mais le jeu en vaut la chandelle. Regardez des bibliothèques comme HXT ou Parsec pour vous en convaincre. Elles permettent d'écrire en quelques lignes ce qui prendrait des dizaines voir des centaines dans d'autres langages.

Ce n'est pas un langage difficile, il repose juste sur des principes différents de ce à quoi nous sommes habitués (non-strictness, pureté, ...). On ne peut pas se contenter de reproduire en Haskell les habitudes prises ailleurs, mais c'est de toute façon généralement mauvais de prendre un langage pour un autre. Il faut juste prendre le temps de s'habituer à de nouvelles pratiques et ne pas avoir peur d'un petit peu d'abstraction.

[DonQuiche]

Elles permettent d'écrire en quelques lignes ce qui prendrait des dizaines voir des centaines dans d'autres langages.

Je suis assez d'accord avec ton intervention mais je tiens à nuancer cette partie : un langage comme Haskell brille particulièrement sur les collections, énumérations, etc. Or les langages impératifs sont tous en train d'intégrer ces capacités, ça a d'abord été le cas de C# il y a quelques années, puis de C++ l'année dernière dans une moindre mesure, et maintenant Java il y a quelques jours. Sorti de ces traitements, la concision d'Haskell devient beaucoup plus anecdotique dans la mesure où "| [] = 0" n'est pas un gain démesuré par rapport à "if (x.IsEmpty) return 0"

Je ne dis pas qu'en-dehors de ça il n'y a pas de cas où Haskell est vraiment plus concis, je dis simplement que ces cas sont relativement anecdotiques au quotidien.

[SurferIX]

Comparer Haslkell et Php...

Tant que tu pourras faire des "echo $xx" et qu'il n'y aura jamais de problème à part un "notice" qu'on peut cacher en Php,
tant que tu pourras faire des "include $xx" et que si le fichier n'existe pas il n'y aura jamais de problème à part un "notice" qu'on peut cacher en Php,
tant que tu pourras faire des "include $xx" dans des fonctions elles-même incluses dans un fichier qui est inclus dans une fonction "private" (du vécu) qu'il n'y aura jamais de problème,
bref : tant que tu pourras faire facilement de la grosse merde en Php, peu importe la qualité de ton équipe, une seule personne pourra tout massacrer et facilement, ...

pour résumer : le Php sera toujours problématique car il est beaucoup trop permissif et par là même ça ne sert à rien de le comparer à ci ou ça.