Ici, à Vandoeuvre-lès-nancy, on a fait une kbirthday party à la résidence du Galilée. On a mangé trois kroques-monsieurs chacun, on hésite à attaker les m&m's. N'empêche c'est trop la fête.
Antoine est un des pricipaux contributeurs de TOM, bien plus que moi :)
Ontologia est un contributeur important de Lissac : http://linuxfr.org/2005/11/29/19970.html si je ne me trompe pas.
L'article (et non le livre) auquel le texte peu informatif en anglais fait référence se trouve en ligne et le texte en question contient un lien http (en haut à droite) qui pointe dessus: http://www.cs.uu.nl/~visser/ftp/eosp.ps
Désolé pour le lien en anglais mais personne n'a encore écrit en français sur la question à première vue. Quant à ne pas pointer l'article directement mais une entrée dans "program-transformation.org", on a pensé qu'une courte description du pattern repousserait moins de gens que la lecture d'un long article, disponible pour les plus intéressés.
Justement, lors de la sortie de qt4, trolltech a annoncé que qt designer était maintenant architecturé de manière telle qu'on peut facilement l'intégrer dans un IDE.
je ne vois pas trop ce qu'on reproche à la syntaxe d'ocaml si ce n'est qu'elle est différente de celle des langages de la famille C (syntaxiquement parlant). Je trouve au contraire que l'inférence de type a tendance à "épurer" le code. Et l'approche fonctionnelle du langage fait que la définition d'une fonction ressemble vraiment à la manière dont on les défnit mathématiquement.
Je pense que la plupart des gens se disant rebutés par la syntaxe d'ocaml sont en fait déroutés par leur premier contact avec un langage fonctionnel.
Pour faire le lien avec une technologie connue, c'est comme du XSLT sauf qu'au lieu de réécrire des arbres XML on réécrit n'importe quelle structure de donnée, y compris les structures du langage hôte (par exemple, on peut réaliser un mapping de java XML dom vers tom et réécrire des arbres DOM).
Un exemple d'utilisation réaliste est la section 3 du tutoriel ou on réécrit toutes les occurences de "if not a then b else c" en "if a then c else b" partout dans l'arbre abstrait d'un programme : on voit donc les applications pour les compilateurs.
c'est presque vrai sauf qu'il y a des infios que les langages haut niveau comme lissac ou caml, ou eiffel, ou même c++ (pas java par exemple) sont capable de fournir :
si je veux faire une liste chaînée "générique" en C par exemple j'écris :
Maintenant en eiffel/c++ j'écrirai une liste chaînée réellement générique:
template class linked_list ...
et je l'instancie avec linked_list par exemple. (dans le cas de caml, le type est inféré, caractéristique qui semble avoir été mise de côté dans les débats ci-dessus mais peut-être que les personnes qui ont un peu vite vomi sur le langage n'en ont même pas pris conscience). Et là, même si du code C est généré par le compilo eiffel/c++/caml, il sera plus efficace parce que le compilo aura un vrai type à la place de void* et poura faire des optimisations sachant par exemple que le champ value ne pourra pas pointer sur linked_list.
Le typage (qui comme par hasard est fort en caml) apporte donc des infos nécessaires à l'optimisation en plus de fournir une abstraction du programme assez proche du langage pour qu'une bonne partie des erreurs de programmation soit détectées à la compil.
la denière fois qu'on a regardé scala, les choses un peu funky en pattern matching avaient été désactivées ... sinon pour ce qui est du partage maximal de la mémoire ils ont carrément repompé ce qu'on a fait.
Scala est sympa mais pour l'instant ça part un peu dans tous les sens, ce qu'on propose avec tom est centré sur la réécriture mais on le fait (déjà :)), on le fait bien (résultats certifiés par coq et zenon, donc il y a une vraie sémantique) et on fournit tout un framework qui va avec :
signatures algébriques, partage maximal de la mémoire, définition de stratégies, possibilité d'ajouter des backends, etc.
Enfin, voila, pour le peu que j ai vu des projets de l INRIA, ca reste assez decevant. A par en prepa / université, je vois pas ou ils sont utilisés tous ces langages.
Je ne pense pas que le but de l'INRIA soit de fournir le nouveau langage utilisé en prépa... et d'ailleurs c'est déjà fait puisqu'ils utilisent caml.
Les langages qui sortent de l'INRIA sont souvents enseignés au départ dans l'université à laquelle le langage est rattaché, puis dans d'autres au gré de l'utilisation de ses langages par les équipes/thésards qui l'utilisent. SmartEiffel est enseignés dans bon nombre d'universités, et même à l'étranger par exemple.
Mais je crois que le but d'un labo de recherche dans le domaine des langages informatiques, c'est de mettre le doigt sur un nouveau paradigme de programmation, même si ce n'est pas la première implantation de la chose qui sera retenue. De ce point de vue, TOM sort un peu des chemins battus puisqu'il propose un langage dont on pense qu'il peut vraiment apporter un plus tout de suite à l'industrie. Ca ne l'empêche pas d'introduire des notions intéressantes en recherche comme les ilôts formels, ou la combinsaison de stratégies... d'ailleurs puisqu'on en parle la sortie de TOM peut être certifiée à chaque compilation à l'aide des prouveurs coq et zenon.
Si la seule chose qui te gêne est le caractère %, tu peux toujours modifier le lexer du compilo et le recompiler, ça marche.
Par contre, plus sérieusement, la prochaine version de TOM proposera certainement des "frontends" adaptés à chaque langage, ce qui nous permettra d'éviter de demander de fournir le type d'une variable dans la construction %match(Type var) en java par exemple. Ca nous permettra d'être plus proche de la syntaxe du langage hôte, par exemple:
def pred(n):
match Nat n:
suc(x):
return x
zero():
return zero()
par exemple en python...remarque que pour le python on a besoin au contraire du java du type algébrique puisque TOM est compilé et que le type de n n'est connu qu'à l'exécution.
Pour l'instant, le choix de faire un préprocesseur qui ne dépende pas du tout du langage, à part dans la toute dernière étape de génération du code, nous a permis de porter TOM très rapidement vers d'autres langages.
- Caml light n'est plus maintenu depuis 2002 et n'existe quà des fins éducatiives dans les prépas. Je ne connais pas bien cette version de Caml, mais une liste s'écrit [1;2;3...] chez moi. Un ide c'est un ide...utilise le mode tuareg d'emacs :)
- ocaml a énormément d'applications dans la recherche (en fait là où je bosse les gens qui n'utilisent pas TOM utilisent ça :) ). Il a aussi des applications industrielles mais elles sont moindres. Quand aux performances (http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...) , le compilo est plutôt réputé pour celles-ci.
- mldonkey est un peu tout pourri mais si on évalue la qualité d'un llangage à ses applications, alors le C, C++ et java sont très très loins derrière :)
Pour ceux qui voudraient compiler le svn, penser à placer la variable d'envorinnement "LANG" à la valeur "C", parce que le script de construction récupère le numéro de version du programme avec la commande svn info et cherche la ligne qui commence par "Revision" et non "Révision" comme c'est le cas en français.
C'est complètement absurde ces remarques.
Je travaille au LORIA qui est une unité de recherche de l'INRIA en partie. La grande majorité des programmes des équipes est sous une licence libre, les autres sont très accessibles en général.
Le labo organise des conférences/séminaires régulièrement, publie les résultats des chercheurs (c'est d'ailleurs leur principale motivation : publier les résultats).
Maintenant il faut comprendre qu'une grosse partie des _recherches_ des équipes de l'INRIA est avant tout fondamentale, leur but n'est pas de pondre 1000 lignes de codes par jour, ni de participer à l'élaboration d'un OS ou je ne sais quoi comme certaines personnes du MIT le font, à moins que cela ne représente un intérêt pour la recherche.
j'ai pas l'impression que le logiciel libre soit boudé par le LORIA. Mais ce n'est que la partie emmergée de l'iceberg : http://www.loria.fr/researchers/equipes
la liste des publications sur le site de chaque équipe reflète le véritable travail, et ça c'est public.
l'INRIA regroupe plusieurs unités de recherches, il faut donc aller chercher sur les pages des labos et non pas sur le site de l'INRIA lui même.
[^] # Re: Il fallait oser, il font surtout parler d'eux.
Posté par _ . En réponse à la dépêche Mark Shuttleworth invite les développeurs OpenSUSE à rejoindre Ubuntu et suscite la polémique. Évalué à 2.
[^] # Re: à vandoeuvre
Posté par _ . En réponse au journal KDE fête ses 10 ans !. Évalué à 10.
http://img515.imageshack.us/img515/345/pa140005bv1.jpg
Avec les kroques
http://img165.imageshack.us/img165/2752/pa140007ig7.jpg
En kolour vision !!!
http://img142.imageshack.us/img142/2433/kpaintnp9.jpg
# à vandoeuvre
Posté par _ . En réponse au journal KDE fête ses 10 ans !. Évalué à 10.
Ramenez vos kuls.
[^] # Re: Putain, les mecs...
Posté par _ . En réponse à la dépêche Sortie du langage de programmation Tom 2.4. Évalué à 1.
Ontologia est un contributeur important de Lissac : http://linuxfr.org/2005/11/29/19970.html si je ne me trompe pas.
[^] # Re: La dépêche précédente
Posté par _ . En réponse à la dépêche Sortie du langage de programmation Tom 2.4. Évalué à 3.
Désolé pour le lien en anglais mais personne n'a encore écrit en français sur la question à première vue. Quant à ne pas pointer l'article directement mais une entrée dans "program-transformation.org", on a pensé qu'une courte description du pattern repousserait moins de gens que la lecture d'un long article, disponible pour les plus intéressés.
[^] # Re: Designer ?
Posté par _ . En réponse à la dépêche QIde, un IDE pour Qt4. Évalué à 4.
[^] # Re: Scenario
Posté par _ . En réponse à la dépêche Diffusion du film d'animation 3D libre "Elephants Dream". Évalué à 2.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 3.
[^] # Re: l'INRIA ne soutient pas suffisamment OCaml
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 4.
Je pense que la plupart des gens se disant rebutés par la syntaxe d'ocaml sont en fait déroutés par leur premier contact avec un langage fonctionnel.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
[^] # Re: Hem
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 3.
[^] # Re: Hem
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 3.
Pour faire le lien avec une technologie connue, c'est comme du XSLT sauf qu'au lieu de réécrire des arbres XML on réécrit n'importe quelle structure de donnée, y compris les structures du langage hôte (par exemple, on peut réaliser un mapping de java XML dom vers tom et réécrire des arbres DOM).
Un exemple d'utilisation réaliste est la section 3 du tutoriel ou on réécrit toutes les occurences de "if not a then b else c" en "if a then c else b" partout dans l'arbre abstrait d'un programme : on voit donc les applications pour les compilateurs.
[^] # Re: Inutile
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 1.
il fallait lire
linked_list< T >
et
linked_list< toto >
[^] # Re: Inutile
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 4.
si je veux faire une liste chaînée "générique" en C par exemple j'écris :
struct linked_list {
void* value;
struct linked_list* next;
};
c'est le choix notemment de la glib.
Maintenant en eiffel/c++ j'écrirai une liste chaînée réellement générique:
template class linked_list ...
et je l'instancie avec linked_list par exemple. (dans le cas de caml, le type est inféré, caractéristique qui semble avoir été mise de côté dans les débats ci-dessus mais peut-être que les personnes qui ont un peu vite vomi sur le langage n'en ont même pas pris conscience). Et là, même si du code C est généré par le compilo eiffel/c++/caml, il sera plus efficace parce que le compilo aura un vrai type à la place de void* et poura faire des optimisations sachant par exemple que le champ value ne pourra pas pointer sur linked_list.
Le typage (qui comme par hasard est fort en caml) apporte donc des infos nécessaires à l'optimisation en plus de fournir une abstraction du programme assez proche du langage pour qu'une bonne partie des erreurs de programmation soit détectées à la compil.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
Scala est sympa mais pour l'instant ça part un peu dans tous les sens, ce qu'on propose avec tom est centré sur la réécriture mais on le fait (déjà :)), on le fait bien (résultats certifiés par coq et zenon, donc il y a une vraie sémantique) et on fournit tout un framework qui va avec :
signatures algébriques, partage maximal de la mémoire, définition de stratégies, possibilité d'ajouter des backends, etc.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
Je ne pense pas que le but de l'INRIA soit de fournir le nouveau langage utilisé en prépa... et d'ailleurs c'est déjà fait puisqu'ils utilisent caml.
Les langages qui sortent de l'INRIA sont souvents enseignés au départ dans l'université à laquelle le langage est rattaché, puis dans d'autres au gré de l'utilisation de ses langages par les équipes/thésards qui l'utilisent. SmartEiffel est enseignés dans bon nombre d'universités, et même à l'étranger par exemple.
Mais je crois que le but d'un labo de recherche dans le domaine des langages informatiques, c'est de mettre le doigt sur un nouveau paradigme de programmation, même si ce n'est pas la première implantation de la chose qui sera retenue. De ce point de vue, TOM sort un peu des chemins battus puisqu'il propose un langage dont on pense qu'il peut vraiment apporter un plus tout de suite à l'industrie. Ca ne l'empêche pas d'introduire des notions intéressantes en recherche comme les ilôts formels, ou la combinsaison de stratégies... d'ailleurs puisqu'on en parle la sortie de TOM peut être certifiée à chaque compilation à l'aide des prouveurs coq et zenon.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 2.
Par contre, plus sérieusement, la prochaine version de TOM proposera certainement des "frontends" adaptés à chaque langage, ce qui nous permettra d'éviter de demander de fournir le type d'une variable dans la construction %match(Type var) en java par exemple. Ca nous permettra d'être plus proche de la syntaxe du langage hôte, par exemple:
def pred(n):
match Nat n:
suc(x):
return x
zero():
return zero()
par exemple en python...remarque que pour le python on a besoin au contraire du java du type algébrique puisque TOM est compilé et que le type de n n'est connu qu'à l'exécution.
Pour l'instant, le choix de faire un préprocesseur qui ne dépende pas du tout du langage, à part dans la toute dernière étape de génération du code, nous a permis de porter TOM très rapidement vers d'autres langages.
[^] # Re: Et beh...
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 5.
- Caml light n'est plus maintenu depuis 2002 et n'existe quà des fins éducatiives dans les prépas. Je ne connais pas bien cette version de Caml, mais une liste s'écrit [1;2;3...] chez moi. Un ide c'est un ide...utilise le mode tuareg d'emacs :)
- ocaml a énormément d'applications dans la recherche (en fait là où je bosse les gens qui n'utilisent pas TOM utilisent ça :) ). Il a aussi des applications industrielles mais elles sont moindres. Quand aux performances (http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...) , le compilo est plutôt réputé pour celles-ci.
- mldonkey est un peu tout pourri mais si on évalue la qualité d'un llangage à ses applications, alors le C, C++ et java sont très très loins derrière :)
# typo
Posté par _ . En réponse à la dépêche Sortie de TOM 2.3. Évalué à 4.
[^] # Re: Ca bouge dans le monde du libre
Posté par _ . En réponse à la dépêche Sortie de Glest 2.0. Évalué à -1.
oui
J'en ai pas
oui !
oui
Tout ca pour dire que ton raisonnement est faux parce que la réalisation graphique n'a pas d'importance partout.
[^] # Re: Interface Python
Posté par _ . En réponse à la dépêche Sortie de GREYCstoration 2.3. Évalué à 6.
http://www.boost.org/libs/python/doc/
"mais" c'est du c++
# compilation
Posté par _ . En réponse à la dépêche GtkRadiant passe en GPL. Évalué à 10.
[^] # Re: Ha ha ha
Posté par _ . En réponse à la dépêche Disparition de M. Gilles KAHN, Président de l'INRIA, membre de l'Académie des Sciences. Évalué à 10.
Je travaille au LORIA qui est une unité de recherche de l'INRIA en partie. La grande majorité des programmes des équipes est sous une licence libre, les autres sont très accessibles en général.
Le labo organise des conférences/séminaires régulièrement, publie les résultats des chercheurs (c'est d'ailleurs leur principale motivation : publier les résultats).
Maintenant il faut comprendre qu'une grosse partie des _recherches_ des équipes de l'INRIA est avant tout fondamentale, leur but n'est pas de pondre 1000 lignes de codes par jour, ni de participer à l'élaboration d'un OS ou je ne sais quoi comme certaines personnes du MIT le font, à moins que cela ne représente un intérêt pour la recherche.
pour info : http://www.loria.fr/software/tous/?license=all&search_st(...)
j'ai pas l'impression que le logiciel libre soit boudé par le LORIA. Mais ce n'est que la partie emmergée de l'iceberg :
http://www.loria.fr/researchers/equipes
la liste des publications sur le site de chaque équipe reflète le véritable travail, et ça c'est public.
l'INRIA regroupe plusieurs unités de recherches, il faut donc aller chercher sur les pages des labos et non pas sur le site de l'INRIA lui même.
[^] # Re: Evangéliser...
Posté par _ . En réponse à la dépêche Jabber explose !. Évalué à 9.
à commencer par le port de la barbe...