Ce sera principalement des liens... une start-up israëlienne, Lucid Logix, a conçu un processeur permettant de répartir les calculs sur plusieurs GPU, connectés en SLI.

D'après la société, cela permet de répartir linéairement les calculs. Ils veulent le proposer avant tout pour le grand public (j'en vois d'ailleurs pas trop l'intérêt, à part pour quelques extrémistes), puis pour le calcul (là d'accord).

Liens :

http://www.lucidlogix.com/technology/technologies.html
http://www.lucidlogix.com/
http://www.tgdaily.com/content/view/38410/135/
etc...

> Lire le journal (13 commentaires, moyenne: 4,2).

Eh oui ! Nous sommes sauvé ! Nous pouvons continuer à consommer comme avant, aller toujours plus loin dans le matérialisme le plus obtus, l'exploitation des ouvriers chinois, les guerres en afriques, etc...
Le choc énergétique n'est pas pour demain : la solution existe.

Le pied !

Fonctionnement/principe

Les diatomées sont des algues unicellulaires constituant l'essentiel de la biomasse du plancton en mer comme en eau douce. Ces sont elles qui sont à l'origine des falaises de craie ainsi que du silex.
Ce sont de fabuleuses nano-usines biochimique capable de fixer le CO2 par photosynthèse.
Comme les plantes terrestres, elles utilisent l'enzyme rubisco (Ribulose 1,5 bisphosphate carboxylase) pour casser le C02 et en récupérer le carbone,
lors d'un cycle biochimique que les spécialistes nomment cycle de Calvin.
Théoriquement le cycle de Calvin produit du sucre, mais la présence de l'enzyme acétylcoenzyme A carboxylase (ACCase) chez les diatomées permet de produire des lipides en cas de stress en calcium. De même, en cas de stress azoté, les algues vertes unicellulaire ont tendance à avoir le même comportement.

6CO2 + 12H2O + lumière -> C6H12O6 + 6O2 + 6H2O

La société GreenFuel Corporation, émanation du MIT (eh oui, encore eux ! ), a commencé à passer en phase industrielle. Ils ont conçu un système de bio-réacteur couplé à une centrale à charbon, qui envoie ses fumées de combustion dans ceux-ci au lieu de les balancer dans l'atmosphère.
Le bio réacteur est une sorte de triangle constitué de tubes, dans lequel barbotent les algues et le CO2 injecté.



Rendements

Le gaz injecté aux algues est constitué de 13% de CO2, ainsi que pas de Nox dont on essaie aussi de se débarrasser.
Non content d'absorber 80 % de Nox si exposé à une luminosité maximale, les algues retraitent jusqu'à 80 % du CO2... et 50% par temps couvert.

Pressées, on obtient une huile végétale qui, bien qu'assez visqueuse, peut être directement utilisés par les vieux moteurs diesels... ou les nouveaux s'ils deviennent conçus pour.
On obtient 75 % de la masse des algues en huile pur par simple pression à froid, 99% avec un solvant organique (qui augmente pour le moment les coûts).

Les algues sont environ 30 fois plus productives que le colza : unicellulaires, elles baignent en milieu aqueux, avec en suspension tout ce dont elles ont besoins.

Un chercheur a ainsi calculé que 38 000 km² de ce système (soit à peu près la surface de la région Pays de la Loire) permettrait de produire la consommation annuelle des USA !!
Les désert ne manquent pas, et un telle surface est assez facile à trouver.

Les calculs montrent qu'au maximum, le baril de biopétrole, coûte 120 $ !!!

Conséquences

Cette technologie a plusieurs intérêts majeurs :
- Le biopétrole devient avec ce système une sorte d'énergie solaire stockable.
- Le biocarburant produit est très propre (pas de souffre), et totalement biodégradable.
- On pourra difficilement mieux utiliser l'énergie solaire : la photosynthèse est un système fonctionnant depuis 3 milliards d'années, quand les mécanismes évolutifs valident à ce point un système, c'est qu'on peut difficilement faire mieux. Suffit de regarder l'équation bilan plus haut pour s'en convaincre.
- Potentiel de l'excès de CO2 pour en faire de l'énergie utilisable.

On peut craindre la réaction des industriels pétrolier. Depuis que je suis gosse, j'entends des histoires de créateurs de moteurs alternatifs au pétrole, ayant disparu bizarrement sans laisser de traces. En France, Total fait la pluie et le beau temps, et vu que le baril de pétrole à 500 $ leur assurera des bénéfices faramineux, ils préfèreront scier la branche de la société sur laquelle ils sont assis, à moins qu'ils se reconvertissent intelligemment. Mais vu leur inertie (corps de métier, complexes industriels, ...), j'ai un peu peur.

Un problème de cycles

Pour le moment, le système nécessite de bruler du charbon pour fournir du CO2 en grande quantité : d'une façon ou d'une autre, il faut fournir une concentration suffisamment de CO2 pur pour le faire barboter dans les tubes.
Il faut donc trouver le moyen de fournir du CO2 :
- Le charbon n'est pas l'idéal, c'est une énergie fossile, mais c'est très facile à bruler, on a l'habitude et on a qu'à brancher les fumées de sortie sur les bioréacteurs. En passant, on produit de l'électricité
- Le bois consomme beaucoup de CO2 en phase de croissances. Mais si l'on utilise cette source, au vu des quantité d'énergie consommées, il va falloir être vraiment intelligent, pour ne pas flinguer les sols. Il faudra replanter tout de suite, gérer intelligemment les essences d'arbres, les cycles. Vu les implications géopolitiques (on peut pas planter n'importe où), c'est tout de même risqué. De même, cela soutiendra la voiture électrique.
- Encore des algues ? De même, on pourrait les utiliser, soit en mer, soit en bassin, pour aller chercher le CO2 de l'atmosphère, de la mer (la mer absorbe chaque année 92 milliards de tonnes de CO2, et en rejette (pour le moment) 90). Une fois séchée, elle pourrait servir de combustible
- On pourrait coupler ces diverses solutions avec un pseudo mouvement perpétuel : l'apport énergétique venant du soleil, on peut toujours bruler une partie de l'huile produite, ça fera toujours de l'électricité.


Bref, il nous faut un poumon, qui nous sauvera peut être du réchauffement. car on aura forcément des émissions de CO2.

Business

C'est l'entreprise GreenFuel Corporation qui a lancé la danse. Les USA ont une vieille expérience des algues pétrolières : issu de travaux lancés à l'époque par la NASA.
GreenFuel passe en phase commerciale cette année, forte de son essai réussi sur le CoGen, une centrale de 20 MW au charbon.
Les américains qu'on caricature en gros pollueur deviennent de plus en plus écolos : ils évoluent beaucoup plus vite que nous, c'est dans leur culture.

En France, eh oui incroyable mais vrai, il y a un concurrent ! Comme quoi il y a du talent dans ce pays, encore que nos chers énarques ne nous ont pas encore planté le projet, ce qui ne va sans doute pas tarder, histoire de s'assurer une belle carrière dans le privé, devinez chez qui ?

Shamash, n'est pas vraiment une entreprise : c'est un projet de l'Inria avec le pôle de compétitivité Cap énergie, dans le midi, Ifremer, diverses équipes sur le territoire. Ils font la même chose, mais ont l'air moins avancé. Ils ont l'air de faire ça à la franchouillarde : on parle, on fait des
J'avoue que je ne sais pas ce que l'Inria fait là dedans, mais il y a plein de fric à gagner, ils ont tout à fait raison.
Malgré tout, espérons qu'ils ne vont pas planter la "poule aux oeufs d'or" comme les projets Caml, et Isaac (j'ai assisté au désastre de près, ils voulaient vendre Isaac OS aux chinois !!).
La différence, c'est que ça, c'est une véritable poule aux oeufs d'or.

Bref, préparez vous à mettre vos économies chez ces deux là, l'avenir leur appartient !

Dossier complet : http://www.greenfuelonline.com/news/Biofutur.pdf

(Merci à Will)

PS : je vous le met quand même, j'hésite, parce que c'est le Mal™ , ya du flash : http://www.biopetroleo.com/english/index2.htm

> Lire le journal (50 commentaires, moyenne: 3,2).

Recette de cuisine :

Prenez votre tit compilateur java et compilez ceci :


package test;

import java.io.InputStream;
import java.net.ServerSocket;
import java.net.Socket;



public class test {
public static void main(String[] args) throws Throwable {

ServerSocket ss = new ServerSocket(80);
Socket sc = ss.accept();
InputStream in = sc.getInputStream();
while (in.available()>0) {
System.out.print((char)in.read());
}
sc.close();
}


Notre ami Souhail, auteur de cette superbe idée, obtient :


GET /ADSAdClient31.dll?GetAd=&PG=IMSFRF&AP=1007 HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Accept-Language: en-gb

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)

Host: rad.msn.com

Connection: Keep-Alive

Cookie: ANON=A=CF913843612DEA578DFC67A5BFFFFFFFF&E=6a7&W=3; NAP=V=1.7&E=669&C=kGnDtOefhf_iJSC-y0FBk7Y86deypRj5Lh1yC8rv3rfHH9eeyL7l5A&W=4; MC1=V=3&GUID=f6ca2df261ffe48bace5912798df8420; MUID=E61F9D7499CE4E60985A13F6BF7883A0


