Intercooler.js est une énième, mais nouvelle bibliothèque JavaScript pour les sites web orientés client lourd.

Elle propose un mécanisme déclaratif assez intéressant : le comportement de l'interface est codé dans les attributs de balises HTML standard.
Elle simplifie la vie du développeur en évitant de devoir intégrer des évènements sur des sélecteurs JQuery (ou ses concurrents) : celui-ci a le choix de provoquer un appel AJAX ou un appel interne sur une fonction javascript, de manière déclarative dans le code HTML.

Intercooler est basé sur le concept de Partial View Controller. Dans cette approche, le serveur renvoi des fragments de HTML à intégrer dans l'interface.

Les langages de programmations, de quelques paradigmes qu'ils soient (bien qu'un peu moins pour le paradigme logique), sont basés sur le concept de liste d'instructions exécutées à la suite par la machine. La machine exécutant ce code est une machine à état, mais le programme n'est pas formellement pensé comme tel.

Les machines à état semblent pourtant un bon outil pour la programmation des logiciels que nous avons l'habitude de développer : facile à dessiner sur papier, permettant un découpage clair du fonctionnement de l'application.
Sans compter qu'une machine à état se patche plus facilement qu'un code classique où l'effet spaghetti peut vite impliquer des effets indésirables.
Les designers de Qt l'ont bien compris en permettant de définir des machines à état pour décrire le comportement du contrôleur.

C'est pourquoi certains se sont demandés si la programmation en machine à état ne devrait pas être plus pratiquée et aimée des programmeurs. C'est, par exemple, ce que se demande Willem van Bergen, carrément enthousiaste.
Celui-ci pense que c'est le stockage de l'historique qui est essentiel.

Plus circonspect, Alan Skorkin étudie la problématique de reprise de code, afin de comparer les approches, pour conclure que si les machines à états ne sont pas la panacée, elles sont très intéressantes si on conçoit le code avec.

Un très intéressant débat est né de cette polémique sur Hacker News.

NantesFP organise le mardi 27 novembre 2012 à 19h30 une conférence sur le logiciel assistant de preuve Coq.

La présentation aura lieu à la Cantine, impasse Juton à Nantes et abordera pour cette première partie le cadre mathématique de Coq.
Cette présentation, gracieusement proposée et réalisée par Maxime Folschette, sera la première d'une série couvrant les principaux aspects de Coq et de son langage Gallina.

Les prochaines séances s'orienteront petit à petit vers un mode plus « travaux pratiques » afin que chaque participant puisse s'approprier l'outil.

Le nombre de places étant limité, une inscription est nécessaire.

Les langages fonctionnels, longtemps restés très académiques, se font leur place dans l'industrie grâce à leurs nombreux avantages, en particulier vis-à-vis des systèmes distribués. Des langages tels que Scala ou Erlang concourent à démocratiser ce paradigme.

Lors de cette soirée, Clément Delafargue nous proposera une présentation du célèbre Why Functional Programming Matters. Ce manifeste expose les avantages de la programmation fonctionnelle en expliquant pourquoi ceux-ci peuvent nous permettre d'atteindre le saint graal du développeur : la modularité ultime.

En particulier, il montre comment les fonctions d'ordre supérieur et l'évaluation paresseuse permettent d'écrire du code plus générique et plus réutilisable. Les exemples fournis dans ce manifeste constituent une bonne introduction aux langages fonctionnels et nous étudierons l'implémentation des exemples proposés en Haskell, en OCaml et en Scala.

Le groupe NantesFP est un groupe assez divers, tant par le niveau que de par le langage de prédilection. La rencontre aura lieu à la Cantine de Nantes, impasse Juton, le 15 mars à 19h30.

Venez nombreux !

Java est un des langages de programmation les plus auréolés de succès de ces quatre dernières décennies. Une grande partie des offres de postes de développeurs en France concerne Java.

