Ma petite entreprise

Ce n'est pas vraiment dans mon habitude de faire le relais de nouvelles de ce genre, mais je voulais juste partager mes réflexions sur le fait que Flex devienne Open-Source.

Le web a vraiment beaucoup changé dans les deux dernières années, et on a vu une floraison de projets open-source, reflétant un vif intérêt pour les applications client "riches" (applications web en HTML ou en Flash). Tout personne ayant tenté des choses un peu avancées avec HTML auront vu les limitations de HTML/JavaScript en ce qui concerne l'animation, ou même des interfaces graphiques avec des représentation non conventionnelles (listes, arbres, etc), et l'intérêt que peu avoir Flash pour des visualisations interactives.

Il y a clairement une convergence desktop/internet qui se fait de plus en plus nette, et j'ai l'impression qu'Adobe a décidé de d'attaquer ce problème de manière frontale en propulsant sa plateforme Apollo et les technologies connexes (Flash, ActionScript 3 et donc Flex) dans la sphère des développeurs. Jusqu'à présent, le fait que la plateforme Flash soit propriétaire, et qu'elle a très mauvaise réputation auprès des développeurs Web (HTML/CSS, amis du W3C), a sans doute limité son utilisation dans bon nombre de sites, mais il faut avouer qu'en pratique, il y a de nombreux cas oû HTML/JavaScript ne tiennent tout simplement pas le coup (si vous avez de nombreux éléments graphiques a afficher, si vous voulez de l'animation, etc).

Est-ce que le poisson va mordre à l'hameçon ? C'est difficile à dire pour l'instant, mais avec un changement de stratégie (une ouverture sur la communauté des développeurs, laboratoire à ciel ouvert "Adobe Labs", open source) appuyé par une machine marketing/buzz plutôt efficace, on peut anticiper quelques évolutions cette année. Je ne serais pas surpris si dans quelques temps Adobe allait essayer de faire passer quelques petites choses relatives a Flash dans le W3C.

Personnellement, j'espère surtout voir plus de synergies entre les applications de bureau et les applications web, notamment en ce qui concerne le partage de données (ex: agenda, list de contacts, etc). Je trouve qu'il y a relativement peu d'intérêt à avoir (par exemple) un Photoshop pour le web, qui soit plus lent et ait moins de fonctionnalités que le Photoshop classique...

Update: Fred Cavazza donne une bonne explication aussi de Flex par rapport a Apollo.

Hier je lisais une présentation concernant YesNo, un langage de programmation qui m'a paru intéressant dans sa conception.

L'idée de base est tirée d'un théorème de Gödel (je ne l'ai pas étudié), qui dit que toute logique "substancielle" (alors là...) est soit "cohérente" ('consistent') soit complète ('complete'), mais pas les deux. Comme il y a un parallèle important entre la logique et les langages de programmation, l'approche est que tout concepteur de langage a le choix entre avoir une sémantique "cohérente" ou alors d'offrir la possibilité aux programmes de ne pas s'arrêter (ceci semble être l'interprétation du fait d'être complet).

Si tout ceci semble vague et incompréhensible (ce qui devrait être le cas ;), voici ce que j'en retire personnellement : le concept de base de YesNo est que chaque fonction écrit doit être capable de retourner un résultat "approximatif" (soit l'ensemble des valeurs qui peuvent être produites, soit éventuellement des valeurs "à la louche"), avant de retourner le résultat précis.

L'auteur (Mike Burrel) donne d'ailleurs un exemple assez clair. Plutôt que d'écrire un programme de la manière suivante:

fonction f:
 (un tres long calcul du résultat)
 retourne le résultat

on écrirait plutôt:

fonction f:
  résultat := (ensemble des valeurs possibles)
  (un tres long calcul du résultat)
  résultat := (la valeur retournée par le très long calcul)
  retourne résultat

En gros, on permet de renvoyer un résultat approximatif tout de suite, en attendant d'avoir le résultat complet.

Dans cette perspective, le nom 'YesNo' prend un peu plus de dimension: une fonction pourrait retourner vrai, faux (l'ensemble des valeurs) avant de retourner vrai (la valeur finale).

On peut se demander quel est l'intérêt d'une telle approche. Dans sa présentation, Mike Burrel mentionne ParaLog, un langage de programmation du type Prolog, qui permet de faire des programmes proches de la "logique floue". En logique floue, plutôt que de considérer que les choses sont soit vraies, soit fausses, on peut considérer qu'elles sont 60% vraies et 40% fausses. Bref, de manière générale, ceci a des applications très importantes en intelligence artificielles, lorsque des données sont incomplètes ou simplement floues.

Au delà de la capacité à traiter des données incomplètes, on pourrait penser à utiliser cette approche pour générer automatiquement des suites de test : si l'on stipule un ensemble de valeurs "probables", on a 'de-facto' un ensemble de données proche des données réelles de l'application.

Pour ceux qui veulent en savoir plus, il y a le fil de discussion sur LtU ici. En regardant de plus près la documentation de YesNo, je suis sûr que Damien appréciera la syntaxe 100% Smalltalk

Je suis un peu confus de me rendre compte a quel point j'ai négligé mon blog ces derniers temps... milles excuses donc, et je vais faire en sorte de retrouver mon rythme de croisière et de faire un peu plus part de mes recherches relatives a l'interface et aux langages de programmation.

En tout cas, je viens de voir ce projet de Google Summer of Code, qui me dit que nous allons voir cette année des choses bien intéressantes. C'est un projet qui a pour objectif d'implanter un front-end Python pour HLVM, qui est une surcouche à LLVM permettant de créer facilement des langages.

En gros, il serait possible d'avoir un interpréteur Python (basique) produisant du code natif très optimisé (grâce à LLVM), mais aussi d'avoir un exemple concret de comment implanter un langage dynamique avec HLVM/LLVM.

Pour ceux qui l'avait manqué, PyPy (Python ré-écrit en Python, avec une approche très moderne) est sorti récemment en 1.0 (mais le projet n'est pas encore au point), et dispose également d'un back-end LLVM.

Pourquoi je parle de ça ? Eh bien parce que l'on commence à voir une convergence entre langages dynamiques (comme Python) et langages compilés/optimisés. Ceci signifie que la barrière de performance entre les langages compilés (C, Cpp, Java) et les langages dynamiques est en train de se réduire, et que l'on pourra espérer bientôt faire une application Python qui sera aussi rapide qu'une application Java. Un projet intéressant dans ce contexte est ShedSkin qui traduit du Python en C++, atteignant des performances impressionantes.