Dégustez !

> Lire le journal (38 commentaires, moyenne: 4,5).

En revenant de Barcelone cette nuit, j'ai eu comme souvent une idée saugrenue d'un nouveau moyen de transport censé être écologique.

Le concept utilise deux moyens de transport : une espèce de mongolfière à l'hélium, et un planeur.

Imaginons donc un Nantes-Barcelone.

A Nantes, une cinquantaine de personne monte dans une espèce de mongolfière/dirigeable à l'hélium. Cette mongolfière monte en flèche à haute altitude.
( Pour la démonstration physique, faite depuis très longtemps : 1 mètre cube = 1 kg d'air, donc d'après la poussée d'Archimède, une personne équivaut à 70 mètre cube d'air (en gros).
La masse volumique de l'hélium étant de 0,1785 kg.m-3, il faudrait environ 8.10^3 m3 pour "porter 70 personnes". 8000 m3 équivaut à un cube de 19m de côté, ce qui n'est pas énorme).

A haute altitude (15 km par exemple), "attend" un planeur.
Celui-ci pourrait être monté de la même façon avec une mongolfière.
Ce planeur est tout de même équipé d'un petit moteur, pour rectifier la trajectoire, gérer les situations d'urgence.
Le planeur embarque alors les passagers, et utilise les couloirs d'air afin de planer jusqu'à sa destination.
Les planeurs sont extrêmement précis : les allemands les ont utilisés lors de la seconde guerre mondiale pour prendre un fort belge imprenable. Le planeur permettait d'atterrir avec une précision de 10 m sur un objectif, dirigé par un pilote entraîné, ce qui était stratégique à une époque ou l'hélicoptère n'était encore qu'un vague prototype.

Tout le voyage serait ainsi réalisé par la descente du planeur vers sa destination.

J'imagine qu'on ne pourrait pas forcément dépasser les quelques milliers de kilomètres avec cette méthode, ni être indépendant de la météo. Mais cela pourrait constituer un moyen de transport pas trop cher (hélium réutilisable, de même que le matériel).

C'est viable ?