D'après le « TIOBE Programming Community Index » Java est toujours leader avec 18,58 % des parts de marché en juin 2011. Il était bien plus haut en 2000, avoisinant les 30 %.

Mais comment Java en est arrivé là ? Cet article effectue un retour sur la période 1991–2000.

Attempto Controlled English (ACE) est un sous ensemble de l'anglais conçu pour être non ambigüe. Il est constitué d'un petit ensemble de règles syntaxiques, sémantique et d'interprétation. Il est aussi conçu pour être un langage logique du premier ordre. Constitué d'un ensemble d'outils permettant d'exprimer et de manipuler du texte en anglais, l'outil principal Attempto Parser Engine (APE) est capable de fournir une représentation logique d'une phrase en anglais ACE.

Ecrit en Swi-Prolog, APE est capable rendre un ensemble de phrases sous forme logique en utilisant la représentation DRS (Discourse representation structures). Cette représentation est disponible sous différents formats (Prolog, XML, OWL, etc.) et APE peut être utilisé en tant que webservice, serveur web ou en simple ligne de commande.

Quelques outils gravitent autour du projet. Citons ACE editor qui permet d'écrire des phrases compatible ACE, RACE (ACE reasoner) qui permet de réaliser des déductions sur du texte ACE, ACEWiki un wiki sémantique.

ACE est un projet de l'université de Zurich mené depuis 1996 et est distribué en LGPL. ACE a été choisi comme anglais controllé par le projet de l'Union Européenne "EU Network of Excellence REWERSE (Reasoning on the Web with Rules and Semantics)"

Les processeurs graphiques sont d'une puissance inégalée par rapport aux cœurs de calcul disponibles sur les processeurs x86. Malgré tout, leur coût d'accès mémoire reste trop important. Plus encore, les processeurs graphiques sont très spécialisés dans le calcul pur rendant difficile leur programmation.

Pour un développeur programmant autre chose qu'un jeu, il est difficile d'évaluer si transférer les calculs sur le processeur graphique est intéressant, d'autant plus si la complexité des calculs peut être variable.

Quelques voix s'élèvent pour pointer ces problèmes qui peuvent laisser penser que le traitement graphique hors du processeur n'a plus que quelques années devant lui.

La victime de cet état de fait pourrait bien être NVidia.

L'année écoulée a vu poindre les prémices d'une guerre technologique et commerciale qui va prendre une importance grandissante dans les années à venir : la guerre entre les GPU et les CPU.
De simples afficheurs de triangles texturés en 1995, les cartes graphiques munies de GPU sont devenues des sortes d'énormes DSP bientôt composées d'un milliard de transistors, délivrant des performances approchant bientôt le téraFLOPS. La répartition des tâches semblait jusqu'ici bien déterminée entre le CPU, dévolu aux tâches de gestion et de décision, et le GPU se chargeant du calcul brut, en particulier graphique. Mais les quelques acteurs du marché ont récemment amorcé des mouvements les préparant à dépasser leurs frontières traditionnelles.

CodeWorker est un outil d'automatisation du développement, sous GNU LGPL. Cet outil se propose d'être un générateur de code universel, capable non seulement de générer du code, mais de générer celui-ci en l'injectant dans du code existant.

Cordeworker se matérialise comme un interpréteur d'un langage de script intégrant la possibilité de définir une grammaire BNF du langage à parser ou du source cible dans lequel on veut injecter du code. La génération se décrit à l'aide de modèles de génération (template-based scripts), décrivant le remplissage d'un graphe de parsing pendant l'analyse. Ce graphe pourra ensuite être manipulé.

Sa force réside dans sa souplesse totale : on peut lui faire lire un source en C++ ainsi que des information en XML, pour injecter du code dans du Java. Partant de là, et de grammaire BNF decrivant XML, Java, etc... on peut imaginer toutes sortes d'outils. Notons le mode JEdit prenant en charge la coloration syntaxique pour CodeWorker.

