Petit amusement programmatique avec Google Collections (1)

Google Collections est une bibliothèque fort sympathique et bien utile. Ce billet de Benjamin Wintenberg et celui-ci sur le Jayway Team Blog en présente plus en détail que le mien ce qu'offre cette nouvelle bibliothèque de Google .

Mon objectif est plus ici de m'amuser un peu avec Google Collections sur un petit cas concret. En l'occurrence ici le problème 1 du Projet Euler.
Il s'agit ici de déterminer la somme de tous les entiers naturels strictement inférieurs à 1000 qui sont multiples de 3 ou de 5.

La classe principale qui implémente une solution possible avec utilisation de l'API Google Collections :


La classe de tests (JUnit4) associée :


Regardons tout cela d'un peu plus près. La partie vraiment intéressante est la méthode solve.

Cette méthode comme son nom l'indique résout notre problème.
On crée d'abord une liste des nombres entiers de 0 à 999. Le "Lists.newArrayList();" vient de Google Collections. C'est plutôt explicite, la méthode statique newArrayList me retourne une instance de ArrayList (ici une ArrayList) que l'on se contente ensuite d'initialiser avec les nombres de 0 à 999.
Puis on crée une nouvelle liste à partir de la première liste. On utilise toujours Lists.newArrayList mais cette fois-ci avec en paramètre un Iterable. Ce paramètre Iterable correspondra concrètement à notre liste précédente filtrée pour ne garder que les multiples de 3 ou de 5. Pour se faire on utilise la méthode statique filter de la classe Iterables disponible dans Google Collection. Cette méthode filter prend en paramètre la liste à filtrer et un objet implémentant l'interface Predicat matérialisée ici par l'instanciation d'une classe anonyme implémentant une méthode apply. Cette méthode apply doit retourner un booléen et sera appliquée sur chaque élément de la liste passée en paramètre de la méthode filter : tous les éléments pour lesquels la méthode apply retournera false seront filtrés. Une fois que l'on a la liste filtrée, c'est fini. Il n'y a plus qu'à faire la somme des éléments pour trouver le résultat.