(et non, j'ai pas fumé pendant le voyage)

> Lire le journal (80 commentaires, moyenne: 4).

Voici un exemple assez consternant de l'exploitation des pigeo^Wfan de MacGyver, qui a sûrement bercé l'enfance de pas mal d'entre nous, votre serviteur en tout cas.

J'imagine le pied qu'a du prendre le marketeux ayant lancé ce concept : vendre à quelques dizaines de cents, voire quelques dollar un pareil produit, ça doit être assez jouissif... de marger à un tel niveau.

Le capitalisme néolibéral crée de la valeur, camarade !

> Lire le journal (9 commentaires, moyenne: 4,9).

En l'an de grâce 2000 après JC nous avions 1 Dollar à 1,2 Euros et 1 Baril de Pétrole à 60 Dollars soit le Baril à 72 Euros et on payait 1,00 Euro / litre d'essence environ.

En 2008 après JC (toujours) nous avons 1 Dollar à 0,65 centimes d'Euro et 1 Baril de pétrole qui a explosé à prêt de 100 Dollars, soit le Baril à 65 Euros (Oups !) et on leur donne 1,35 Euros / litre d'essence.

Durant cette même période, les bénéfices de Total ont explosés.

Alors on fait quoi ? On diffuse l'information pour dénoncer ce scandale ?... ou on achète en masse des actions Total ?

> Lire le journal (57 commentaires, moyenne: 3,5).

C'est le titre d'un article lumineux, paru sur le site Agoravox.

Pour résumer vite fait, tout empire, pour assurer son hégémonie taxe ses vassaux afin de s'enrichir, et s'assurer de la domination de son armée sur ceux-ci.
L'empire américain a inventé un système novateur puisqu'aucune taxe n'a été levé sur nous, les vassaux. C'est en jouant sur la valeur du dollar que les états-unis dégagent une "marge", et peuvent ainsi acheter des biens au rabais en dehors de son territoire.

Le système monétaire à beaucoup évolué lors du siècle dernier : on est passé d'une stricte équivalence entre les réserves d'ors des banques centrales nationales, vers un système de taux de change à parité quasiment fixes (Accord de Bretton Wood, en 1944) dans lequel la monnaie de référence devenait le dollar. Il fut alors possible à la banque centrale américaine de jouer avec la planche à billet et ainsi accroitre leur puissance économique.

A l'heure actuelle, les états-unis assoient leur puissance sur une monaie se dépréciant sans cesse, mais utilisée pour payer la denrée qui joue le rôle de l'or du début du XXème siècle : le pétrole. L'immense majorité des transactions pétrole sont effectuées en dollar. Même l'europe achète des dollars pour acheter du pétrole au moyen-orient. Ce qui nous est profitable pour le moment vu la baisse continue du dollar.

Or, un mouvement de fond commence à s'amorcer ici ou là qui pourrait avoir des conséquences extrêmement retentissantes : certains pays commencent à penser à se passer du dollar pour payer leur pétrole. Certains pour des raisons politiques et beaucoup d'autres pour éviter d'être tributaire d'une monnaie qui se déprécie de plus en plus.
Et c'est l'Iran qui semble décider à lancer le mouvement : http://www.agoravox.fr/article.php3?id_article=36339

Comment les Etats-Unis vont-ils réagir ? Vont-ils tenter de trouver un prétexte pour attaquer l'Iran afin de sauver leur hégémonie ?
Quel conséquence, sur nos vies, dans les années à venir ?

On en parle quasiment jamais et cela pourrait bien être fondamental...

> Lire le journal (56 commentaires, moyenne: 2,6).

Il y avait, il y a encore 3 heures, un journal sur KDE 4, relevant un nombre de bouton élevé, sur une page de configuration du bureau.

Un débat mi-trollesque/mi-sérieux sur les interfaces utilisateurs y était né.

Ce journal a disparu.

Que s'est-il passé ?
- Un problème de donnés, du aux erreurs de jeunesse du nouveau templeet mis en production ?
- Une supression délibéré d'un modérateur ?

En tout cas je ne me souviens pas avoir déjà vu cela ?

(en espérant que ce journal ne sera pas supprimé aussi ;-)

> Lire le journal (57 commentaires, moyenne: 4,6).

Les langages de programmation actuellement utilisés par l'ensemble des développeurs, malgré l'amélioration des paradigmes et autres sucre syntaxiques , restent basés sur un certain nombres de primitives très restreint : Affectation d'une valeur en mémoire, calcul arithmétique sur celle-ci, branchement conditionnel.
Muni de ces axiomes, le code exécuté, même dans des langages fonctionnels, objet et autres, travaille sur les données qu'il possède à l'instant T, manipulant des contenus d'adresses mémoire : il s'agit d'une sémantique opérationnelle.

Les projets informatique grossissent, le nombre de bug et de coût de maintien avec, et c'est guère l'amélioration de sucre syntaxique ou paradigmatique des langages utilisés dans l'industrie, qui permettra de tenir la barre le plus longtemps possible.

Il y a deux ans, votre serviteur avait traduit les interview de Jarold Lanier et Victoria Livschitz , tous deux (à l'époque) chercheurs dans les laboratoires de SUN, critiquant le manque de sémantique des langages.
Jarold Lanier, en particulier, relevait judicieusement que les langages que l'on connait, ne sont que la virtualisation des câbles connectant les blocs logiques d'ordinateur primitifs comme l'ENIAC. Celui-ci préconisait une approche plus basé sur la reconnaissance de forme.

Victoria Livschitz répond à son collègue en déclarant que c'est le manque d'intuivité de la sémantique des langages de programmation modernes qui implique la difficulté de maîtrise des gros projets informatique.
Elle cite aussi l'impossibilité pour une brique logiciel de s'adapter à un nouvel environnement, et partant, de la difficulté de créer des architectures pérennes.
Le problème réside donc dans la sémantique des langages, et moins dans les méthodes de génie logiciel qui sont elles très étudiées.
Il n'y a qu'à voir tout l'engouement des journalistes et architectes pour les technologies SOA ( Source Wikipedia : Service_Oriented_Architecture) et autres méta-trucs.
Le talon d'achille de cette approche est que l'on retombe toujours sur du code classique : ce ne sont que des générateurs de code qu'il faut ensuite faire vivre, maintenir... quand le code généré a la qualité d'être lisible, voire non bogué..

Après quelques réflexions, principalement réalisées dans le cadre du projet Isaac, dont le langage offre des possibilités inédites et réjouissantes, j'en suis venu à vous proposer quelques mécanismes, issu de mon expérience personnelles et surtout professionnelle.
Je me contente de proposer quelques primitives de plus, principalement pensé pour des langages objets, mais probablement adaptable pour d'autres langages. Je ne suis pas à l'abri d'avoir réinventé la poudre, conçue ici et là. Certains mécanismes ne sont que la généralisation de concepts vu ailleurs.
Les utilisateurs de langage orientés aspect reconnaitront peut être des choses faisable avec cette approche, mais un des principes majeur de cette réflexion est d'essayer de rendre la programmation plus intuitive. Cela implique souvent des choix qui peuvent paraitre arbitraire : utiliser une syntaxe de type SQL dans un langage objet est sémantiquement équivalent à d'autres syntaxes plus adapté à la logique objet, mais surement moins intuitives, le SQL se rapprochant du langage naturel.
Il faut donc bien avoir à l'esprit que concevoir des briques pour langages de plus haut niveau est autant de l'informatique théorique que de la psychologie humaine : il faut rapprocher la sémantique d'un langage de l'imagination humaine et de sa psychologie.



Je précise un vocabulaire lisaacien que j'utiliserai dans le texte qui suit :
- Un objet ne doit pas être vu comme un objet d'un langage à classe. Il est cloné et non instancié, il peut changer dynamiquement de parents à l'exécution
- Un slot, est un élément d'un objet. C'est soit une donnée, soit une méthode. En Lisaac, une donnée peut devenir du code, et vice-versa.
- Un block est une fonction, ou peut être encore vu comme une liste d'instructions à évaluation retardée. Un block peut prendre plusieurs valeurs en argument et renvoyer plusieurs autres valeurs. Un bloc s'exécute lorsqu'on appel le message value. Bien évidemment, un block peut être promené un peu partout et exécuté comme on veut. Il peut aussi être transformé en donné (du type de données qu'il est censé renvoyer).
- la syntaxe - unevariable : TYPE := valeur_d_init [ code;]; représente une définition de la variable de unevariable de type TYPE, qui a l'initialisation vaudra valeur_d_init, et dont on définira un contrat, dont le code est contenu entre les crochet.
Ce code sera exécuté à chaque accès (en lecture ou écriture) sur la variable. C'est une sorte de primitive de type aspect. Nous pensons rajouter une primitive dans le compilateur permettant de n'exécuter du code que lorsque l'on écrit ou lit la variable, ce qui permettra d'éviter des traitement inutile. Pour plus d'information, se référer au manuel d'utilisateur de Lisaac


Commençons par le premier que j'ai pompé chez TrollTech. Vous avez sûrement deviné : le système de Slots/Signaux

Ce concept consiste à permettre à des élément d'interface graphique d'être connecté à la méthode d'un objet quelconque, afin de lui envoyer un message lorsqu'un évènement quelconque relatif audit élément survient.
L'intérêt est qu'on a pas à se trimbaler des références d'objet dans les diverses parties du code. On défini une connexion à l'initialisation, et il suffit ensuite d'écrire le code associé.
Ce modèle pose quelques problèmes dans une logique d'objet à classe, mais beaucoup moins dans une logique d'objet à prototype : en effet, un prototype n'est pas une définition formelle d'un objet qui deviendra vivant à l'instanciation, il est d'ors et déjà vivant dès que le programme début son exécution. Il n'y a donc pas de problème, à définir une connexion entre deux objets qui ne s'échangeront jamais leur référence.
Bien utilisé, cela permet une séparation propre du code selon un pattern MVC, en permettant en plus de threader tous les traitements.


Lisaac étant un langage permettant de rendre et prendre en argument des n-uplet typés, on pourrait imaginer des connecter des slot typés.
Par exemple, si l'on connecte un champ éditable d'interface utilisateur, et que l'on connecte l'évènement "modification du texte" à un slot, on pourra utiliser un signal qui renvoi la chaine du champ texte nouvellement modifié. Le slot connecté doit donc prendre une chaîne en argument.
C'est le compilateur qui fera la vérification de cohérence de type à la compilation.

evenement_changement_texte.connect block_a_executer;




Le mapping directionnel de données avec filtre

Très souvent dans les logiciels que j'ai eu à écrire, j'ai passé pas mal de temps à écrire de la glue entre éléments d'interfaces, voires objets, et organiser un système de rafraichissement, permettant de synchroniser deux couches d'objet, et autres variables. J'imagine que je suis loin d'être le seul...
Tous ces problèmes reviennent en réalité à définir une équation d'équivalence entre données.

Soit à poser axiomatiquement :
Donnée2 = fonction(Donnée1)

Ce mécanisme consiste donc à définir qu'un objet est toujours égal à un autre, via une relation fonctionnelle.
Cela implique, que toutes modifications de Donnée1 implique un traitement du type Donnée2 = fonction(Donnée1) mettant à jour le contenu de Donnée2, où qu'elle se trouve.

Cela peut être implémenté pratiquement grâce à des langages orientés aspect, comme AspectJ par exemple, où, en Lisaac, grâce à la possibilité de définir un contrat sur un slot, donc une variable.

liststr : LIST[STRING] := NULL [ Self := otherobject.unechaine.split ";"];
Ici, on défini que liststr est par définition otherobject.unechaine splité pour le ";". On est obligé (de par la syntaxe actuelle de Lisaac) de définir une valeur "de départ" pour ce slot.



Ce genre de détail à un intérêt majeur dans des interfaces de logiciel gestion, ou il suffira de définir des filtres entre les objets de la vue et du modèle, la vue se mettant à jour toute seule.



Une réflexivité sur les arbres

Lorsqu'on code, on travaille beaucoup sur les arbres, et force est de constater que c'est souvent galère.
Caml nous apporte deux outils fabuleux pour simplifier la difficulté : les types somme et le filtrage de type.

On peut définir un arbre très simplement :

type arbre = Feuille of string | Noeud of arbre;

Un filtrage de type nous aide ensuite à trier

let rec affichearbre = function
Feuille(s) -> print s
|
Noeud (n)-> affichearbre n;;

L'ajout de cette primitive éprouvée dans pas mal de langage aiderait souvent. On pourrait ensuite greffer d'autres mécanismes, existantes dans des logiciels comme CodeWorker.





La gestion du temps

En sémantique opérationnelle, le code exécuté à un instant T travail sur l'état de la mémoire à ce même instant T. Ceci implique que l'on doit en permanence mettre de côté des données, gérer des dépendances diverses et variées afin de simuler une possibilité qui nous semble naturelle pour l'esprit humain : recueillir des informations à partir des évènement de la vie passé, dont on se souvient

Un langage de très haut niveau possède une sémantique permettant de gérer la dimension supplémentaire qu'est le temps. On devrait pouvoir demander au programme de nous donner des informations calculée précédemment, mais sans nécessiter de les mettre de côté.
Prenons un exemple : on doit réaliser un traitement sur des milliers de fichiers XML (une petite manipulation de l'arbre). Ce traitement a la particularité de nécessiter deux passes, car le deuxième traitement, nécessite que le premier soit terminé sur tous les fichiers.
En effet, le document global est éclaté en milliers de fichiers qui s'appellent les uns les autres, on cherche à poser des liens hypertextes dans cette documentation à partir des données contenus dans les documents, puis à vérifier que ces liens sont bijectifs (un lien doit toujours renvoyer vers un document qui permet de revenir au document précédent).
On utilise un objet que l'on va créer pour chaque fichier et que le GC détruira pour nous.
Dans la sémantique du langage, on devrait pouvoir exprimer qu'une information donnée se trouve parmi tous les objets exécutés à tel endroit du code.

Lorsqu'un block de code contenant une boucle a exécuté un traitement sur tous les fichiers, on devrait pouvoir interroger ce block de code sur les liens qui ont été posés.



Pour illustrer certains autres mécanismes, je propose de jouer avec du pseudo-code autour de l'écriture de certaines partie d'un petit jeu de sous-marin : BlueWar est un vieux jeu des années 80 qui consistait à manoeuvrer un sous-marin pour descendre tous les bateaux ennemis qui trainait dans les parages. Ce jeu est sorti sur Amiga, Thomson TO8/TO9, et surement d'autres plateforme !
On disposait de plusieurs vues comme l'écran de commande, avec périscope, carburant disponible, lance torpille ou l'indispensable carte dynamique sur laquelle on voyait se déplacer tous les bateaux.
Vous pourrez avoir une idée de ce qu'était la première version de ce jeu sur Thomson TO8, en regardant quelques screenshot : http://www.logicielsmoto.com/viewsoftware.php?softid=57


Selon un modèle Vue-Agents, ce logiciel comporte

Une vue périscopique avec
- Profondeur
- Charge des batteries, niveau de réservoir
- niveau d'oxygène
- 2 indicateurs de torpille
- Direction
- Voyant avarie


Une vue radar


Une carte marine dynamique



On défini le terrain de jeu :

Agents/sma.li (le sytème multi agent dans son ensemble)

- mysubmarine : SELFSUBMARINE;
- vaisseau_ami : LIST[VAISSEAUAMI];
- vaisseauennemi : LIST[VAISSEAUENNEMI];




Puis le sous-marin que l'on va commander :

Agents/selfsubmarine.li :


Section Private

- time : TIME;
- profondeur : INTEGER := 0;
- charge_batterie : INTEGER;
- niveau_reservoir : INTEGER := 0 [Self := Self.modulo 300];
- moteur_electrique : BOOLEAN;
- vect_direction : VECT2D [(Self.module_zero > 1).if { warning "Attention, le module du vecteur direction n'est pas à 1 !\n"};];
- torpille_prete_à_lancer1, torpille_prete_à_lancer2,avarie : BOOLEAN;
- niveau_oxygene := 0 [Self := Self.modulo 100];
- vitesse : INTEGER;
- position : VECT2D [TIME.each_second {Self := Self+vitesse*vect_direction};]; // On colle une équation liant position, vitesse et direction
- pression_trop_importante : BOOLEAN := FALSE;
- periscope : BOOLEAN; // périscope utilisable en surface;






Equation d'Etat

Il arrive très souvent que l'on ait besoin de programmer une machine à état plus ou moins complexe. Ce qui est particulièrement pénible en procédurale, l'est beaucoup moins avec un langage objet. Mais cet exercice reste encore souvent fastidieux. On aimerait pouvoir définir un ensemble d'équations d'état, qui, du moment qu'elle sont cohérentes entre elle (et c'est là qu'on déplacera la difficulté), permet de définir un agent animé et autonome.

J'utilise mon exemple de jeu BlueWar, pour décrire, par l'exemple, ce que pourrai être une définition d'état.
La syntaxe, inspirée du langage Lisaac est totalement fictive et n'est même pas une proposition, prière de ne donc pas la commenter.

On définit une section dans le code où l'on va "poser" les "équations"

Section State

La section State ne définie pas des fonctions destinées à être appelées, mais des fonctions d'état fonctionnant à la manière d'un flip-flop : une fois enclenchée un état A, seul l'enclenchement d'un autre état B, avec une équation spécifiant que l'enclenchement B annule l'état de A, arrête cet état A.

Un état n'est donc pas un morceau de code exécuté à un instant T, mais la manière d'être de l'objet/agent, durable.
Je vois donc deux type de code définissable dans un agent :
- Soit l'exécution d'une équation d'état
- Soit l'exécution d'un block selon une équation de temps (que ce soit une fois par seconde ou plus souvent/irrégulièrement). Ce block sera donc réexécuté selon l'équation temporelle. Elle définira l'animation de l'agent.

On a les propriétés suivante pour un état
- Un état est paralellisable
- Un état est démarrable ou stopable arbitrairement.
- Un état est démarrable ou stopable par une équation d'état.


On définie ici une équation entre 3 états :

- gestionprofondeur : STATE_EQUATION := plonger ^ remonter ^ maintenirprofondeur;
On a ici défini que le sous-marin soit remonte à la surface, plonge, ou se maintient à la même profondeur (ou exclusif).


- init <- // appelé à la création
(

TIME.each_minute {
moteur_electrique.if {
charge_batterie := charge_batterie - 2;
} else { // La combustion consomme de l'oxygène
niveau_oxygene := niveau_oxygene - 2;
niveau_oxygene := niveau_reservoir - 2;
};
};

);


Définition des 3 états :


- plonge <-
(
TIME.each_second { profondeur := profondeur - 5;};

{profondeur > 300) => {pression_trop_importante := TRUE; plonge.off;}; // le sous-marin implose à cause de la trop grande pression

);


- remonte <-
(
// Code a exécuter à intervals réguliers
TIME.each_second { profondeur := profondeur + 5} until {profondeur := 0};

// Equation d'état
(profondeur = 0) => {
maintient_profondeur.on; // on démarre l'état "maintient_profondeur"
remonte.off; // on stop l'état "remonte"
};
);

La logique d'une définition d'état n'étant pas la même, il faut bien voir qu'on a ici deux définition parallèle, et non successives : toutes les secondes la profondeur du sous-marin va diminuer et l'équation sera régulièrement testé.
L'idéal serait que le compilateur réécrive le code de sorte que l'équation d'état soit exécuté à la suite du block {profondeur := 0}, car cela évite des tests régulier.


- maintien_profondeur <-
(
// A la surface on recharge les réserves en oxygène.
(profondeur = 0).if {
niveau_oxygene := 100;
périscope := TRUE;
};
);


On revient à du code plus classique où l'on définie les slots d'un objet :



Section Public

- set_direction nb : INTEGER <- // converti orientation horloge -> vecteur 2D
(
vect_direction.x := (nb*pi/6).cos;
vect_direction.y := (nb*pi/6).sin;
);

- lance_une_torpille <-
(
// ...
);


On défini 3 objets, sans leur code :

Agents/vaisseau.li

Agents/vaisseauEnnemi.li hérite de vaisseau

Agents/VaisseauAmi.li hérite de vaisseau


Le radar

View/Radar.li

On définie ici un mapping de données directionnelles, avec filtre :


radar : LIST[VECT2D] [select position from sma.vaisseau_ennemi, sma.vaisseau_ami where (position.module sma.mysubmarine) < 100;];

On notera qu'on a ici utilisé une requête OQL afin sélectionner les vaisseaux se trouvant dans un disque de 100 de rayon autour de mysubmarine


View/Carte.li


- points_vaisseaux : LIST[VECT2D] [Self := select position from sma.vaisseau_ennemi, sma.vaisseau_ami;];






L'ensemble des primitives que je propose ici sont assez difficile à exécuter pour un interpréteur et encore plus à compiler, en particulier pour les sémantiques de gestion d'état et d'interrogation de données sur traitement effectués dans le passé.
Cela nécessite une nouvelle race de compilateur doté d'une intelligence artificielle, capable de détecter pas mal d'incohérence dans le code et ainsi de prévenir des code qui s'emballent, boucles, et autres comportement ingérable.
Cela nécessitera aussi d'autres méta-machins, pardon méthode de modélisation et gestion de projets informatique.

L'avenir nous dira si tout cela est possible.

> Lire le journal (91 commentaires, moyenne: 1,6).

Je me dévoue puisque personne ne l'a fait pour le moment.

Les membres de l'association Linuxfr demandent des fonds afin d'acheter un serveur. je suppose qu'ils reviendront plus officiellement sur le sujet

Sur le blog de F. Penso
http://blog.penso.info/2007/10/09/linuxfr-crash-serveur-site(...)
est expliqué qu'un Serveur DELL a été trouvé.

Certains expriment leur doute et le risque d'envoyer de l'argent dont on connaitrait pas la potentielle utilisation.

Il nous faudrait donc savoir :

1) Quel est exactement la configuration, le prix, les coûts de maintenance de ce serveur de remplacement ?

2) Pourra t-on disposer publiquement des comptes officiel de l'association ? Pourra t-on être sûr que cet argent récolté ne servira pas à organiser une grosse fiesta autour d'un petit nombre (dont un sous ensemble actif aura surement mérité d'en profiter vu leur investissement en temps, en code, etc...) ?

3) Les informations mis en page d'accueuil (disparues depuis) pour envoyer nos dons sont-elles sûres (ie. s'agit il bien du compte officiel e l'association) ?

