Le financement proposé est de 6000$ par étudiant. Une rencontre entre les participants est organisée à la fin de l'été à New-York. Les soumissions doivent être effectuées avant le 15 mars. Entre 5 et 10 projets devraient être acceptés. Ce financement est offert par Jane Street Capital, une société de courtage new-yorkaise qui cherche à s'appuyer sur des technologies de pointe et qui s'implique beaucoup dans la recherche et le développement sur les langages de programmation.
Les projets sont à réaliser individuellement ou en équipe de deux. Une liste de projets est suggérée par les organisateurs, parmi lesquels un éditeur en OCaml, des bindings (liaisons) pour des bibliothèques (il manque toujours un binding Qt pour OCaml !), un résolveur d'équations, des outils de visualisation scientifique, des bibliothèques pour des applications multi-processus, etc.
Objective Caml est un langage multi-paradigme (impératif, fonctionnel, objet) de la famille ML, disposant d'un système de type évolué permettant de réduire considérablement les bogues d'exécution possible. Il est réputé pour sa fiabilité, sa concision, sa rapidité, et la facilité de maintenance des applications.
Aller plus loin
- OCaml Summer Project (17 clics)
- Jane Street Capital (4 clics)
- Objective Caml (8 clics)
- la liste des suggestions (3 clics)
- Caml sur dmoz (3 clics)
- Objective Caml sur Wikipédia (2 clics)
# Tout bon!
Posté par tulipemoutarde . Évalué à 5.
Ca donne une meilleure visibilité à l'Ocaml, montre qu'il est utilisé "dans la vraie vie" et que les entreprises qui l'ont choisi en sont content !
[^] # Re: Tout bon!
Posté par philou (site web personnel) . Évalué à 4.
Quand je vois les concurrents "Python, Ruby, Mono, ..." . Je me dis que les actions de visibilité ne suffiront pas. Python n'a pas besoin d'un "summer project" pour être aujourd'hui incontournable (notamment pour en language de script) .
Ocaml n'est toujours pas compatible GPL. De plus, c'est devenu un langage franco-français, d'universitaire, sans aucune application majeur (peut être mldonkey et encore...).
L'Inria a tout simplement loupé l'opportunité du langage multi-plateforme et haut niveau. Il en faudras encore du temps pour en faire le deuil.
[^] # Re: Tout bon!
Posté par tontonflingueur . Évalué à 4.
Il y a aussi l'excellent Unison http://www.cis.upenn.edu/~bcpierce/unison/docs.html.
[^] # Re: Tout bon!
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Bref, c'est pas le meilleur exemple.
Unison est un super programme mais il lui manque deux choses qui m'empêche dersomais de le déployer : une équipe de développement, une IHM pour le configurer, notament pour la partie Windows.
[^] # Re: Tout bon!
Posté par Jakie Kasperwsky . Évalué à 5.
En quoi Ocaml n'est pas compatible GPL ?
L'inria n'a rien loupé du tout. On utilise rarement un autre language de programmation quand on connaît bien Ocaml. C'est donc à prori une réussite. Après si personne ne veut l'utiliser dans l'industrie, je ne vois pas ce que l'Inria peut y faire. De plus c'est pas leurs problème, ils fournissent un language performant et bien documenté et leur travail s'arrête là. L'inria n'est pas une société de service et n'a pas de marketing à faire. Microsoft délivera bientôt une copie d'Ocaml avec F# qui elle marchera sans doute beaucoup mieux grâce au marketing de MS. C'est donc plutôt la faiblesse de la veille technologique et la peur de prise de risque dans le milieu de l'informatique industrielle qui explique sa faible utilisation en dehors des universités.
[^] # Re: Tout bon!
Posté par Olivier Grisel (site web personnel) . Évalué à 3.
La communauté des développeurs du compilateur OCaml n'a pas su organiser et motiver les contributeurs extérieurs pour faire une bibliothèque standard complète comme c'est le cas dans le monde python (batteries included) + l'index de package cheeseshop ou CPAN dans le monde perl. Résultat, il faut installer des libs externes à la main sans conventions de développement communes et ca ralentit énormement la diffusion du langage aussi bien dans les entreprises que chez les developpeurs independants.
Dans le monde OCaml il y a tout de même l'initiative le systeme de packaging GODI mais il n'est pas mis en avant sur le site officiel. L'INRIA n'a probablement pas vocation a faire du marketing, mais les résultats de ses développement sur Objective Caml gagneraient énormément a être mis en avant par la structuration d'une communauté de contributeurs extérieurs comme c'est le cas des autres langages open source.
[^] # Re: Tout bon!
Posté par MrLapinot (site web personnel) . Évalué à 3.
Et GODI, il pue des chaussettes ? Et ocamlfind, c'est pas une convention pour trouver toutes les libs automatiquement ?
[^] # Re: Tout bon!
Posté par Olivier Grisel (site web personnel) . Évalué à 3.
Le problème du non décollage de OCaml n'est probablement pas technique, le langage est excellent mais culturel : il est très en recul par rapport aux autres langages en terme d'intégration des contributions de la communauté dans le processus de développement.
Mais bon il faut reconnaitre que la situation s'améliore : il ya deux ans, il n'y avait même pas GODI et le site officiel était digne des pages perso du début du web :)
[^] # Re: Tout bon!
Posté par MrLapinot (site web personnel) . Évalué à 1.
[^] # Re: Tout bon!
Posté par gege (site web personnel) . Évalué à 2.
Je ne suis vraiment pas d'accord, l'INRIA pourra faire les plus belles avancées techno possible, c'est a elle d'aller les vendre à l'industrie et de convaincre les industriels. Il faut leur montrer que c'est pas des trucs fumeux de chercheurs sans vraiment de retour sur investissement visible et démontré. Sans cela ça restera dans les cartons de l'INRIA ou au mieux dans un marché de niche après la création d'une start-up sur la techno qui vivotera quelques années...
Je pense que l'INRIA s'en rend de plus en plus compte et c'est tant mieux...
Les entreprises prennent des risques quand elle peuvent les calculer et qu'on vient leur présenter des nouvelles idées bien présentées (avec une vision industrielle) et adaptées à leur besoins (eclipse, python, ...)
C'est avec des réactions comme la tienne que les américains vont encore faire d'une bonne idée française une affaire juteuse pour eux...
[^] # Re: Tout bon!
Posté par Gniarf . Évalué à 2.
> C'est avec des réactions comme la tienne que les américains vont encore faire d'une bonne idée française une affaire juteuse pour eux...
tu peux développer ? je ne vois pas la suite logique, là...
[^] # Re: Tout bon!
Posté par gege (site web personnel) . Évalué à 3.
[^] # Re: Tout bon!
Posté par Gabriel . Évalué à 2.
On ne peut pas faire comme s'il n'y avait aucun rapport entre la Recherche et l'Industrie. Surtout dans le domaine de l'informatique. Dans ce domaine il y a une course à l'innovation entre les différents acteurs. Microsoft, apple, google, sun, hp etc. Tous sont à la pointe de la technologie dans un ou plusieurs secteurs d'activités.
En informatique, l'innovation va de paire avec l'industrialisation.
Il faut des gens et des idées qui vont de l'un à l'autre, que les idées soient concrétisées, que le concret valident les idées.
Autre exemple: regardez Ruby, magnifique langage. Il a connu un grand essor quand:
1- il est sorti de son premier cercle, à savoir son public japonaise.
2- il a été utilisé et validé à plus grande echelle par RoR.
cqfd.
D'autant que c'est un cercle vertueux à construire. Les chercheurs alimentent les gens du secteur informatique, qui donnent des sous aux chercheurs etc.
C'est comme si un écrivain écrivait les meilleurs livres du monde mais ne les publiait pas.
Ou comme une belle fille qui reste à la maison et ne sort jamais. C'est dommage. Elle ne perdra aucune beauté à aller dehors.
Maintenant la question subsidiaire est : qu'est-ce qu'on fait? On s'engueule ou on bosse?
[^] # Re: Tout bon!
Posté par Jakie Kasperwsky . Évalué à 5.
Il n'y a pas de secret, comment c'est developpé F# ? Pour un ancien doctorant de l'INRIA, Alcatel par exemple proposera un travail d'ingenieur là ou MS research, Google, Sun, Cisco proposera 6000 euros net par mois pour faire de la vrai R&D. Pour pallier à ce problème, l'INRIA offre un service de pépinnière d'entreprise qui marche plutôt bien.
[^] # Re: Tout bon!
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Bref, faire un CPAN pour OCaml est tout à fait à la portée de l'INRIA si celle-ci le voulait réellement. Depuis le nombre d'année qu'on le lui dis (idem Scilab, idem Lisaac), je me dis que l'INRIA n'est pas réellement motivé sur ces projets.
C'est son droit mais c'est dommage quand même...
[^] # Re: Tout bon!
Posté par Vivi (site web personnel) . Évalué à 7.
[^] # Re: Tout bon!
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Tout bon!
Posté par dinomasque . Évalué à 4.
~~>[]
BeOS le faisait il y a 20 ans !
[^] # Re: Tout bon!
Posté par gasche . Évalué à 3.
[^] # Re: Tout bon!
Posté par MiniMoi . Évalué à 3.
J'ai l'impression que les utilisateurs d'OCaml aiment la "belle" informatique, c'est-à-dire l'algorithmique sophistquée...
Il est vrai que le langage rend des choses compliquées tellement plpus simples (dès qu'il s'agit de récursivité en particulier) et propres que ceci est logique. Mais d'un autre côté je ne suis pas fan de la syntaxe dès qu'il s'agit de faire des applications "réelles", et je crois que la plupart des programmeurs OCaml n'aimeront pas trop passer des mois sur des projets de bindings...
[^] # Re: Tout bon!
Posté par Anonyme . Évalué à -4.
Alors, oui, je sais, je suis un méchant pas bien qui critique les idées des informaticiens théoriques, mais ceux-ci seraient bien avisés de faire aussi un peu de pratique, histoire d'essayer de montrer que leurs créations ne sont pas du vent (mldonkey pue; unison est pas mal, mais ce n'est qu'une surcouche rsync et/ou ssh, donc bof (et en plus il est très lent, mais bon))
[^] # Re: Tout bon!
Posté par mouftard . Évalué à 2.
Prouve le.
Idem.
C'est pas ce qu'en dit http://www.ffconsultancy.com/free/ray_tracer/comparison.html par exemple.
Ça veut dire quoi, "certaines structures sont absconses" ?
Et merci de ne pas généraliser à tous les langages fonctionnels une spécificité (un défaut ?) d'OCaml, ils ne sont pas tous typés statiquement et tous ne haïssent pas le polymorphisme ad-hoc (cf. typeclasses en Haskell).
De quoi parles tu ? Emacs ? Vim ? Emacs + Caml-mode ? Emacs + Tuareg ? Camlwin (bwahahah) ?
Mais je suis d'accord, il n'y a rien de très évolué... Toutefois ce n'est pas le seul langage ou les libristes se contentent du triptyque éditeur de texte + shell + make.
As-tu essayé Cameleon2 (moi pas) http://gna.org/projects/cameleon/ ?
[^] # Re: Tout bon!
Posté par . . . Évalué à 2.
[^] # Re: Tout bon!
Posté par reno . Évalué à 4.
La syntaxe *par défaut* doit attirer les programmeurs, autrement il ne décollera jamais..
[^] # Re: Tout bon!
Posté par . . . Évalué à 1.
Si l'on regarde sh (posix shell) par exemple, cela n'empêche pas 90% des gens de coder en bash et de s'imaginer faire du shell portable.
Pour le cas de caml, il manque de nombreux exemples pour se mettre au langage, la création de bindings avec c/c++ paraît en particulier beaucoup plus difficile qu'avec python ce qui ne donne pas envie de s'y mettre. Autre exemple, l'absence de support pour les librairies partagées compilées (environnements type unix) limite l'intégration de programmes caml avec d'autres applications.
Pour s'intéresser au language, il faut peut-être commencer à s'intéresser à ce qu'on peut faire avec celui-ci dès aujourd'hui (autres que MLDonkey):
Le solveur d'équations de Kalzium est écrit en caml http://edu.kde.org/kalzium/screenshots.php (basé sur eqchem : http://freehackers.org/~tnagy/eqchem.html), ce composant n'a toujours pas pu être réécrit en c++ malgré les efforts de l'auteur de Kalzium (utilise le solveur de contraintes "Facile" http://www.recherche.enac.fr/opti/facile/)
L'environnement de développement Coq peut permettre de s'ouvrir au domaine des preuves formelles.
Tout n'est pas forcément bon à prendre, mais il y a énormément à apprendre.
[^] # Re: Tout bon!
Posté par reno . Évalué à 1.
>deuxièmement la syntaxe par défaut est probablement le moindre des problèmes.
Et bien dans mon cas personnel, cela a suffit pour me dissuader d'apprendre caml. C'est en parti la syntaxe, en parti l'accent mis sur le coté fonctionnel dans le livre (alors que c'est "vendu" comme étant un langage mixte).
Ceci dit, je ne suis pas totalement réfractaire au fonctionnel: Scala (mélange objet/fonctionnel) me paraît intéressant.
Pour le shell, certes sa syntaxe n'est pas terrible, mais il répond a un besoin auquel les autres langages ne répond pas, c'est pour ça qu'on continue a s'en servir.
Sinon je ne vois pas trop le rapport avec Coq, outil peut-être intéressant, mais vu le jargon obscur utilisé, je n'ai pas eu envie d'apprendre.
[^] # Re: Tout bon!
Posté par Gilles G. . Évalué à 3.
Pour la comparaison avec C, c'est ici:
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
Et pour la comparaison avec Java, c'est ici:
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
Et effectivement OCaml ne s'en sort pas trop mal.
[^] # Re: Tout bon!
Posté par ndesmoul . Évalué à 3.
Attention cependant à ne pas prendre au pied de la lettre ces benchs notamment pour les perfs des langages utilisant une machine virtuelle (avec JIT et autres optimisations à la volée) comme Java et C#. On avait déjà parlé il y a quelques temps ici de cette page.
Certains des bench s'exécutent en quelques secondes, sans prendre en compte ni le temps de démarrage de la machine virtuelle ni les optimisations faites comme la recompilation native du code à la volée. Contrairement à ce qui est prétendu sur le site, si le programme s'exécute en 3s l'impact est important.
Je rajouterai que les compétences exprimées dans chaque langages ne sont pas forcément équivalentes. J'avais jetté un coup d'oeil sur un des programmes Java proposé et j'avais vu des choses qui ne me semblaient pas optimales (genre recopie d'un tableau case par case alors que souvent il vaut mieux faire un arraycopy). Il n'est pas impossible que la même chose puisse être observée avec les autres langages du panel.
Enfin j'ignore si c'est le cas ici mais avec un langage objet haut niveau on va avoir tendance à batir un model objet qui sera plus lisible et plus facilement (ré-)utilisable mais que les compilateurs ont encore du mal à bien optimiser; alors qu'en C ce sera disons plus 'crade', presque illisible mais plus optimisée. (Il y a peut-être une différence de philosophie)
Il n'est pas impossible que l'on obtienne de meilleures performances aux benchs, sur certains langages, en partant de la version C traduite au plus près vers le langage cible.
A contrario un langage de haut niveau rendra peut-être plus facile l'implémentation d'un algorithme optimisée, alors que sera un casse tête en C.
Tout ça pour dire que les benchs, mieux vaut ne pas y accorder une importance démesurée et programmer avec le langage que l'on préfère.
(C'était le dicton du jour...)
[^] # Re: Tout bon!
Posté par neologix . Évalué à 0.
Si d'un côté tu as un mec d'Ulm qui code en OCaml, et de l'autre côté un mec comme moi qui code en C, l'issue est évidente.
Il ne faut pas oublier un truc, c'est que la plupart des gens qui codent en OCaml savent coder, et sont généralement très bons. Ce qui n'est pas le cas avec beaucoup d'autres langages.
[^] # Re: Tout bon!
Posté par Gilles G. . Évalué à 2.
Sinon, lire la première question/réponse de la FAQ (http://shootout.alioth.debian.org/gp4/faq.php )
Il ne faut pas oublier un truc, c'est que les languages permettent d'exprimer de différentes façons différents algorithmes, et que c'est le compilateur qui doit tirer parti de ce qui est exprimé par le language pour effectuer les optimisations. Ces benchmarks donnent une idée du degré d'information contenues dans le langage en vue de l'optimisation des performances.
[^] # Re: Tout bon!
Posté par petitdragon . Évalué à 5.
Pour les perfs, c'est faux. OCaml est réputé pour être très efficace. Moins que C évidemment mais beaucoup plus que Java...
L'histoire des +. c'est le problème que l'on rencontre au premier cours de caml mais quasiment plus jamais après donc bof. On ne va pas juger un langage là-dessus, surtout qu'il y a des raisons à ce choix.
Ton deuxième argument sur les environnements de devt est bon par contre... Il n'y a à peu près rien à part emacs. Le module eclipse ne fonctionne pas bien, cameleon peut-être deviendra un jour bien ? (je n'ai pas essayé récemment).
[^] # Re: Tout bon!
Posté par パパフラクス . Évalué à 2.
Par contre de ce coté, je préfère nettement les classes de types à la Haskell. C'est plus joli (subjectif !), mais surtour ça permet un polymorphisme plus large: je vois ça un peu comme une définition d'interface, qu'on peut utiliser après comme type.
[^] # Re: Tout bon!
Posté par karteum59 . Évalué à 1.
Mais pour tout le reste : (par exemple si je veux faire une classe matrix) je suis obligé de faire des fonctions ad'hoc (matrix_add, matrix_mul, etc.) et on ne peut pas dire que ça aide la lisibilité... OK, c'est pareil en C, mais pas en C++ ni dans tous les langages un tant soi peu modernes !
Maintenant, je peux concevoir que cette contrainte (absence de surcharge des opérateurs / fonctions) provienne du typage automatique et qu'il faille choisir entre les deux fonctionnalités. Mais... est-ce vraiment le cas ? Je veux dire : le compilateur n'est-il vraiment pas capable de regarder le type des arguments d'entrée pour déterminer s'il doit effectuer l'opération '+' pour les entiers, les flottants, les matrices... ?
[^] # Re: Tout bon!
Posté par fmaz fmaz . Évalué à 2.
[^] # Re: Tout bon!
Posté par パパフラクス . Évalué à 2.
Si j'en crois l'idée du poste, l'exmple avec matrice de flottant et matrice d'entier serait plus parlant.
Au passage:
http://en.wikibooks.org/wiki/Haskell/Class_declarations
[^] # Re: Tout bon!
Posté par Gniarf . Évalué à 2.
j'aimerais bien voir ta tête quand tu vas devoir maintenir du code usant et abusant des opérateurs surchargés.
parce que si tu as une jolie fonction matrix_add ou matrix_mul à un endroit dans ton code, tu pourras te douter de ce qui va être appellé. et tu pourras utiliser la recherche textuelle ou autre outil de ton IDE pour voir qui appelle matrix_add dans ton projet.
mais un '+' ou un '*' surchargé, tintin.
[^] # Re: Tout bon!
Posté par MiniMoi . Évalué à 2.
En effet une des grandes force de Caml est que l'algorithme de typage est prouvé, et une fois qu'on voit comment il fonctionne en détail, on comprend le pourquoi du comment...
En plus il faut mettre un bémol à cette non surcharge des opéraeurs : beaucoup de fonctions en Caml sont polymorphes, justement grâce à l'algo d'inférence des types, qui donne des types polymorphes dès qu'il peut (par ex si je parle de la fonction foobar : 'a -> 'b -> 'a je sais qu'elle prend n'importe quel type en premier argument, n'importe quel type en euxième argument et renvoie n'importe quel type, mais le premier, pas le deuxième ;)
[^] # Re: Tout bon!
Posté par reno . Évalué à 1.
Bof, la tête du programmeur, elle n'est pas prouvée elle..
Dans les cas ambigu, je pense qu'il est préférable que l'algorithme d'inférence de type sorte une erreur a la compilation, après tout pour corriger il suffit de rendre explicite le type désiré.
[^] # Re: Tout bon!
Posté par Thomas Douillard . Évalué à 3.
Raison de plus pour qu'il évite de chercher un bug dans le compilo en croyant que la connerie vient de lui, parce que ça peut prendre du temps ces conneries ;)
# Bémol !?
Posté par GuieA_7 (site web personnel) . Évalué à 4.
- Si j'en crois la doc, les threads sont lightweight et n'utilisent donc pas les multi-processeurs. Est-ce exact ?
- Toujours en mattant la doc, le chargement dynamique de bibliothèques ne marche qu'en mode bytecode, et pas en mode natif. Là encore, est-ce que je me trompe ?
Parce que si je ne me trompe pas, ça fait quand même 2 trucs assez indispensables qui manquent. Alors, je suis le 1er à m'extasier sur des conceptions super haut niveau ou des algos élégants et performants, mais pour un langage que certains voudraient voir remplacer le C, je trouve ça très handicapant.
Voilà mon objectif n'est absolument pas de dégouter les gens de OCaml (il y a des tas de langage très nuls mais super utilisés, alors un bon langage sous utilisé je vais pas taper dessus en priorité), mais juste de signaler que faire un langage avec des abstractions super bien foutues c'est bien, mais pour pouvoir remplacer les autres langages, il va quand même falloir pouvoir faire au moins autant que ces derniers.
[^] # Re: Bémol !?
Posté par mouftard . Évalué à 2.
À l'image des implantations actuelles de Ruby ou Python, les threads d'OCaml ne tirent pas partie du multi-coeur : il me semble que c'est lié au glaneur de cellules (GC) et aux difficultés liées à la mise en oeuvre d'une version concurrente de ce dernier.
Pour le chargement de code dynamique, en effet le module http://caml.inria.fr/pub/docs/manual-ocaml/libref/Dynlink.ht(...) ne gère que le chargement de bytecode, et ne peut donc pas ètre utilisé dans un programme compilé vers du code natif.
[^] # Re: Bémol !?
Posté par qpad . Évalué à 2.
Est-ce que ces points sont susceptibles d'évoluer ?
[^] # Re: Bémol !?
Posté par mouftard . Évalué à 2.
En ce qui concerne un éventuel GC concurrent, un fil de discussion relativement récent sur la liste de diffusion dédiée au langage[0] a fourni une réponse intéressante de la part de Damien Doligez, "GC wizard" de la team OCaml :
http://caml.inria.fr/pub/ml-archives/caml-list/2006/09/7fbdc(...)
Il semble que l'obstacle soit plus philosophique que technique tout compte fait (bien que les difficultés d'implantation soient réelles), et que l'équipe attende d'avoir quelque chose de plus propre et élégant que threads et mémoire partagée pour offrir cette possibilité.
Le mail se terminant par "In summary, you shouldn't hold your breath.", ça ne semble pas être pour tout de suite.
<hypothèses>
Il y a d'autres projets liés à la concurrence et la distributivité à l'INRIA, certains assez liés à OCaml, comme JoCaml. Peut-être que l'équipe Gallium attend quelque chose de ce coté, et préfère se concentrer sur d'autres aspects pour l'instant ?
</hypothèse>
[^] # Re: Bémol !?
Posté par Vivi (site web personnel) . Évalué à 2.
Pas tout à fait. Il y a deux implémentations pour les threads: une pour le bytecode avec des threads usermode (lightweight comme tu dis) et une pour le code natif qui utilise les pthreads du système. Mais dans le cas des pthreads il y a un lock global qui assure qu'il n'y a qu'un seul thread caml qui s'exécute à la fois (comme en python).
- Toujours en mattant la doc, le chargement dynamique de bibliothèques ne marche qu'en mode bytecode, et pas en mode natif. Là encore, est-ce que je me trompe ?
En effet. Il y a un patch qui traîne sur le net pour permettre plus ou moins ça il me semble.
Mais bon ces 2 limitations sont là "by design" et ce n'est pas près de changer AMHA. Par exemple le runtime n'est pas concurrent parce que cela permet des allocations mémoire trés rapides et qu'un GC concurrent est beaucoup plus complexe.
Parce que si je ne me trompe pas, ça fait quand même 2 trucs assez indispensables qui manquent.
rien n'est indispensable :) OCaml n'est pas le langage magique qui permet tout facilement et sûrement. Il est mieux adapté pour certaines tâches que pour d'autres. Le cas typique c'est un (assez gros) programme qui fait une tâche bien définie sans avoir besoin de dizaines de bibliothèques, par exemple un compilateur.
Ensuite pour ce qui est de "l'industrie", ça ne change rien, c'est toujours la même question: savoir si le langage est adapté à ce qu'il faut faire. Dans certains domaines ça l'est tout à fait.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.