CodeWorker est donc un outil puissant, stable, qui a sûrement besoin de contributions comme des scripts pour analyser toutes sortes de langages et ainsi permettre de nombreuses manipulations !

Après un an de travail intensif, Benoit Sonntag nous livre une version stable et intégralement réécrite de Lisaac, un langage ayant une productivité proche des langages de script avec les performances du C. Lisaac est un langage objet à prototype avec une bibliothèque et un compilateur sous licence GPLv3.

Les benchs effectués sur des traductions fidèles de programmes C donnent des résultats différents en fonction de l'architecture cible : on obtient, grossièrement, un code de 20 % plus rapide à 30 % plus lent.

La spécification 0.2 apporte de nombreuses nouveautés au langage : un système de types amélioré, une syntaxe où la casse permet de séparer clairement mot-clé, prototype/type et variables, un système de contrats amélioré et gérant l'héritage, une gestion automatique des micro/macro objets, l'héritage alimentaire, une gestion des blocks très puissante. L'innovation la plus visible est l'apparition des résultats multiples : une méthode peut retourner plusieurs valeurs, de même qu'elle peut en accepter plusieurs en argument.

Le compilateur est en outre capable de produire des statistiques sur les appels potentiels sur NULL et de prédire l'endroit où ils risquent d'arriver. Les temps d'exécution, la consommation mémoire et surtout la stabilité du compilateur ont été considérablement améliorés.

L'intérêt majeur pour le libre est la disponibilité du seul compilateur objet au monde à réaliser une analyse de flot profonde du code. Cette technique de compilation, qui analyse et prédit les chemins potentiellement empruntés par le code à l'exécution permet une optimisation très poussée de celui-ci afin se rapprocher des performances du C (voir les benchs).

Dominique Colnet (auteur de SmartEiffel) et Benoit Sonntag ont quasiment terminé un traducteur Eiffel vers Lisaac. Ce traducteur permettra à Lisaac de bénéficier d'une bibliothèque Eiffel rigoureusement traduite de l'originale, et donc de disposer d'une bibliothèque testée et sûre. Cette bibliothèque devra ensuite être retravaillée afin d'utiliser au mieux la puissance d'un langage objet à prototype.

La version 0.3 de Lisaac, implémentera la gestion de la concurrence avec le modèle COP, qui automatisera celle-ci. La version 0.4 apportera la stabilisation syntaxique, sémantique et fonctionnelle du langage, ce qui permettra le lancement du projet Isaac OS, le système d'exploitation objet à prototype. Le projet Isaac sera ainsi réellement lancé.

Espérons que la communauté répondra présent à ce formidable défi.

NdM : l'"héritage alimentaire" est appelé comme cela car c'est un héritage qui possède toutes les propriétés de l'héritage classique, mais "secrètement". C'est à dire que vu de l'extérieur de l'objet qui utilise ledit héritage alimentaire, on ne sait pas qu'il hérite.

FreeDesktop.org a annoncé le 9 novembre la sortie de D-Bus 1.0 après quelques années de travail.

Ce système est la tentative de FreeDesktop.org de standardiser un système d'échange d'informations et de données entre applications des environnements de bureau, ou entre applications et le noyau. Chaque application peut ainsi demander ou proposer des services aux autres, ainsi que demander à être informée de l'arrivée ou de la déconnexion à chaud de nouveaux périphériques. Des bus de données munis d'une sémantique sont créés.

Freedesktop.org est une initiative des développeurs de GNOME, KDE, Enlightenment, GStreamer, Xgl/AIGLX ou encore x.org afin de créer des standards communs dans un contexte de développement de code et de spécifications ouvertes.

KDE 4 sera vraisemblablement la première version de KDE à intégrer D-Bus grâce au binding Qtbus de TrollTech. D-Bus succédera donc à DCOP. GNOME est aussi de la partie, puisqu'il est prévu dans la feuille de route de remplacer complètement bonobo par D-Bus.