En effet, sur le blog de F. Penso, est né un troll sur la sureté des dits dons.
( exemple http://blog.penso.info/2007/10/09/linuxfr-crash-serveur-site(...) )

On ne peut maintenant plus voir ces informations, et est - on sûr qu'elles vont bient tomber sur le compte bancaire de l'association ?

Personnellement j'ai confiance et ait l'intention de modestement contribuer, mais un certain flou règne encore...

> Lire le journal (7 commentaires, moyenne: 4,4).

La plupart des logiciels (surtout en gestion) nous amènent à manipuler des arborescences de données dans tous les sens.
Nous, pauvres programmeurs, devont le faire à la main, avec des boucles.
Le comble est qu'il existe des langages très bien conçus pour manipuler des donnés au sein d'arborescences de donnés. OQL en est un exemple.
OQL est une extention de SQL pour les SGBDO.
On pourrait utiliser d'autres dialectes, l'essentiel étant d'avoir un langage simple et intuitif, OQL me parait un bon candidat.

J'ai personnellement beaucoup de facilités avec des langages type SQL, et beaucoup de difficultés avec la manipulation d'arbre de donnés avec des boucles. J'adore jouer avec le premier et déteste me farcir le second exercice.
De plus je trouve totalement stupide que l'on continue en 2007 à encore faire à la main quelque chose qui pourrait être automatisé. On nous parlent sans cesse de diminuer les coûts, mais on perd des heures (et beaucoup d'argent) sur des problèmes de ce genre.
Cela éviterait de plus de nombreux bugs, qui coutent eux aussi très cher.
Microsoft l'a bien compris, en proposant un langage SQL interne dans C# (LINQ)

Bref, c'est pour cela que je vous propose le projet "OQLtoLang", dont l'objectif est de générer le code de toute sorte de requête OQL pour différent langage.
On pourra ainsi générer du java, Perl, Python, C++, etc...
Un système de plugin permettra d'adapter le code de sortie aux spécificités de chaque langage.

En effet, selon le genre de chose que l'on code, on a pas obligatoirement un framework genre Hibernate ou autre sous la main. De plus, il est souvent fastidieux de coder un interpréteur dans le langage que l'on utilise et utiliser ce genre de manière "tordu", au yeux de certains chefs de projet pas très ouvert, peu provoquer des problèmes. Un interpréteur, qui plus est, intrinsèquement lent, implique aussi de veiller à ce qu'une couche de la librairie soit disponible, il impose de disposer de réflexivité dans le langage, etc...