Voilà, rien de bien extraordinaire, c'est certain. L'intérêt est ici de voir un petit exemple d'utilisation de l'API Google Collections (qui - je vous rassure - propose bien d'autres choses) et les possibilités de pouvoir avoir une approche fonctionnelle en Java. D'ailleurs puisque l'on parle d'approche fonctionnelle en Java, un billet sur le blog de Xebia à propos de la sortie de Google Collections en finale 1.0 renvoyait vers 2 projets qui concernent une approche fonctionnelle en Java : Lambdaj et Functional Java. Avis aux amateurs !

Ruby 1.9

Ci-après une présentation de Ruby 1.9 par son créateur en personne... bon, cette vidéo date un peu (fin février 2008) mais je n'avais pas eu le temps de la regarder avant.

La présentation est relativement courte (une grosse demi-heure sans les questions) et va à l'essentiel. Ce que j'ai surtout retenu pour ma part, c'est que la version 1.8 est la dernière version stable assurant une compatilité ascendante avec les versions antérieures de Ruby alors que dans la 1.9, Yukihiro Mastumoto n'a pas hésité à casser ces compatibilités pour corriger ce qu'il considérait comme des erreurs de conception. Ce qui est important aussi avec la version 1.9 est le support d'Unicode (ce qui est un peu une des faiblesses de Ruby, si j'ai bien compris... mais bon je suis loin d'être un spécialiste en la matière) et une modification de la VM de Ruby qui semble apporter des améliorations de performance.

Le langage Factor

Ci-après, une présentation vidéo (un peu longue : un peu plus d'1h30) sur le langage Factor de Slava Pestov (qui est aussi le créateur de l'éditeur jEdit).

Factor est un langage de programmation dynamique concaténatif, dont les principales influences sont Joy, Forth, Lisp et Self.

Dans un langage concaténatif la composition de fonction est dénoté par juxtaposition contrairement à des langages applicatifs (traduction libre et probablement incorrecte de l'anglais "applicative language").

Dans un "applicative language" pour exprimer la composition de la fonction G de x par la fonction F vous serez amené à écrire quelque chose de la forme F(G(x)).
Dans un langage concaténatif comme Factor vous écrirez x G F.

Comme les autres langages concaténatifs et comme l'exemple ci-dessus le laisse entrapercevoir, Factor utilise une syntaxe postfixée, ce qui signifie que vous écrivez les arguments d'une fonction avant son nom. Ainsi pour afficher le fameux "hello world" vous écrirez en Factor la ligne suivante :

"Hello world" print

Pour ce qui concerne Factor, tout comme l'un de ces ancêtres - Forth - c'est un peu plus subtil : c'est un langage de pile ("stacked-based language"). Dans un langage de pile, vous n'appelez pas une fonction ou une procédure en lui passant des arguments, vous déposez des arguments sur la pile et la fonction (en Factor ou en Forth on parle de mot ("word") dépile le nombre d'arguments dont elle a besoin de cette pile. Ainsi dans l'exemple "Hello world" print, en fait le littéral "Hello world" est déposé sur la pile, le mot print le dépile et réalise un affichage.

La programmation avec Factor est donc particulièrement dépaysante si vous n'avez pas déjà tâter de Forth ou de la programmation sous les calculatrices scientifiques HP.

Si le coeur de Factor est clairement du Forth, il propose un système de macros proche de celui de Lisp. De plus, tout comme Smalltalk, Lisp ou Forth, c'est un véritable environnement de développement qui est mis à votre disposition, que chaque création de nouveau mot vient enrichir. Par contre, il n'y a pas à proprement parler d'IDE façon Eclipse ou Netbeans.

Néanmoins, si Factor est un langage original sur bien des points, son créateur a une visée pragmatique : le système est multiplateforme (Windows, Linux, Mac), il propose tout ce dont un développeur peut actuellement souhaiter (GUI, API réseau, API pour le développement Web, tests unitaires, expressions régulières, I/O, etc.). Bref, ce n'est pas juste un langage jouet dans lequel on ne fera que de petits programmes, mais bien un langage complet qui permet de tout faire.

Idéal pour les geeks qui ont envie d'apprendre un nouveau langage complètement différent et qui va bousculer leurs habitudes mais n'ont pas envie de se retrouver limité par les possibilités des bibliothèques. Si vous pensez comme Alan Perlis que "A language that doesn’t affect the way you think about programming is not worth knowing", alors il est clair que Factor vaut très certainement le temps que vous lui consacrerez.

Par contre pour apprendre Factor mieux vaut ne pas avoir de problème de compréhension avec l'anglais et si tutoriaux et autres documents pour apprendre le langage existe, on ne croule pas sous le nombre. Par contre l'existant, au moins pour démarrer est complet.



Quelques références :

• Le site de Factor : http://factorcode.org/
  
• La documentation de Factor en lignes (avec tutorial, cookbook et docs de rférence) : http://docs.factorcode.org/
• Le Wiki : http://concatenative.org/wiki/view/Factor/
• Billet de blog sur Factor (en anglais) : http://www.rfc1149.net/blog/2007/01/18/factor-a-stack-based-programming-language/
• Un tutorial bien fait en 2 parties sur Factor : http://elasticdog.com/2008/11/beginning-factor-introduction/

Google Data Eclipse Plugin

Une petite vidéo qui explique comment installer et utiliser le plugin Eclipse pour faciliter le développement de projet utilisant Google Data en Java :



Par contre, j'ai fait l'essai avec Eclipse 3.4 (Ganymede), et si l'installation du plugin ne pose pas de soucis, la création d'un projet avec ce dernier n'a pas abouti. Dommage... comme écrirait Isaac Asimov, cela sera certainement pour Noël sur Ganymède... désolé je n'ai pas pu m'empêcher... shame on me ;-)

Ci-après, une courte vidéo d'introduction à "Google Data" pour ceux qui ne connaissent pas :



En tous les cas, le plugin semble intéressant dès l'instant où l'on souhaite réaliser des développements autour de l'API Google Data.

Protocol Buffers

Google a mis a disposition récemment, un outil utilisé en interne : les "Protocol Buffers".

Ces "Protocol Buffers" sont la solution maison de Google "indépendante de la plateforme, indépendante du langage et extensible" pour sérialiser/désérialiser des données structurées.

Il faut d'abord définir un protocole - c'est-à-dire la manière dont les données sont structurées - dans un fichier avec l'extension .proto. Puis ce fichier .proto est compilé avec l'outil protoc pour générer un format binaire compact et le code source dans le langage adéquat (Java, Python et C++ pour l'instant) pour lire et écrire dans fichiers dans ce format de manière transparente.

Les données dans le fichier de protocole sont typées : sont disponibles des types simples génériques correspondant aux types simples des langages cibles. Et il est également possible de définir des nouveaux types dans le fichier de protocole.

Les "Protocol Buffers" semblent pour l'instant être utilisés principalement avec du RPC (Remote Procedure Call) ou pour stocker des données structurées simples.

En fait par rapport à XML, l'avantage des "Protocol Buffers" est d'être un format compact dont le traitement est rapide et facile (comparée à la manipulation d'arbres DOM en XML). Par contre, les "Protocol Buffers" ne sont pas conçus pour des données structurées complexes, dans lesquelles la structure est elle-même significative, comme par exemple une structure décrivant un document.

Si dans la petite vidéo qui suit, une comparaison des "Protocol Buffers" est effectuée avec XML et IDL/Corba (les "Protocol Buffers" sont un outil de sérialisation/desérialisation utilisable dans du RPC mais ne sont pas une solution de RPC), il n'y a pas de comparaison avec JSON et YAML. Ces 2 formats sont beaucoup plus compacts que XML mais le sont moins qu'un format binaire, mais reste par contre "lisible par un être humain".

Enfin, un aspect mis en avant et qui semble en effet un point important c'est l'extensibilité des données mises en oeuvre par les "Protocol Buffers". En effet, il semble possible de faire évoluer le format du protocole, en ajoutant des nouveaux champs par exemple, sans pour autant gêner les applications qui utiliseraient l'ancien format. Bien sûr, il faut voir jusqu'à quel point on peut faire évoluer un protocole sans que cela est d'impact sur l'existant.



Encore un outil de Google pour les développeurs même si ces derniers doivent d'abord déterminer si cela peut convenir à leur besoin. Cependant cela peut être une solution de sérialisation/déserialisation séduisante et dans tous les cas à étudier. Surtout qu'il va certainement rapidement y avoir des bindings ou des mises en oeuvre pour d'autres langages que Python, Java et C++.

Site des "Protocol Buffers" : http://code.google.com/apis/protocolbuffers/