Jouer avec les bits lorsqu'on code est souvent un bonheur intense tant les possibilités sont larges malgré les axiomes 8/16/32/64 bits dont on dispose sur les processeurs (et donc) dans les langages.

De nombreux "grands maîtres", dont Brian Kernighan lui-même ont écrit de nombreux algorithmes utilitaires effectuant des travaux sur les champs de bits que sont nos mots mémoires.

On trouvera donc dans l'article cité, qui des comptage de bit (à 1 ou 0), des tests de parités parallélisables, des rotations de bits, des modulos, des log base 2 (et donc des log base n). L'article prévient en introduction que les problèmes de cache, bande passante mémoire doivent être pris en compte dans l'utilisation de l'algorithme sur l'architecture libre.

Un bien beau texte.

NdM : les extraits de code sont du domaine public d'après l'introduction du document.

Une dangereuse tendance se profile à l'horizon : l'hégémonie de Google.

Issu de la net économie, Google, à bien y regarder, est en train de mettre en place tous les ingrédients assurant une domination incontesté sur le net : l'accès à l'information. Google est le moteur de recherche le plus utilisé au monde avec 49% de part de marché. L'entreprise américaine propose des services de plus en plus complet et intégrés avec semble t-il un seul but : rendre l'internaute captif pour rassembler un maximum d'information sur son profil personnel. Bien entendu ce genre d'information est d'un intérêt énorme pour les publicitaires se trouvant en quelque sorte désorientés devant la multiplication des individualité, des profils, et de la difficulté de connaître ceux-ci sur l'internet afin de les "cibler" de façon appropriée.

Avec des services comme GoogleTalk, Gmail, GoogleMaps, GoogleGroups nécessitant souvent d'être identifié pour bénéficier des services, couplé à une infrastructure de recherche capable d'analyser une grande masse de données, Google est capable de posséder le plus grand répertoire de données personnalisées et donc en position de fournir des information d'une grande précision à ses clients publicitaires. Sur le marché de la publicité, ces informations valent de l'or et ouvrent la porte à l'hégémonie.

En face, Microsoft essaie de suivre avec MSN Search (un peu moins de 15% du marché) pour conserver sa position. Google n'a plus le choix que d'adopter une stratégie concurrentielle frontale. Privilégiant les applications utilisant le navigateur, de préférence Firefox, Google compte fournir des logiciels AJAX en ligne. Dernier coup de théâtre, l'achat de Writely, un traitement de texte en ligne, écrit avec AJAX.

Le libre dans tous cela ?

Google affiche depuis longtemps sa préférence pour le libre, d'autant que son modèle basé sur l'internet privilégie de fait des logiciels et standards ouverts. De plus, l'ouverture ou non de ses logiciels n'est pas un problème pour la société : c'est l'accès à l'information qui compte dans son modèle.

De lourds changements en perspectives...

Une nouvelle version du compilateur Lisaac est disponible.

Lisaac est le premier langage objet à prototype compilé. Digne héritier de Self et Eiffel (il a été conçu au sein du laboratoire où a été écrit GNU/SmartEiffel, sous la férule de Dominique Colnet), il améliore grandement les techniques utilisées dans SmartEiffel afin de produire un code aussi rapide que du C. Lisaac a été conçu dans le cadre du projet "IsaacOS" afin de disposer d'un langage objet de haut niveau, suffisamment performant pour écrire un système d'exploitation.

Pour cette version, la bibliothèque standard du compilateur passe en LGPL et l'ensemble du code fourni en exemple passe en GPL. En effet, Lisaac est fourni avec une bibliothèque complète, incluant depuis cette version des fonctionnalités permettant d'écrire des interfaces utilisateurs. Un gros effort a été fourni pour rendre le code totalement portable sous GNU/Linux, DOS et Windows (Lisaac produit du C ANSI).

Notez que le versionning est à rapporter aux spécifications originales du langages : le compilateur est stable et fonctionnel.