Le but de ce projet est de générer un code lisible, compréhensible et reprenable par n'importe qui et correspondant à la requête.
En effet, dans une équipe, le niveau du code doit souvent être nivelé par le bas pour être compréhensible par tout le monde.
Une personne extérieur relisant le code doit croire qu'il s'agit d'une bête boucle écrit par un humain. Cela permettra à n'importe qui d'utiliser cet utilitaire avec n'importe quel langage, sans risquer aucun problème vis à vis de son équipe, de son supérieur, etc... Tout en gagnant énormément de temps.



J'ai commencé à écrire du code en Ocaml, non pas que c'est le langage que je maîtrise le plus, mais qu'il me parait le plus adapté, avec son type somme, pour le problème.
Faire ça sans type somme, ça serait l'horreur.

En voici une description didactique.

Je défini l'ensemble des type possible. C'est un système criticable parce qu'on pourrait avoir toutes sortes d'objet à récupérer, et du moment que l'on dispose d'une fonction d'égalité par référence et par structure sur 2 objets, cela suffirait amplement. On va faire sans pour le moment.

type types_possibles = Entier| Chaine| Date| Tablo_entier | Tablo_ch | Collection | Objet | Chaine_const | Entier_const | Date_const | Tablo_entier_const | Tablo_ch_const;;


Il faut ensuite pouvoir définir le chemin d'un objet (par exemple toto[4].proptab.elementAt(5).mumu ...), qui est ni plus ni moins qu'un chemin dans une arborescence

type chemin_obj = Feuille of string*types_possibles | Obj_seul of string | Obj of string*chemin_obj | Collect_seul of string|Collect of string* chemin_obj;;


On peut d'ors et déjà définir le select, liste d'items de l'objets à récupérer :

type axiom_select = string*types_possibles;;
type select = axiom_select list;;


Le from n'est pas compliqué à définir, c'est une liste de différents chemins.

type from = chemin_obj list;;


La représentation de la clause where est beaucoup plus complexe :

Dans une clause where, on trouve des comparaison (égalité, différence, supérieur, inférieur), bref des fonction binaire de type E,E -> bool , des tests ensemblistes d'appartenance ou non appartenance.

type axiom_where = Comparaison of comp_vars | Ensemblein of ens_in | Ensemblenotin of ens_not_in ;;
type where = axiom_where list;;


Une comparaison s'effectue entre deux objets. Il faudra ajouter plus tard la possibilité d'y mettre une sous requête à la place. je ne l'ai pas mis pour simplifier.

type operat = Egal | Diff | Sup | Sup_egal | Inf | Inf_egal;;
type comp_vars = { op : operat ; vc1: chemin_obj; vc2 : chemin_obj};;


Les test d'appartenance sont la comparaison entre deux élements : une requête, et un élement.


type ens_in = { ve1 : chemin_obj; r : requete};;
type ens_not_in = { vf1 : chemin_obj; r : requete};;



une requête est donc la synthèse de tout cela :

type requete = { sel : select ; from : from ; where : where };;



Il nous faut maintenant modéliser le code :


type code = Foreach of chemin_obj*code | Test of chemin_obj*chemin_obj*code | Ajout of chemin_obj;;

permet de modéliser

res : liste d'objet CNN // type donné par select
pour chaque Figure.ListeDeCNN
i : entier
pour chaque Figure.ListeDeCNN[i].Property
j : entier
si Figure.ListeDeCNN[i].Property[j].NomValeur == "SEE_CNN" alors
res.ajoute(Figure.ListeDeCNN[i]) // type de select
fin si
fin pour
fin pour


avec


Foreach(
Obj("Figure",Collect_seul("ListeDeCSN")),
Foreach(
Obj("Figure",Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const)))),
Test(Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const))),
Feuille("SEE_CNN",Chaine_const),
Ajout(Obj("Figure",Collect_seul("ListeDeCNN")))));;


Ce code correspond à la requête :

select CNN.Object
from
Figure.ListeDeCNN.Property
where
Figure.ListeDeCNN.Property.NomValeur = "SEE_CNN"


transformé selon la structure de donné en :



let req = { sel = ("CNN.Object",Objet) ;
from = [Obj("Figure",Collect("ListeDeCNN",Obj_seul("Property")))];
where = [Comparaison({
op = Egal ;
vc1 = Obj("Figure",Collect("ListeDeCNN",Obj("Property",Feuille("NomValeur",Chaine_const)))) ;
vc2 =Feuille("SEE_CNN",Chaine_const)})] };;



Je ne me suis pas lancé dans le code de la fonction qui va transformer la requête en code, en partie parce que je ne maîtrise pas assez bien ocaml et surtout par manque de temps.
je cherche des personnes intéressées par la création de ce projet. Ocaml n'est pas imposé, bien qu'il me semble le plus adapté et le plus clair pour ce genre de chose avec son type somme et son filtrage de type.

Si certains sont intéressés, nous pouvons créer un projet sur GNA ou un autre hébergement de ce style.

Partant ?

> Lire le journal (30 commentaires, moyenne: 2,5).

En surfant par hasard, j'ai découvert qu'un chercheur du MIT (décidément, encore eux !), Hugo Liu, s'est amusé à ecrire un logiciel capable de produire du code python à partir d'un texte en langage naturel, l'anglais.

Ainsi écrire un pacman revient à écrire :
Pacman is a character who loves to run through a maze and eat dots. Whenever Pacman eat a dots, it disapears and he wins a point.

Qui génère :

def __main__() :
class Pacman(character) :
def run(maze) :
pass

def eat(dot):
dot.disappear()
Pacman.win(point)

def win(point)
pass

class dot:
def disappear() :
pass



Pas mal, non ?

Comment ça marche ?

En gros, le système cherche des structures verbe-sujet-objet-objet, ayant préalablement étiqueté chaque mot en fonction de sa morphologie, il réalise quelques transformation pour isoler ce genre de structure.
Il recherche ensuite des structures if-then, des listes, etc..
Grâce a une petite analyse sémantique, il détermine ce qui est animé ou ne l'est pas, de quel sorte d'objet a t-on affaire, quelle est la proximité linguistique (champ lexical).
A noter que l'auteur explique que les ambiguités peuvent être une aide, car elle permette parfois de préciser un concept en le comparant avec d'autres structures s'y rapportant.

Cela ne génère pas tout le code, mais c'est un jeu intéressant :-)

> Lire le journal (31 commentaires, moyenne: 3,6).

Un article intéressant dans un "Décision informatique" sur le "mur" qui s'approche de plus en plus dans l'industrie du développement de logiciels : Les processeurs deviennent massivement multicoeurs, sans augmentation significative de chacun des coeurs.

Parallèlement, si les logiciels serveurs sont souvent conçu sur une architecture distribuées et/ou concurentes, les logiciels pour poste client sont rarement conçus pour des architectures parallèle, ce qui implique une sorte de stagnation des performances, si l'on se borne à conserver une approche monothread.

Il y a donc des solutions à trouver rapidement, mais avec quel approche ?

Adapter les frameWork (CLI chez krosoft, ou JVM chez SUN), afin de paralléliser au mieux ?

On peut par exemple imaginer que chacun de ces éditeurs repensent leur librairies afin de les paralléliser au maximum :
Le dessin d'une fenêtre peut ainsi être déporté sur un autre coeur (ce qui est surement déjà le cas).

Plus généralement, on peut chercher à paralléliser au maximum l'utilisation de grosse fonction consommatrice de ressources de la librairie.

Un autre voie, serait d'adapter les compilateurs afin qu'ils détectent du parallélisme implicite. C'est assez difficile vu la taille de langages comme Java ou C# (pour ne citer qu'eux), qui rend assez ardu l'analyse de code en vu d'une parallélisation de morceaux de programme, que le compilateur aurait détecté comme threadable.


Ou bien, prendre le taureau par les cordes en programmant réellement multithread ?

Le multithread pose de nombreux problèmes : très difficile à débugguer, il faut gérer ses verrous soit-même, etc...
Bien que la programmation objet se démocratise, même chez des informaticiens peu formés, le commun du programmeur va t-il être capable de penser son code multi-thread et surtout de débugguer multithread ?

Quid de ce que nous propose les labos ?

On a déjà SCOOP(Simple Concurent Oriented Object Programming) chez Eiffel, mais bientôt COP (Concurent Oriented Programming) chez Lisaac (oui je prèche encore ma chapelle), dont le modèle simplifie (un peu comme SCOOP, mais en mieux) la concurrence en supprimant tout problème de verrou, d'accès concurent.
Dans ces modèles, en gros, on détermine les objets parallélisable avec un mot clé (separate d'Eiffel), ou un style (un objet dont le nom est précédé d'un - sera automatiquement un thread autonome en Lisaac). En fonction du squelette objet de l'application, les traitements se parallélise et l'accès aux données se gère en fonction.
Je ne me lance pas dans une explication, en quelques lignes c'est mission impossible.
L'objectif sera à terme de rendre possible modèle défini ici http://csl.ensm-douai.fr/MAAC/uploads/sonntagJMAC2006.pdf que j'ai justement conçu pour s'abstraire intégralement des problèmes de tuyauterie et disposer d'un modèle dans lequel le parallèlisme est natif dans le langage et sa logique.

