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.
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.
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.
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++.
C'est un fait suffisamment rare pour mériter que l'on en parle : le prestigieux Prix Turing (certain le considère comme l'équivalent du Prix Nobel pour l'informatique) vient d'être co-décerné à Edmund M. Clarke (de l'université Carnegie Mellon), E. Allen Emerson (de l'université du Texas) , et Joseph Sifakis (Université de Grenoble, laboratoire Verimag) pour leur travaux sur le "model checking".
Je vous invite à lire ces 2 articles pour avoir plus d'information sur le sujet et des liens sur cette thématique :
J'en profite pour vous recommander le livre "ALAN TURING - L'homme qui a croqué la pomme" de Laurent Lemire chez Hachette si vous voulez en savoir plus sur Alan Turing le mathématicien reconnu comme un des pères fondateurs de l'informatique et qui a donné son nom à ce prix.
Adobe vient de sortir la version 1.0 de AIR : avec ce nouvel environnement il est notamment possible de lancer des applications web riches ("Rich Internet Applications" ce qui donne l'acronyme RIA) directement sur le bureau de l'ordinateur et en mode "déconnecté" , i.e. qu'il n' y a plus besoin d'être connecté en permanence à Internet.
AIR repose sur un ensemble de technologies et d'outils : bien sûr Flash, Flex et les technologies liées à AJAX (Javascript, XML, JSON, CSS, etc.) mais également sur la base de données open source SQLite pour la stockage et la synchronisation les données avant et après les déconnexions.
La bataille du RIA s'annonce disputée : il y a les technologies concurrentes de Google (Google Gears), de Mozilla (PRISM) et bien sûr l'omniprésent Microsoft (Silverlight). Dans une moindre mesure on peut dire que dans la concurrence il y a Sun avec JavaFX et Java mais certains estiment déjà que ce n'est plus un challenger crédible sur le créneau du RIA (voir l'article "Swing is drowning" de Dion Almaer).
Ce "port" de RoR est notamment l'oeuvre de Steve Yegge qui travaille chez Google : ne pouvant utiliser Rails car basé sur Ruby qui ne fait pas partie des langages utilisables en production chez Google, il a décidé d'effectuer le portage de ce framework sous Rhino, la version de Javascript pour la JVM. Il a publié un intéressant billet sur dans lequel il explique pourquoi Javascript et Rhino, pourquoi ce projet, etc.
Rhino On Rails n'est pas encore disponible en OpenSource. Il est intéressant de noter que RnR n'est pas le seul framework basé essentiellement sur Javascript et/ou Rhino. Il est ainsi possible de citer Helma ou TrimPath (Junction) .
Un point un peu ironique (mais qui a son intérêt techniquement et pour les amoureux des technos Google) est que RnR devrait s'intégrer avec Goggle Web Toolkit ...
Une affaire à suivre dans tous les cas.
Et une chose est sûre : on n'est pas près de voir le nombre de frameworks web décroître prochainement...
J'ai découvert Xebia un peu par hasard en recherchant des vidéos sur J2EE sur YouTube : je suis tombé sur les présentations vidéos qu'ils font de leur entreprise.
En jettant un oeil à leur site institutionnel et à leur blog, je suis tombé sur le Xebia Poker Tour qui semble être une initiative ludique et intéressante : vous répondez à des questions sur Java, XML, J2EE, les méthodes agiles, etc. ce qui vous permet de recolter de l'argent fictif.
Les 50 plus riches pourront participer à une partie de poker et peut-être gagner un voyage à JavaOne ou Javapolis. Toutes les explications sur ce billet.
L'initiative est à la fois surprenante, rare et ludique, alors je vous invite à aller y faire un tour si vous êtes un expert Java/J2EE et que le poker vous branche !
Si cela fait quelques temps que vous entendez parler régulièrement du langage Scala et que vous souhaitez quelques points d'entrée pour un savoir plus, voici quelques pistes.
Scala est un langage de programmation multi-paradigme conçu à l'EPFL pour exprimer les modèles de programmation courants dans une forme concise et élégante. Il intègre les paradigmes de programmation orientée objet et de programmation fonctionnelle, avec un typage statique.
J'ai inséré la vidéo juste après dans ce billet. Cependant cette dernière dure plus d'une heure. Cela peut-être sympa de la récupérer avec Miro et de la regarder tranquillement. Cela reprend pas mal de points évoqués dans la "présentation synthétique du langage" que l'on trouve sur le site officiel : certains passages sont assez techniques et difficiles à suivre quand on n'a pas de solides bases en théorie des langages.
Encore un passionné de développement logiciel et de programmation qui se sent obligé de faire un blog.
Le contenu de ce blog reflète uniquement mes opinions personnelles et en aucun cas les opinions d'un de mes employeurs précédents ou de mon employeur actuel.
Articles