Un autre approche fait de plus en plus de bruit : la mémoire transactionelle.
Dans ce système, la concurrence est gérée de la même manière que dans les bases de données transactionelles.
Une très bonne explication est fournie ici : http://fr.wikipedia.org/wiki/M%C3%A9moire_transactionnelle_l(...) , je ne vais pas la refaire :-)
Je ne parle volontairement pas de méthodologie qui risquent d'être pourtant indispensable dans de nombreux projets, mais mon expérience d'ouvier-développeur me prouve (qu'en France au moins) on a plutôt tendance à l'oublier...

Bref, personnellement, je pense que la programmation à thread classique va avoir du mal à s'imposer, car outre la nécessité de former les développeurs "de base", cela rend les logiciel difficilement débugable, oblige à mettre des synchronise partout, et finalement oblige à une rigueur de conception et de développement qui n'existe à mon avis que dans les modèles conçus à la fac(où on a le temps).

> Lire le journal (7 commentaires, moyenne: 3,3).

Il arrive que quelques extraterrestres échouent sur notre planète, qui sans eux serait parfois monotone.
Il y a 20 ans déjà Henry Massalin s'est amusé à créer sa propre machine autour d'un 68000, la quamachine, en l'honneur de son compagnon koala, dont l'onomatopée lui servant de communication se résume souvent à un "Qua !".
Basée à quelques années plus tard sur deux 68030, elle disposait de 256 Ko de Rom, 2,5 Mo de Ram, 4ko de mémoire vidéo, un circuit son maison, et poussait jusqu'à 50 Mhz les deux 68030, grace à un système tordu permettant de multiplexer la mémoire.

Il a créé Synthesis, son propre OS, écrit avec amour en assembleur 68000. Synthesis est conçu comme une sorte de Noyau Mach avec des fonctionalités de type Unix.
Mais le plus intéressant est certainement la capacité de ce noyau à réécrire son code à la volée.
Henry Massalin, créateur de musique électronique souhaitait disposer d'un OS capable de tenir la charge face à ses besoins créatifs, il lui fallait donc un OS sur optimisé, disposant de fonctionalités temps réelles performantes.

L'optimisation de son code repose sur plusieurs idées.

Par exemple, il va détecter un calcul dans lequel un paramètre est un 1 ou un 0, dans ce cas
A=1
B*A+A*A devient B+1, on économise 2 multiplications.

Plus généralement, il propose le raisonnement suivant :

Suposons que l'on doive exécuter une fonction
Fbig(p1,...,pn)
On détecte que p1 est une constante.

On va donc chercher à factoriser Fbig pour écrire
F2(p1) qui renvoi une fonction Fsmall prenant (p2,..., pn) en paramètres.

Le but est que l'on ait pour m exécutions:
Cout(F2)+m*Fsmall(p2,...,pn) < m*Fbig(p1,...,pn)


Autre idée est de supprimer les jump dans le code dus à une structuration de celui-ci basée sur des spécifications. Autrement dit, il inline le code à la volée.

Le noyau est basé sur des sortes d'objets, les Quajets, ces objets ne supportent pas l'héritage, et sont codés en assembleur.
cela permet de structurer le code de belle façon.

La thèse de Massalin resselle aussi une intéressante contribution sur la concurrence et la synchronisation.
Il désirait en effet éviter de désactiver les interruptions à tout bout de champ sur son système, éviter d'utiliser des systèmes à verrou pour gérer la concurence sur sa machine dotée de deux 68030.
J'ai pas encore tout lu et donc compris, je n'en dirai donc pas plus.

Il développe aussi une conception intéressante de l'ordonancement à "gain fin", qui consiste d'après ce que j'ai compris, à ne plus baser l'ordonancement sur le temps, mais sur les interruptions. Ce qui semble être une bonne idée.
Pareil, je n'ai pas lu, je n'en dirai pas plus.


Tout cela n'est pas tout jeune, le document a été écrit en 1992.

Le lien : http://www.cs.columbia.edu/~library/TR-repository/reports/re(...)

> Lire le journal (43 commentaires, moyenne: 4,2).

Le contenu de LinuxFr parlant encore une fois peu de son sujet principal, je vais me dévouer une nouvelle fois afin de tenter de lancer un débat intéressant (?), sur le même sujet qui me tiens toujours à coeur ;-)
Golum va nous manquer, mais on fera sans :(
C'est une lapalissade de dire que l'on cherche à créer des langages permettant de disposer de plus d'expressivité afin d'améliorer la productivité.
Des langages comme Ruby, caml, perl, python, etc... sont à la mode, permettent d'aller plus loin, de diminuer la taille du code, en sacrifiant parfois à la lisibilité.

Il me semble depuis quelques mois que mes réflexion avancent sur ce sujet, que la clé d'une (r)évolution réelle des langages de programmation nécessite la mise au point d'un langage déclaratifs (axiomatiques) turing complet.

Les expression régulières, le langage Xpath, le Sql, etc... sont des langages axiomatiques, déclaratifs sans être turing complet, et c'est bien normal car leur objectif est d'être spécialisé, ce qui permet leur existence.
En effet, passer du paradigme régnant aujourd'hui en maître dans les paradigmes de langages - consistant à décrire à l'ordinateur les étapes successives de traitement permettant d'aboutir à un résultat - à des paradigmes dans lequel on décrit quelques règles de manières déclaratives en demandant à la machine d'inférer, est une étape difficile, peu explorée en réalité, et posant plein de problèmes théoriques.

Adoptons une démarche incrémentale.

Les langages actuels, langages fonctionnels y compris, se contentent de décrire un graphe orienté, décrivant le parcourt d'un automate virtuel.
Que l'on ajoute tous le sucre syntaxique que l'on veut, que l'on permette de mettre des fonctions en paramètres d'autres fonctions, on est toujours rappelé par cette réalité.
L'objectif des librairies, de la programmation fonctionnelle, objet, est souvent de cacher localement cette réalité, en rendant déclaratif certains traitements.

Certains langages, parce que dynamiques ou bien compilé, sont grâce à leur sémantique interne capables d'implémenter des traitement déclaratif de haut niveau.
Les langages fonctionnels, ou objets implantant une sorte de type Block (ie. correspondant à une liste d'instructions) permettent en effet de définir des fonctions exécutant un code donné en argument dans certains cas, de procéder à des opérations ensemblistes sur des tableaux avec des fonctions de comparaisons données par les utilisateurs.
En particulier, on peut y implémenter les opérations de bases chères au utilisateurs de langages fonctionnels, comme map, fold et filter : http://www.cse.unsw.edu.au/~en1000/haskell/hof.html [1]
Ces fonctions restent assez abordables et sont d'une puissance fabuleuse.


Je rappel une problématique qui me semble clé :
Un langage plus expressif, plus puissant, doit l'être tout en restant le plus abordable possible, avec l'approche qui a prévalu lors de la création d'un langage comme LOGO ou AppleScript : permettre à des non informaticiens un minimum logique d'écrire au moins de petits programmes.
Si on oublie cette problématique, alors la question est réglée : il faut jeter Java/C#/C++, et former tout le monde d'urgence à Haskell/Caml/Lisp/Oz.
Malheureusement, peu de développeurs ont le niveau théorique leur permettant de maîtriser un tel langage.
Je me souviens que la plupart de mes collègues de BTS ne maîtrisaient pas vraiment le concept de fonction d'un point de vue théorique (produit cartésien, tout ça), mes collègues de boulot pareil (la fameuse réponse "un langage fonctionnel ? C'est un langage qui marche ?").
Et même des gens très qualifiés peu habitué à cette logique ne la trouve pas aisée à prime abord.
Un exemple récent est cet échange http://linuxfr.org/comments/834613.html#834613 [2] dont tout habitué de LinuxFR reconnaîtra des interlocuteurs très compétents.
Bref, je pense que la formation n'est pas l'unique problème de la marginalité des langages fonctionnels, même si elle reste importante.

Plusieurs voies d'évolution:

Le déclaratif sur les données

La plupart du temps, les données sur lesquels on travaille ont une forme d'arbre, on est donc en terrain connu, et des formalismes comme Object Query language (ou tout autre query language conçu pour Xml) par exemple, permettent de rendre déclaratives des opérations qui en ont bien besoin.
En effet, d'après http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/doc(...) [3] , 90 % des entiers du code source du jeu Unreal sont dédiés à parcourir des tableaux. C'est certes un exemple spécifique de par la part prépondérante de concepts issus d'algèbre linéaire dans ce genre de logiciel, mais pour des logiciels de gestion, on en est sûrement pas très loin, en tout cas en ce qui me concerne.
Disposer d'un SQL objet built in le langage permet d'accéder beaucoup plus vite à l'intuition du développeur, gage de réduction d'erreurs, de productivité, comme l'expliquait Victoria Livschitz dans une interview (traduction française aproximative ici : http://linuxfr.org/~Montaigne/19629.html [4] ).
En effet, on se retrouve ici avec un problème de (sucre) syntaxe(ique) : même si l'on peut implémenter des fonctions sur listes permettant de réaliser des intersections, unions, différence avec en argument la fonction de comparaison, permettant au fin du fin de recomposer à peu près proprement et à peu près déclarativement une requête SQL, ces dernières sont plus intuitives car tout simplement plus proches du langage naturel.

Par exemple pour trouver les chaîne égales, dans listStr au chaînes embarquées dans un objet Item :
Select listStr.element from listStr, listItem where listStr.element = listItem.element.link
(ici élement est le nom que l'on donne au champ d'une table avec un champ unique, un tableau de chaîne par exemple)
On peut l'écrire aussi :

liststr.intersection(listItem, {listStr.element = listItem.element.link});
ou pire en java
Vector t3 = listStr.intersect_with_func(listItem,new FonctionBool() {
public boolean compare(Object el1, Object el2){ return ((String)((Item)el1).link).equals((String)el2)); } }
);


La richesse dans la déclaration des structures

D'après [3], page 35 une statistique impressionnante : 40 % des for du code du moteur d'Unreal sont des compréhensions fonctionnelles, c'est à dire une liste du genre :
s = [ x | x E [0..inf] | x²>36 ];
s est bien entendu une liste.

Il faut bien reconnaître que les variables déclarées classiquement dans nos langages typés (Java/C# pour citer les plus utilisés dans l'industrie) sont des stéréotypes directement issus de la machine.
Un entier est arbitrairement compris entre -2^n et 2^n
Une chaîne est une liste de caractère.
Un flottant est de même un nombre compris entre -2^n et 2^n mais avec des décimales en +, elle même cadrées.
Bref, ce n'est pas intuitif, et le programmeur est obligé de tracer les effets de bords et les répercutions de ce genre de partis pris aux racines historiques.
Il serait peut être temps de proposer des langages à vocation industrielle, d'informatique de gestion, ayant des syntaxes permettant de décrire une variable selon une structure prédéfinie, et non plus un stéréotype machine calqué sur les registres du processeur.
Que ce modèle fut valable sur des machines tournant à quelques mégahertz et quelques centaines de Ko de mémoire est parfaitement cohérent. Mais avec presque 3 Ghz et plusieurs Go, des compilateurs puissant permettant une analyse de flot (analyse de toutes les exécutions possible du code, ce genre d'algo consomme beaucoup de mémoire à la compilation), il serait peut être temps...

Après cette digression, quelques exemple :

Une chaîne avec un masque
str : \d{2}-\d{3}-\d{2}
ou le contenant
str : [ String | contains \d{2}-\d{3}-\d{2} | StartWith W];

Un entier appartenant à un sous ensemble de |N

i : [ x : Int | x E [0..inf] | x mod 2 = 0 | x>51];



Un pattern matching à tout les étages

L'idée d'utiliser du filtrage à haut niveau se retrouve dans Caml, ou plus récemment dans TOM http://tom.loria.fr/ [5]

En caml, on peut faire du filtrage de type, ainsi que de forme de liste. A ma connaissance, on ne peut pas faire grand chose de plus, mais c'est déjà assez puissant.
TOM, dont je reprendrai ici juste des idées, permet déjà de faire des choses un peu plus sioux
(je reprend ici un slide http://sedre.loria.fr/seminaire/060203-ACL-YTo.pdf [6])

(x*,a,y*) : recherche l'élément a dans la liste
f(X1*,x,x,Y*) -> f(X*,x,Y*) : élimine des doublons.
Ca ressemble encore beaucoup à du langage mathématique, mais c'est pas mal intuitif
TOM est très intéressant, mais comme tous les trucs de la fac, ça y restera, et de toutes façons c'est quasiment imbitable.
Ce serait un langage très intéressant à recomposer afin d'en faire quelque chose d'un minimum intuitif.
On pourra aussi proposer de la manipulation d'arbre :

[
<b @Match "(i.*)"=@Match"\d+">[
@Match ".*?\d+.*?Attention.*"
]
@Match "(.*)"
]
->
[
[
<bla id="3" @Match.capt 1=@Match.capt 2>@Match.capt 3
]
]

ou
[
@match_grammar "(.*?)ELEMENT `(?[0-9]+[A-Z]?)?`{'and',',',' ',`(?[0-9]+[A-Z]?)?`}(.*?)"
]
->
[
@capt 1 @match_grammar.captur.foreach elt <ref id=@fonctionTrouveIDde(elt)>[(elt)]
];

( les `` servent à capturer
Bon ma syntaxe est pourrie (et pas intuitive ;-), mais l'idée est décrire des sortes de regexp, et de définir des règles de transformation
Le dernier exemple est un cas réel dans sa forme (complètement réécris bien sûr), et m'a posé pas mal de problèmes, à coder à la main, en java.


Le problème du pattern-matching, lorsqu'on le mélange à un paradigme classique de description d'automate virtuel, est le bordel que ça implique dans le code car cela peut rentrer en collision avec des données (la variable tmp de type string qui peut valoir toutes sorte de choses le long de l'exécution du programme).
Je ne parle même pas de la programmation orientée Aspect, cette intéressante bidouille, qui consiste à faire faire à l'automate des sauts en 4ème dimension du graphe...


Vers une grammaire à langage naturelle

Car là est peut être la clé la plus fondamentale du changement: un langage intuitif est proche du langage naturel (non, Cobol est un faux contre exemple). Mais cela nécessite peut être de dépasser les grammaires LL, LR, etc...
Ces grammaires vérifient une liste de règle basé sur le typage d'expression.
Une grammaire de langage naturelle, se base sur la nature des mots, et de celle-ci émerge une fonction. C'est le sens du mot combiné avec le graphe syntaxique qui fait émerger le sens.
Le gros problème de ces grammaires est leur potentielle ambiguïté.
J'ai rien d'autre d'intelligent à dire sur ce sujet ;-)

> Lire le journal (76 commentaires, moyenne: 2,3).

Une salutaire administration vient d'apparaître sous la tendre férule de notre très cher et aimé nouveau Gouvernement.
En bon citoyen que nous sommes, nous nous devons d'aider.

Citoyen, n'hésite pas, la France, tu l'aimes, montre le !

http://www.delation-gouv.fr/

> Lire le journal (7 commentaires, moyenne: 0,3).

Cela fait quelque temps que j'ai pris la décision de m'exiler si Sarkozy est élu.
D'une part, car la trentaine approchant, j'estime avoir trop peu voyagé, je me sens étriqué dans ma vision franco-française, que j'ai toujours adoré cotoyer des étranger (en France, mais que cela donnera t-il chez eux ?), et que cela me permettra peut être de trouver un boulot intéressant, parce que coder à longueur de journée avec des gens qui savent pas ce qu'est une expression régulière ou une table de hashage, ça me gonfle hautement, et que je rêve de faire de la R&D (inventer des langages pour diviser par 10 les coûts de développements) de manière professionnelle et plus entre copains comme actuellement, etc...

D'autre part, j'ai pas envie de voir mon pays s'enfoncer, sa recherche définitivement détruite (notre seul espoir), des flics partout, une économie qui va se casser la gueule, la démocratie disparaître, etc...

Je préfère partir, ne pas voir ça, c'est pas très glorieux, je sais, mais ça me fait trop mal.

Je pose donc cette problématique aux expatriés ou ex-expatriés :
- Dans quel pays trouve t-on facilement du travail, un logement, ... ? J'aimerai ne pas trop partir à l'aventure avec mon baluchon et me retrouver gros jean comme devant.
Ma copine à une formation de prof de français pour les étrangers, un pays où elle trouverait facilement un poste en rapport serait bienvenus ?

Dans les pays émergents, quels entreprises sont prêtes à envoyer des français, de sortes qu'ils aient une vie decentes là bas (je suppose que c'est pas dur) ?
Serait-ce une bonne idée de partir dans des pays comme la Corée, le Laos, la thailande (bref dans ces coins là).
Quels pays sont moins touchés par cette mentalité hyper matérialiste qui nous ronge de plus en plus ?

Merci pour vos réponses.

PS : Libre à vous de troller sur l'aspect idéologique, amusez-vous bien. Mais ma question est très concrète, et pour tout dire, même en cas de victoire de S.R. je suis attiré par l'idée de partir à l'étranger pour les premières raisons que j'ai exprimé, je cherche donc des informations pratiques.

> Lire le journal (94 commentaires, moyenne: 3,7).

Ce livre vient d'être censuré par l'éditeur MICHALON qui a subi des pressions.
Tombé dans ma boite mail il y a peu

Serge Portelli est membre du syndicat de la magistrature.
Son livre "Ruptures", dressant le bilan de Sarkozy au ministère de l'intérieur, devait être publié par Michalon... qui vient mystérieusement d'y renoncer au dernier moment, empêchant toute publication chez un autre éditeur avant les élections.

Vous le trouverez ici :

http://montaigne2001.free.fr/Serge.Portelli.Ruptures.FRENCH.(...)

Un aperçu du sommaire :

Chapitre premier FAUX BILAN_____________________________________________________________7
Chapitre II LA PRISON COMPULSIVE______________________________________________________18
Chapitre III JUSTICE AUTOMATIQUE______________________________________________________28
Chapitre IV MINEURS DÉLINQUANTS. LE DEBUT DE LA BARBARIE?_________________________36
Chapitre V SIMPLE, INEFFICACE ET DANGEREUX : “TOURNER LA PAGE DE LA RECIDIVE”___47
Chapitre VI LE TRAITEMENT CHIMIQUE, C’EST PAS AUTOMATIQUE_________________________52
Chapitre VII LE NOUVEL ASILE PENITENTIAIRE___________________________________________57
Chapitre VIII LA CHASSE AUX ETRANGERS________________________________________________65
Chapitre IX L’INSTRUMENTALISATION DES VICTIMES_____________________________________72
Chapitre X UNE SOCIETE SOUS TRES HAUTE SURVEILLANCE_______________________________76
Chapitre XI POLICE DE GARDE A VUE_____________________________________________________83
Chapitre XII LA JUSTICE, MAILLON FAIBLE DE LA “CHAINE PENALE”?______________________90
Chapitre XIII LES VRAIES RUPTURES______________________________________________________95
CONCLUSION LES DEUX FRANCES______________________________________________________100

> Lire le journal (26 commentaires, moyenne: 4,7).

On parle peu d'informatique en ces colonnes en ce moment, ainsi me suis-je dis qu'un bon troll du mardi serait peut être sympa.

Comme je ne savais pas de quoi vous parler, je vais vous faire partager ma haine pour ce qui me torture en tant qu'analyste programmeur vulgus de métier : les boucles.

Je pourrai parler d'inculture informatique dans l'industrie (comme un de mes chefs à qui j'ai appris ce qu'est une regexp ou une table de hashage, ou d'un autre qui m'a répondu lorsque je lui parlais de langage fonctionnel "fonctionnel ? qui fonctionne ?" quand je pense qu'ils sont chefs censés codé et effectivement programmeurs...), mais non parlons de boucles.

Au commencement, il y avait ça (merci Lurker) :

10 print i
20 i = i +1
30 if i< MAX then goto 10

Ensuite, comme vous le savez on a eu
for ( i = 0 ; i< MAX ; i++)
printf("%d\n",i);

ensuite on pourra avoir ça
(1..MAX).foreach {
int i;
print i;
}

Puis (là ça devient beau)
(1..MAX).map print

Je passe la programmation par contraintes.

Alors comme j'ai lancé ma dissertation de but en blanc, je parlerai de 2 sous problèmes.

Le premier est la sous formation. A l'image de l'anecdote que je rapportai plus haut pour pleurer en passant sur votre épaule (des fois c'est dur), on forme les informaticiens bac+2/bac+4, voire les ingénieurs à l'impératif, à java, etc...
Comme ce sont des gens pour lesquels la définition d'une fonction soit est flou, soit est une notion philosophique qui ne sert à rien (souvent les deux), ils vont avoir un peu de mal si on leur propose de coder en Lisp ou en Caml.

De plus, ce sont en général des GENS (selon la définition GCU : http://imil.net/wp/lexique/ ) qui ont pour caractéristique de se contenter de ce qu'ils ont et de ne pas rechigner à réécrire 100 fois la même chose, chaque jour.
Le mot généricité est un mot vaguement philosophique pour eux. Ils s'en approchent parfois, quand le client gueule parce que le projet a un mois de retard et reste effroyablement buggé.

Le second est lié aux langages. Ecrire un map, un fold ou un filter(1) en java, est une gageure, en on code beaucoup de chose en javouille.
J'ai trouvé ici ou là des tentatives, mais c'est syntaxiquement affreux. Je réessaierai un jour avec la réflexivité.


Une autre raison de la profusion de boucles-qui-ne-servent-à-rien est l'absence d'une sorte de SQL objet dans le langage (je parle pour les langages objets).
Kro$oft en a sorti un depuis quelques années, ça s'appelle LINQ, et je pense que ça va faire un carton.
Par exemple j'ai Objet1 contenant une liste de Objet2, contenant lui même une liste de Objet3, Objet3 possède un champ toto, une chaîne.

Je veux tous les objets de type Objet3 que Objet1 contient mais, seulement ceux sur lesquels la fonction Quelconque(String quoi), appliqué au champ Objet3.toto, renvoi true :

select Objet3 from Objet1 where Quelconque(Objet1.listeObjet2.listeObjet3.toto)

Bah non, je dois faire trois boucles.

Pareil, j'ai deux liste d'objets représentant la liste du personnel d'une boite à deux dates distrinctes. Je veux les comparer(une appli d'analyse d'évolution de la masse salariale par exemple), faut que je fasses des boucles... Et je vous dis pas comme c'est casse gueule de refaire une clause where avec un "not in" pour un dyscalculique comme moi...

Je pense qu'il nous faudrait un outil pour générer du code à partir d'une requête du genre. Je vous en reparlerai bientôt, car j'ai commencé à travailler sur la question.

Bref je crois que dans notre croisade contre les bugs, et avant qu'on arrive à faire des compilateurs sémantique (ie. des langages axiomatiques turing complet, en d'autres termes ou l'on se contente de décrire ce que l'on veut, comme en sql (voir un trip perso là dessus : http://wiki.loria.fr/wiki/Lisaac/M%C3%A9talangage ))


(1)http://www.zvon.org/other/haskell/Outputprelude/filter_f.htm(...)

> Lire le journal (84 commentaires, moyenne: 2,4).

Le projet Isaac et Benoit Sonntag recherche assez urgement un thésard pour septembre 2007.
Une bourse est proposée avec cette thèse.

Le texte est très vague (normal pour une thèse), mais j'en préciserai les possibilités concrètes plus bas.

Proposition de thèse (Sept. 2007) pour étudiant ayant un Master 2
d'informatique dans lequel il est particulièrement bien classé.

Directeur(s) de Thèse : Philippe Clauss, PR - Benoît Sonntag, MCF

Unité(s) d'Accueil(s) : Laboratoire LSIIT UMR CNRS 7005, Strasbourg,
équipe ICPS

Établissement de rattachement : Université Louis Pasteur, Strasbourg

Requis :
- Interêt pour le projet Isaac/Lisaac (http://isaacos.loria.fr/),
- Très bonne connaissance des concepts objets,
- Bonne connaissance des systèmes d'exploitation,
- Connaissance en Architecture et Assembleur.

Contacts :
sonntag __at __ icps.u-strasbg.fr ou
clauss__at __icps.u-strasbg.fr

Titre : Programmation des couches basses par une approche de haut niveau

Sujet (résumé) :
L'informatique embarquée impose une réutilisabilité croissante du code
existant avec de fortes contraintes matérielles. Néanmoins dans la
pratique, l'équipe de développement doit maîtriser en profondeur ce code
pour l'adapter aux différentes contraintes matérielles. Le code est
essentiellement écrit en C pour des raisons d'efficacité, de portage,
d'intégration avec le système (gestion du matériel). Ici, nous dénonçons
une réutilisabilité peu fiable, parfois hasardeuse d'un code C non
maîtrisé.

Les langages de haut niveau échappent encore à la programmation système.
Le développement des couches basses nécessite un code sensible à
l'architecture matérielle et rend difficile l'application
d'optimisations génériques et automatiques. La fiabilisation des couches
basses du système devient une priorité grandissante dans une
informatique de plus en plus hétéroclite. Une impasse est alors à
combattre: la réutilisabilité et la fiabilisation d'un code sont
grandement facilitées par l'utilisation des langages de haut niveau,
mais leurs utilisations pour les couches basses du système ne sera
possible qu'après une maîtrise des optimisations spécifiques du matériel
avec des performances au moins similaires à un programme écrit en C.
Cette thèse aura pour objectif de sortir de cette impasse en repoussant
les limites des langages de haut niveau pour l'embarqué tout en
garantissant l'efficacité.

Une des possibilités de recherche pour le futur thésard serait un projet passionnant et ambitieux : Certains savent peut être que Lisaac est un langage à contrat, comme Eiffel.
Il existe à l'heure actuelle peu de compilateur permettant de produire du code certifié, et lorsque cela existe, les performances ne sont que rarement au rendez vous.
Il s'agirait donc ici de produire un prouveur de code, qui prendrai les contrats définis dans le code et vérifierai si ces contrats sont respectés par le code écris.L'utilisation de logiciels de preuve comme coq peut être envisagée (1)
C'est une hypothèse parmi d'autres...


Les avantages du projet, permettant de disposer d'un cadre accueillant sont :

-La maîtrise du compilateur :
Lisaac est un compilateur écris par Benoit Sonntag, (dont la prochaine version totalement réécrite va être bientôt publiée), à ce titre le langage est totalement maîtrisé par l'encadrant de thèse, et les modifications nécessaires lors de cette thèse pourront être faites directement dans le compilateur.

- Lisaac est un langage minimaliste construit autour d'environ 10 primitives, en ce sens, il est moins difficile à prouver.
- Analyse de flot. Lisaac est le premier compilateur objet à intègrer de l'analyse de flot, c'est à dire une analyse de toutes les possibilités d'exécutions du code.
- Performances. Lisaac est un compilateur capable d'optimiser son code de sorte à ce qu'il soit aussi rapide (ou presque) qu'un même algorithme écrit en C.
- Lisaac est écrit en Lisaac.


N'hésitez pas à en parler autour de vous.

(1) why de Jean-Christophe Filliâtre est un logiciel qui explore une problématique similaire, dans une sorte de caml, mais il subsiste quelques trous. http://why.lri.fr/index.fr.html

> Lire le journal (16 commentaires, moyenne: 3,4).