C'est avec quelques mois de retard que je vous propose un rapide petit compte rendu de la réunion du projet Isaac ayant eu lieu du 25 au 28 juillet 2008 à Strasbourg.
Environ une quinzaine de personnes étaient présente, dont certains habitués de ces pages.
Divers questions y ont été abordé dans la chaleur moite et statique de l'été Strasbourgeois (35 °C, 0 Km/h de vent)
Le programme se trouve ici : http://lisaac.u-strasbg.fr/index.php/R%C3%A9union_25-28_juil(...)
Parmi les points fort, on pourra remarquer la présentation de travaux autour de Lisaac : externalisation des optimisations, Programmation par aspect, une GUI automatique, le fantastique binding OpenGL de Damien Bouvarel, le nouvel Isaac OS. Citons aussi, pour ne pas l'oublier, "Raton Parser" une librairie de mapping mémoire.
Eurent lieu quelques débats théologiques : Quid de la gestion des erreurs, de la compilation de module, de la gestion de la configuration des librairies, choix cornélien entre GIT et Mercurial, etc...
L'externalisation consiste, grâce à un pattern visiteur, de détecter des pattern au sein du graphe de code que traite le compilateur Lisaac, le compilateur travaillant en interne avec un langage minimaliste (une vingtaine d'instruction).
Isaac OS, qui n'avait pas bougé depuis 2003, a été entièrement repris par Jérôme Hilbert et Simon Fuhlaber, Jérôme ayant joué les prolongations pour implémenter le multitâche dans le système.
GUII, par Johnatan Ponté et Maxime Audrin est un très intéressant système d'adaptation automatique de l'organisation de l'interface afin que celle-ci s'adapte à toute résolution : elle construit un arbre abstrait reprenant l'arbre réel des widgets de l'interface et le transforme en arbre concret pour redessiner l'interface. Outre l'aspect de calcul sur l'arbre, ce projet utilise des possibilités uniquement offertes par Lisaac et plus largement le paradigme objet à prototype.
Vous trouverez les slides ici : http://isaacproject.u-strasbg.fr/download/2008Meeting/
Lisaac est encore en cours d'évolution et donne toujours lieu à des réflexions diverses sur le génie logiciel, l'expérience que l'on a accumulé avec d'autres langages, les extensions qu'on aimerait avoir.
Quelques liens pour illustrer les débats ayant eu lieu :
http://lisaac.u-strasbg.fr/index.php/Aspect_programming
Les présentations de Nicolas Boulay rassemblées ici : http://lisaac.u-strasbg.fr/index.php/Pr%C3%A9paration_r%C3%A(...)
Les Fallback de Mildred : http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Fal(...)
Enfin, n'oublions pas l'impressionnant port OpenGL réalisé par Damien Bouvarel (que vous trouverez sur le repo git), qui nous avait déjà gratifié d'un tout aussi impressionnant compilateur Prolog générant du Lisaac.
L'ensemble des présentations présentés durant cette session sont maintenant disponible sur
C'est le débat sur la gestion des erreurs qui m'a le plus marqué, surtout au vu de mes expériences récentes : j'ai été affecté deux mois sur le travail de test d'un énorme logiciel de gestion commerciale, et largement sensibilisé à la vision fonctionnelle du développement logiciel. Du débat que nous avons eu lors de cette réunion, il ressortait, après étude de tous les systèmes de gestion d'erreurs existant, qu'aucun n'était réellement satisfaisant.
Le débat est d'ailleurs né ici même, puisque c'est Nicolas Boulay qui nous a un jour posé la question.
Le système par contrat de Lisaac/Eiffel, est gênant pour son approche "le contrat n'est pas respecté pas donc je crash", mais intéressant dans sa capacité à chercher la cause d'une erreur 20km plus loin.
Le système à exception de Javouille est intéressant dans sa capacité à faire remonter une erreur, à la capter. Le problème est que c'est un système qui peut vite être très mal utilisé, et pour travailler sur des projets de plusieurs millions de lignes en Java/J2EE, même en environnement très contrôlé, cela devient vite très problématique.
Typiquement, Hibernate perd la connexion à la base, il charge des null dans les objets et l'appli part en carafe...
Le errno est intéressant, pas de rupture de contexte, pas de mort du signaleur, mais difficile de savoir d'où ça vient.
Récemment dans mon entreprise, j'ai beaucoup travaillé avec les fonctionnels, et j'espère d'ailleurs continuer sur cette voie qui permet de prendre un recul très intéressant sur la capacité de l'humain de se représenter ce que doit rendre possible un logiciel, quel service doit-il offrir. Les fonctionnels que j'ai rencontré m'ont expliqué que, selon eux, les langages utilisés dans l'industrie étaient conçu pour faire plaisir aux développeur, mais pas "orienté client". En particulier la gestion des erreurs est un énorme problème : le logiciel doit se comporter de diverses manière en cas d'erreur logiciel survenu quelques part, mais pas forcément de façon bloquante : une souscription à un service sur son téléphone portable doit pouvoir marcher même si la base de données est momentanément hors d'usage, ou fournir le service au client, même si la banque n'a pas encore répondu.
Je ne parle même pas des erreurs qui ne remontent pas, ou remontent mal..
C'est pour cela qu'il faudrait se demander si l'invention d'un système d'erreur ne deviendrait pas nécessaire : on pourrait imaginer un système basé sur un moteur de règle, avec un arrière gout Prolog. Cela aurait l'avantage de pouvoir gérer des conjonctions d'erreurs, et au compilateur de déterminer les cas possibles d'interaction pour proposer aux développeurs de prévoir une réponse. Le moteur de règle serait intrinsèquement d'assez haut niveau pour être accessible au fonctionnel, qui pourrait alors faire des choix.
Reste qu'il nous manque un modèle, que nous implanterions alors sûrement dans le langage...
Quelques liens :
http://lisaac.u-strasbg.fr/index.php/Gestion_d%27erreur
http://lisaac.u-strasbg.fr/index.php/Reflexion_de_08/2008
http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Ges(...)
http://mildred817.free.fr/2008/LisaacWorkshop/Slides2008/Ges(...)
Journal Retour sur le Isaac Meeting 2008
20
déc.
2008
# Une note
Posté par Victor . Évalué à 2.
ce projet utilise des possibilités uniquement offertes par Lisaac et plus largement le paradigme objet à prototype.
Juste pour pinailler, mais Lisaac n'est pas le seul à faire de l'objet à prototype :)
Je pense à particulier à Logtalk (http://logtalk.org ) qui bien qu'étant un langage logique (en fait ça tourne au dessus de Prolog) est un langage objet à classe ET prototype (et certainement d'autres trucs cool :).
Sinon, très bonne idée ce résumé je trouve !
[^] # Re: Une note
Posté par Victor . Évalué à 3.
[^] # Re: Une note
Posté par Ontologia (site web personnel) . Évalué à 4.
J'ai pas étudié les autres langages à proto genre IO, et compagnie et donc je sais pas si c'est possible, mais vu qu'ils sont assez proche de smalltalk, c'est pas sur (IO gère l'héritage multiple cela dit).
Le concept dont je parle évasivement consiste en gros à définir un setter dans un objet recevant un objet, et de prendre cet objet comme parent.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Une note
Posté par Octabrain . Évalué à 3.
# Gestion d'erreur ou de bugs ?
Posté par Anonyme . Évalué à 7.
Plus sérieusement, j'ai franchement l'impression que quand on parle de gestion d'erreur ici on parle plutôt du "meilleur système pour que tout parte pas en vrille quand on a un bug".
Or par définition la plupart des softs deviennent complètement imprévisibles en cas de bug, un gestionnaire d'erreur peut aider, mais peu aussi rendre l'application plus opaque (récupération d'erreur qui rétabli l'application, mais dans un état incorrect - il est très difficile de programmer une récupération d'erreur ... sans ajouter de bugs).
Par exemple : une souscription à un service sur son téléphone portable doit pouvoir marcher même si la base de données est momentanément hors d'usage. Ce n'est pas une erreur. Ce n'est pas un bug. C'est une fonctionnalité. Si le truc doit être programmé pour permettre le coup de téléphone même si une partie du système est en vrac, c'est une fonctionnalité, ca peut se faire sans gestion d'erreur. A contrario,
si le truc génère une erreur lorsque la base de données est offline, c'est un bug.
Pas facile a exprimer mais en gros l'idée est que, un gestionnaire d'erreur, aussi bien qu'il soit, n'est pas la pour récupérer les bugs. Des bugs il y en a toujours, des erreurs aussi. La différence c'est que l'on programme la réaction aux erreurs pour les récupérer, des erreurs qui ne sont pas des bugs, des erreurs dont le développeur est conscient.
Donc je trouve ce brainstorming sur la gestion d'erreur très intéressant point de vue architecture, mais il me donne l'impression qu'on espère récupérer les bugs en même temps que les erreurs, alors qu'a mon sens c'est totalement impossible.
[^] # Re: Gestion d'erreur ou de bugs ?
Posté par Victor . Évalué à 3.
"Récuperer" les erreurs (prévues et imprévues, que ce soit des bugs ou des attaques pourquoi pas) est un challenge qui a été posé plusieurs fois ces dernieres années (je l'ai vu dans pas mal de papiers détaillant les challenges liés à l'intelligence ambiante et autre ubiquitous computing).
Je pense qu'il y a des gens qui tentent de le faire (et donc qui croient que ce n'est pas impossible.
[^] # Re: Gestion d'erreur ou de bugs ?
Posté par Antoine . Évalué à 3.
Je vais être méchant, mais écrire try/except (ou try/catch selon votre langage) est un challenge ?
Quant à récupérer une erreur non prévue, c'est un oxymore. Si on arrive à récupérer une erreur c'est qu'on avait prévu l'éventualité de son surgissement. On parle d'une machine de Turing déterministe, pas d'un organisme vivant.
[^] # Re: Gestion d'erreur ou de bugs ?
Posté par Victor . Évalué à 2.
Autant d'un point de vue syntaxique que conceptuel.
On parle d'une machine de Turing déterministe, pas d'un organisme vivant.
On parlait :)
Les systèmes informatique que l'on construit sont de plus en plus complexe, et les partisans de l'émergence (attention, ceci est un buzzword) comme moyen de résoudre des problèmes sont de plus en plus nombreux.
Il y a un moment où dans un système, il y a trop d'entités (distribuées parfois) et fait par trop de personnes différentes pour que l'on puisse tout contrôler.
Ça fait peur aux gens, mais c'est la réalité : on ne peut pas tout contrôler, c'est la vie :)
Bien sûr, ce n'est qu'une vision futuriste de l'informatique, mais c'est à ça que travaillent beaucoup de gens en IA dans la recherche en informatique.
Mot clés : auto-organisation, émergence, système multi-agents, système complexe, ...
# beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 5.
l'impressionnant port OpenGL
Y'a quoi de fantastique et d'impressionnant dans ce port OpenGL ?
Vous semblez critiquez la notion d'exception, pourquoi pas, mais où sont les arguments/raisonnement ?
Une piste alternative ?
la compilation de module
Alors ?
la gestion de la configuration des librairies
Alors ?
[^] # Re: beaucoup de blabla, peu d'info
Posté par Ontologia (site web personnel) . Évalué à 2.
Tu changes pas.
C'est un boulot énorme et de très haut niveau, c'est tout. Il l'aurait fait en java, en erlang, en brainfuck que j'aurai dit la même chose.
Porter OpenGL dans un langage, c'est difficile point.
Une piste alternative ?
Preuve que tu n'as pas lu mon journal jusqu'au bout, je cite :
C'est pour cela qu'il faudrait se demander si l'invention d'un système d'erreur ne deviendrait pas nécessaire : on pourrait imaginer un système basé sur un moteur de règle, avec un arrière gout Prolog. Cela aurait l'avantage de pouvoir gérer des conjonctions d'erreurs, et au compilateur de déterminer les cas possibles d'interaction pour proposer aux développeurs de prévoir une réponse. Le moteur de règle serait intrinsèquement d'assez haut niveau pour être accessible au fonctionnel, qui pourrait alors faire des choix.
Reste qu'il nous manque un modèle, que nous implanterions alors sûrement dans le langage...
C'est juste une piste...
la compilation de module
Alors ?
C'est pas dans les premières priorités.
Je te rappelle, que Lisaac a pour le moment vocation à être un langage de niche, et pas du tout un concurrent de Java.
la gestion de la configuration des librairies
Alors ?
Dispo dans la prochaine version du compilateur, qui devrait sortir au cours du premier semestre 2009
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: beaucoup de blabla, peu d'info
Posté par hocwp (site web personnel) . Évalué à 5.
C'est quelque chose qui s'automatise relativement bien quand même.
Par exemple pour le Common Lisp, ça m'a pas pris environ un mois sur mon temps libre : http://hocwp.free.fr/ah2cl/
[^] # Re: beaucoup de blabla, peu d'info
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: beaucoup de blabla, peu d'info
Posté par hocwp (site web personnel) . Évalué à 3.
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 6.
N'importe quoi. C'est un travail purement technique, sans doute long con et chiant en fonction de la lib à binder, mais je vois pas ce qu'il y a d'impressionnant là dedans. Si c'était si compliqué, y'a longtemps que les API OpenGL auraient été retravaillés pour être bindés plus facilement. Et la très grande majorité des langages ont leurs bindings OpenGL. C'est que c'est pas si compliqué.
Preuve que tu n'as pas lu mon journal jusqu'au bout, je cite :
Bof, tu mets des mots techniques à la suite sans aucune explication, sans aucun raisonnement, et tu ne réponds pas à ma question : quels sont les critiques que vous avez apportez aux exception ? Que faut-il donc changer ? A partir de là on peut étudier les alternatives en regardant ce qu'elles améliorent par rapport à l'existant.
Désolé mais j'ai lu les slides, et ca m'aide pas non plus à comprendre votre critique des exceptions.
C'est pas dans les premières priorités.
Je te rappelle, que Lisaac a pour le moment vocation à être un langage de niche, et pas du tout un concurrent de Java.
Excuse du peu, mais Lisaac se veut un langage pour faire un OS, et les exceptions existent aussi en C# (que certains utilisent pour faire un OS), en C++ (dont l'utilisation dans les OS n'est plus à démontrer).
Donc voilà, je me doute que c'est dans les priorité, mais j'aimerai savoir si vous avez avancé sur le sujet, parcque dans les derniers débats que j'avais eu, la notion de module avait l'air de foutre en l'air la notion d'optimisation global offerte par le compilo...
Dispo dans la prochaine version du compilateur, qui devrait sortir au cours du premier semestre 2009
C'est cool, mais concrêtement ?
Sérieux, tu réponds totalement à côté de la plaque en n'aucune réponse à mes questions : je connais toujours pas les critiques aux exceptions, j'en sais pas plus sur la gestion des modules et de la configuration. Ca sert à quoi de parler de tout ca dans un journal si t'as pas envi d'en parler ?
[^] # Re: beaucoup de blabla, peu d'info
Posté par Victor . Évalué à 1.
Ce sont des pistes pour faire avancer la recherche, pas le résultat du travail d'une équipe d'ingénieurs qui ont un objectif précis et qui possède déjà toutes les solutions au problème posé.
Après peut-être que ça peut être mieux expliqué, j'en sais rien j'ai pas lu le truc, mais c'est peut-être pas nécessaire d'être aussi hargneux alors qu'il prend de son temps pour raconter ce qu'il se passe derrière la scène.
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 4.
Mes questions sont justement là pour essayer d'avoir les infos intéressantes de ce qui s'est dit "derrière la scène". Parcque là on a un enième teaser marketing de Lisaac par Ontologia sans aucun détail qui permettrait de se dire : tiens il est sorti des idées intéressantes de ce rendez-vous, des idées techniques nouvelles, etc.
Désolé d'essayer de trouver un sujet de discussion technique dans ce journal.
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . Évalué à -5.
* Pour les exceptions : c'est des GOTOS, et les GOTOS, c'est mal (inutile de relancer le vieux débat, je suppose. Si t'aimes ça, c'est juste que nous pas... les gouts et les couleurs quoi...). En plus, le principe de rejeter une exception est vraiment ignoble, ça casse le concept de "boite noire" qu'on aime tant avoir en objet. Après il est vrai que la gestion des erreurs fait parti des défis...
* Les exceptions sont utilisées par C# et C++ : ok, et alors ? Lisaac propose un autre moyen de programmer, et les exceptions n'en font pas parties. Si tu aimes ça, restes sur C++ (qui est quand même une surcouche super crade au C ).
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
*c'est cool mais concrètement : wait & see
Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Bonne soirée
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 5.
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?
Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'
Si tu aimes ça, restes sur C++ (qui est quand même une surcouche super crade au C ).
On est d'accord, mais y dit qu'il voit pas le rapport.
Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?
Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains. Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . Évalué à 3.
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?
Certes, mais contrairement aux exceptions, il n'y a pas un décrochement complet du programme. Les exceptions te cassent la séquentialité, le while non.
Alors oui, une machine ce n'est qu'un GOTO(adresse) + écriture/lecture, mais y'a différentes manières de le faire.
* Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'
j'ai adapté le raisonnement à mon principal lecteur (je prends de l'avance sur le coup des chercheurs).
Enfin, si t'as quelque chose de constructif à ajouter sur la gestion des erreurs, on sera ravi de voir ce que c'est. Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?
le "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" peut en fait être remplacé par "arrête de saouler, on cherche".
Si je te dit que c'est un défi à relever c'est que c'est pas encore fait. On le dit pour montrer la direction dans laquelle on va et si ça intéresse des gens, ils peuvent venir donner leur avis. Je ne parle pas de toi qui vient juste dire 'c'est naze" - même si c'est un avis.
*Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille
allons donc, il faut de tout pour faire un monde...
Mais la recherche, c'est pas mal plus intéressant que de continuer a implémenter des trucs bricolés (façon exception). Tu vois, on cherche, pour faire quelque chose de mieux. Toi tu dois bien te "branler la nouille" sur autre chose...
sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains.
J'ai pas dis ça, c'est pour replacer les choses dans leur contexte. Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires. On essaie de faire quelque chose d'innovant et ça prend du temps.
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Sinon, t'as déjà codé en Lisaac ?
parceque si ce n'est pas le cas, je t'invite cordialement à le faire et à remonter les erreurs/bugs. On a toujours besoin de gens de bonnes volontés pour faire avancer un projet.
Bonne soirée
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 3.
Bah oué, en même temps c'est leur objectif : le programme fait face à une situation exceptionnelle et non prévue, et il ne sait pas quoi faire : il lève une exception et casse la séquentialité plutôt que de continuer comme si de rien n'était au risque de faire des conneries.
Ca vaut ce que ca vaut, mais ca me paraît acceptable. T'as un meilleur comportement face à une telle situation ?
Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
Oué mais moi je viens pas poster un journal pour dire "oué nous on va inventer (c'est même pas on va chercher, non, on va inventer) un truc ouachement mieux parcque l'existant il est pourri". Alors pas la peine de renvoyer la balle, je pensais que vous aviez quelque chose d'intéressant à apporter. Je sais pas, peut être élaborer sur ce qui se cache derrière l'utilisation d'un jeu de règles ?
peut en fait être remplacé par "arrête de saouler, on cherche".
Ben j'ai envie de dire, arrêtez de nous saouler avec Lisaac tant que vous avez rien à dire à part nous informer que votre réunion de l'été dernier c'était cool.
Tu vois, on cherche, pour faire quelque chose de mieux.
L'objectif est louable, c'est d'ailleur assez excitant. M'enfin vous avez pas l'air de savoir ce que vous chercher effectivement à résoudre comme problème. Tu dis : les exceptions c'est mal, ca casse la séquentialité. Ok admettons, mais alors commencez par définir à quels critères doit coller un système de gestion idéal des erreurs. Bref, définissez l'objectif. De ce que je dois en déduire, un des critères c'est que les ce système idéal ne doit pas casser la séquentialité. Je propose de discuter de ce critère (cf début de mon post), ca me paraît intéressant.
Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Je suis bien d'accord. C'est pourquoi cela me paraît d'autant plus prétentieux que d'annoncer "nous on fait mieux qu'eux" alors que la comparaison est totalement faussée vu que vous faites abstraction de la plupart des contraintes auxquelles doivent faire face les langages "industriels".
Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
Peut être que c'est pas qu'un jump (GOTO) ?
Faut-il le rappeler, mais les exceptions sont censés être rares et être levées que dans des situations exceptionnelles ? Les perfomances sont-elles donc le critère primordial pour définir un gestionnaire d'erreur ?
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires.
Je dis pas que leurs conception/implémentation est élémentaire, je dis que ce sont des fonctionnalités élémentaires des langages modernes, des fonctions indispensables pour qu'un langage soit utilisable de nos jours. Comme la gestion mémoire, la sécurité, etc. Faire l'impasse dessus lors de la conception d'un langage amène à Lisaac : on se focalise sur les perfs en oubliant le reste, et on se congratule en regardant des benchs. Après on constate qu'il manque des trucs "élémentaires" pour en faire un vrai langage qui puisse espérer sortir d'un labo. On commence par se rassurer en disant : c'est normal, ca répond à un marché de niche (comprendre les utilisateurs qui n'ont pas besoins des choses élémentaires et uniquement des perfs). Ensuite on se dit que la gestion des erreurs c'est pas si mal, même dans l'embarqué, que la modularité c'est pas si mal dès qu'on travaille en équipe, et là on s'apercoit que les perfs "pures" c'est gentil mais ca sert à rien tout seul et que peut être qu'il aurait fallu y penser dès le départ.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Les shootout c'est pas la vrai vie, les shootouts se focalisent uniquement sur les perfs et pas sur les autres choses "élémentaires" qui font qu'un langage est de qualité.
Sinon, t'as déjà codé en Lisaac ?
Quand y'aura tous les trucs de base, oué pourquoi pas.
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . Évalué à 2.
C'est dommage que tu n' aie pas essayer le lisaac, ça t'éviterais de dire des bêtises :
* Le lisaac dispose d'un gestionnaire de mémoire
* Le lisaac propose la programmation par contrat pour le débuggage
(et a plus, long terme, le but est de permettre plus que le simple débuggage, notamment de la preuve de programme)
* Le lisaac a des facilité pour l'écriture de fonction bas niveau, notemment au niveau de l'accès mémoire (mapping de slot directement sur la mémoire)
* Le lisaac est pensé autour de la sécurité des accès : le "public" ne permet que l'appelle et non pas l'écriture (passage obligatoire par des setters)
* Le lisaac proposera dans une future release (mais c'est déjà opérationnel) un système de synchronisation automatique pour le parallélisme - combien d'industriels rêvent d'arrêter de se casser la tête sur les synchronized de java ?
* Le lisaac est 100% objet (mais tu t'en fous)
* Le lisaac permet de l'héritage multiple (mais tu aimes les interfaces java, nan ?)
* Le lisaac permet des choses que peut de langages modernes permettent - réallocation du parent, changement de code dans les fonctions, retour de fonctons avec plusieurs valeurs...
Au vu de l'évolution des systèmes informatique, je suis prêts à parier que les systèmes type multi agents (si tu n'as pas essayer, je te recommande de jeter un oeuil sur JADE pour JAVA - de télécom Italia) vont se répandre de plus en plus. En règle générale, je pense qu'on va vers des systèmes répartis en réseaux. Dans de tels systèmes, la gestion des erreurs prendra une place extrêmement importante - déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein. Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Si tu veux un petit exemple de séquentialité, on peut voir le tout comme un automate. Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur. C'est - basiquement - ce que fait un programmeur C à la main en testant les retours de fonctions critiques (accès systèmes en générales). On pourrait, par exemple, essayer d'automatiser le procéder, rendre la chose plus générique. Avant que tu ne sautes dessus, je te rappelle que c'est un exemple et que autre chose a été proposé dans le journal...
Donc, étant donné que lisaac possède déjà pas mal de "fonctionnalités indispensables dans un langage moderne" je t'invite à le tester.
bonne soirée
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 3.
C'est bien gentil d'avoir de l'héritage multiple ou de pouvoir changer le parent. Mais dans bien des cas, c'est inutile. C'est joli, mais on s'en passe facilement. Par contre, devoir gérer chaque cas exceptionnel à la main, c'est pas super :/
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 3.
Je sais très bien que Lisaac propose la gestion mémoire. Je critiquais seulement l'absence de gestion des modules et de la configuration.
Ces autres qualités que tu décris sont très bien, mais il manque des choses beaucoup plus basiques, c'est ca que je voulais rappeler.
déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein.
Autant de situation complexe qu'il faut effectivement les gérer. Des situations qui deviennent courantes dans les architectures complexes et distribuées... qui font qu'elles ne sont plus exceptionnelles et ne sont donc pas gérées par les exceptions. La gestion de ce type d'erreur doit faire pleinement parti des fonctionnalités du logiciel.
Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Soit les erreurs sont gérés par le code "métier", et dans ce cas elles ne sont pas gérés par les exceptions qui doivent être réservées aux comportements exceptionnels et non prévu. Donc non, leur efficacité n'est pas la priorité (même si c'est toujours mieux).
Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur.
Oué rien à voir avec un comportement exceptionnel donc.
Enfin se pose toujours le problème de la séquentialité : dans certains cas il n'est pas du tout envisageable de continuer l'exécution du programme là où il était rendu (il peut être continué par ailleur sans doute), tu proposes quoi si tu ne veux pas de rupture dans la séquentialité ?
Vous voulez tout faire mieux que tout le monde, et au final y'a rien d'utilisable qui sort. C'est dommage, y'a peut être des concepts intéressant dans Lisaac, mais inexploitable en l'état à toujours vouloir repousser les limites de l'état de l'art.
Quand Ontologia avait commencé à parler de Lisaac, il avait mis en avant les perfs liées aux optimisations globales faites par le compilateur. Pourquoi ne pas partir de cet apport pour essayer de faire un langage"quasi-industriel" ? Ne serais-ce que pour valider que c'est utilisable au quotidien l'optimisation globale. C'est justement là que ca devient intéressant : faire en sorte que ce soit utile pour tout le monde.
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 4.
Pour un langage qui se dit de haut niveau, si :)
Mais je commence à douter que Lisaac soit si haut niveau. En tout cas son code source est très bas niveau :)
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 3.
Oui, et Lisaac manque de plein de fonctionnalités élémentaires :(
désolée de casser le mythe du parfait langage, j'espère que ce sera le cas un jour, mais pas encore.
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 3.
Lisaac n'est pas encore prêt. Et pour ma part, je n'ai jamais prétendu le contraire. Mais je travaille sur ces sujets importants (lorsque j'ai le temps et la possibilité, c'est à dire quand j'ai accès à des sources assez récentes (pas d'il y a deux ans) et qui compilent :)
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 2.
Donc voilà, je me doute que c'est dans les priorité, mais j'aimerai savoir si vous avez avancé sur le sujet, parcque dans les derniers débats que j'avais eu, la notion de module avait l'air de foutre en l'air la notion d'optimisation global offerte par le compilo...
L'aspect OS était ces derniers temps en train de disparaître, même si il se met peu à peu à revivre ...
Pour les modules qui fouttent en l'air l'optimisation globale, c'est vrai. Mais il n'y a pas de solution miracle. Par contre, si l'application est bien développée, les interfaces entres modules seront réduites, ce qui permettra d'optimiser chaque module séparément comme avant, et de ne perdre que peu de performances à l'endroit des interfaces.
C'est mon idée en tout cas. Mais pour le moment il n'y a aucun code de ce coté. Mais c'est prévu: http://mildred817.online.fr/Misc/Computer/Lisaac/Specs/Futur(...)
(note, ce sont mes idées, cela ne sera probablement pas intégré dans Lisaac tel quel)
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 2.
D'où ma question : partant de ce constat, l'optimisation globale est-elle vraiment pertinente au regard du coût qu'elle engendre ? (notamment temps de compilation et mémoire utilisée pendant la compilation)
[^] # Re: beaucoup de blabla, peu d'info
Posté par Ontologia (site web personnel) . Évalué à 2.
Il y a plein de logiciels où il y a ce genre de besoin.
Enfin, l'objectif est de fournir un langage de haut niveau pour la programmation paralèlle sans souçi, l'embarqué, etc...
Ce n'est pas parce Benoit, qui a énormément codé en C, a gardé ses habitudes de coder bas niveau que Lisaac n'est pas haut niveau, il est tout autant que SmallTalk ou Ruby, puisqu'on peut faire la même chose avec.
On peut toujours itérer une collection avec une boucle classique, ou un foreach, le second paraitra plus haut niveau, mais au final, ça génèrera le même code.
Quand aux temps de compilation, ils ne sont pas énorme, et n'ont pas a rougir face aux temps de compilation de GCC, qui sont bien plus importants, ou même Java.
Pour la mémoire, il est vrai que la consommation est importante, mais quand on regarde une compilation de source Lisaac, on se rend compte que GCC consomme autant de mémoire
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 2.
Effectivement, mais faudra toujours faire un compromis entre séparation/module et recherche des perfs.
Enfin, l'objectif est de fournir un langage de haut niveau pour la programmation paralèlle sans souçi
Ca me paraît important ça effectivement. Lisaac apporte quoi pour la programmation parallèle ?
L'algo d'optimisation global cherche-t-il par exemple à paralléliser ce qui peut l'être ? Quels sont les outils à la disposition du programmeur pour guider le compilo dans ce travail ? Quels avantages/apports par rapport à l'existant ?
Pour la mémoire, il est vrai que la consommation est importante, mais quand on regarde une compilation de source Lisaac, on se rend compte que GCC consomme autant de mémoire
Bon bah c'est cool, c'est que ca a bougé depuis les dernières stats que t'avais donné (qui faisaient peur).
[^] # Re: beaucoup de blabla, peu d'info
Posté par Ontologia (site web personnel) . Évalué à 4.
C'est la vie ça, des compromis :-)
On a tout de même pas mal de logiciels où la partie calcul peut être mis dans un coin, les jeux par exemple, ou souvent la partie 3D/physique est codée en C++, mise dans des DLL à part, et la partie IA codé dans des langages style python. C'est le cas pour la série des civilisations il me semble.
C'est expliqué ici http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-(...) page 17
Il explique qu'on autant de ligne de code pour la partie "scripting" que pour la partie "numeric computation", mais que la première ne consomme que 10% des ressources.
Il y a beaucoup de cas comme ça.
Ca me paraît important ça effectivement. Lisaac apporte quoi pour la programmation parallèle ?
L'algo d'optimisation global cherche-t-il par exemple à paralléliser ce qui peut l'être ? Quels sont les outils à la disposition du programmeur pour guider le compilo dans ce travail ? Quels avantages/apports par rapport à l'existant ?
Lisaac propose le modèle COP (Concurent Object programming).
Tu définis ton objet en tant que parallelisable, et chaque appel non bloquant (ie, ne retournant pas de valeurs) est exécuté en parallèle. Le compilateur te garanti la gestion des synchronize, qui est transparente pour toi.
Pour la détection de parallèlisme, on y a pensé, mais ça nécessite de trouver un thésard pour travailler dessus. On pense aussi au parralèlisme spéculatif, reprenant le concept de prédiction de branchement.
Mais c'est pareil, c'est encore un travail de thèse.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 3.
Vi vi je suis d'accord, cependant quid de l'intégration avec tout ce qui touche à l'accélération 3D, les shaders, les décodeurs H264 toussa ?
Non parcque de manière générale, notamment pour les jeux, dès qu'un truc est consommateur de calcul, ce travail est délégué à un composant dédié à ce type de traitement.
Le CPU reste la solution de secours "générique".
Tu définis ton objet en tant que parallelisable, et chaque appel non bloquant (ie, ne retournant pas de valeurs) est exécuté en parallèle. Le compilateur te garanti la gestion des synchronize, qui est transparente pour toi.
Tu peux montrer un exemple, ca semble intéressant.
[^] # Re: beaucoup de blabla, peu d'info
Posté par Ontologia (site web personnel) . Évalué à 3.
Non parcque de manière générale, notamment pour les jeux, dès qu'un truc est consommateur de calcul, ce travail est délégué à un composant dédié à ce type de traitement.
Le CPU reste la solution de secours "générique".
C'est pour ça qu'il faudra que le compilateur soit capable de générer du shading language, OpenCL. C'est un peu de travail, mais ça ne devrait pas être insurmontable, à condition évidemment, qu'on se restreigne à lui demander du calcul pur.
Le système présenté pendant la réunion, de pattern visiteur pour les optimisation du compilateur sert précisément à ça : son rôle sera de détecter les formes de graphes dans le code qui pourront être confiée à un GPU, et de générer un appel vers la fonction OpenCL qui va bien.
Tu peux montrer un exemple, ca semble intéressant.
On va définir deux objets fictifs maitre et un objet calcul.
Section Header
+ name := MAITRE;
Section Inherit
- parent_object:OBJECT := OBJECT;
Section Public
- main <-
(
+ calcul1, calcul2, calcul3 : CALCUL;
calcul1 := CALCUL.create;
calcul2 := CALCUL.create;
calcul3 := CALCUL.create;
calcul1.exec 1;
calcul2.exec 2;
calcul3.exec 3;
// donne lieu a 3 thread à exécution simultanée
);
Section Header
- name := CALCUL;
Section Inherit
- parent_object:OBJECT := OBJECT;
Section Public
- exec i : INTEGER <-
(
// Code du calcul
);
C'est le fait de mettre - à la place de + devant le name du prototype CALCUL qui fait que l'exécution de ses méthodes devient parallèle.
Par contre, si tu utilise une autre méthode renvoyant un résultat et créant une dépendance, le compilateur va évidemment sérialiser.
Le modèle te garantit que tes synchonise sont effectués correctement, tu n'as rien d'autre à faire que de mettre + ou - devant le name de ton objet pour dire s'il doit y avoir parallèlisme ou pas.
Il me semble aussi que si tu fais :
1.to 10 do { i : INTEGER;
ma_collection.add_last (calcul.exec i)
};
ça parallèlise aussi
Tout est expliqué dans le manuel de la 0.3, page 97
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . Évalué à 2.
Quid de l'implémentation ? Une surcouche des threads natifs de l'OS sous jacent ? Une gestion interne ? Autre ?
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: beaucoup de blabla, peu d'info
Posté par Mildred (site web personnel) . Évalué à 2.
Perso, je n'ai rien contre, c'est plus Benoît, l'inventeur du langage qui ne les aime pas. Il me semble que le problème c'est que cela cause une rupture de flot (un peu comme les goto, les break, continue et return qui n'existent pas en Lisaac). Cette rupture de flot pose un problème il semblerait au niveau de la preuve des programmes par les contrats.
Mais je ne peux pas en dire plus, je n'en sais rien en fait.
[^] # Re: beaucoup de blabla, peu d'info
Posté par 2PetitsVerres . Évalué à 0.
Ah il a oublié les if aussi.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: beaucoup de blabla, peu d'info
Posté par Ontologia (site web personnel) . Évalué à 5.
Dans le langage utilisé en interne par le compilateur pour l'analyse de flot, tu as : le test, read, write, loop, plus quelques primitives comme la soustraction, la division, la porte et, etc...
Tu les trouveras dans le répertoire "codelife" du code source du compilateur.
break et continue sont des ruptures de flot car ils ne sont pas représentables avec les primitives ainsi définies. De même pour les exceptions.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
"Menaces
* Aussi évoluées les fonctionnalités du langage soient-elles, elles pourront tout à fait se retrouver dans un autre langage."
C'est quoi cet esprit à l'opposé total de l'esprit des logiciels libres ?
Si une idée est bonne, il faut la diffuser pour que tout le monde en profite. La phrase ci-dessus laisse surtout entendre que le but c'est que ce soit Lisaac qui en bénéficie et pas les autres langages... Vous pouvez expliquer vos motivations ?
[^] # Re: ca fou les boules
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
Sérieusement, ici on est sur linuxfr, l'esprit est à l'ouverture et au partage de l'information et du savoir. Vos guéguerres inter-techno ou vos ressentiments anti-MS on s'en tape, ce qu'on veut c'est de nouvelles techniques, de nouveaux algos, utilisables dans les logiciels libres.
[^] # Re: ca fou les boules
Posté par Ontologia (site web personnel) . Évalué à 2.
Ms est l'ennemi du libre, et le partage de l'information doit prendre en compte la possibilité de donner des armes à notre ennemi.
Désolé, mais je suis un anti-ms très très primaire.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: ca fou les boules
Posté par Ontologia (site web personnel) . Évalué à 2.
Par contre, si la techno reste longtemps confidentielle et qu'il la repère, là c'est la cata.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
En gros vous refusez pertinemment de partager de l'information. Vous avez peut être de bonnes raisons professionnelles, mais ici c'est LinuxFR, et ça va être dur de vous justifier...
[^] # Re: ca fou les boules
Posté par Mildred (site web personnel) . Évalué à 3.
On à besoin de se justifier ?
Personnellement, je préfèrerais que le projet soit plus ouvert ... mais c'est déjà une évolution par rapport à avant où il n'était même pas libre.
Il faut aussi comprendre que Lisaac, cela représente vraiment tout pour Benoît qui en est à l'origine. Il à fait un travail fantastique sur certains points (même si le langage n'est pas encore prêt), ce serait injuste je pense que le projet ne marche pas.
De plus, Lisaac est la base de ses travaus de recherche. Souvent il implémente une fonctionnalité avant d'avoir rédigé le papier correspondant. Ce serait injuste que quelqu'un d'autre reprenne son travail pour publier un papier à sa place alors que c'est lui qui l'a implémenté.
Certes, ce n'est pas très ouvert, mais le monde n'est pas un monde parfait. Il faut malhereusement se protéger un peu si on veut pouvoir y survivre. Finalement, je trouve que c'est le bon choix car j'ai l'impression que peu de chercheurs produisent vraiment du code utile comme ça.
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
Y'a 2 solutions :
- soit le le "prototype" (Lisaac) devient industriel, et en soit c'est réussite par le concrêt.
- soit le prototype est mal adapté au contexte industriel (parcqu'il ne répond à aucun besoin et/ou a trop d'inconvénients), mais il peut en sortir des idées à adapter à d'autres langages industriels.
Dans les 2 cas c'est utile pour l'informatique, et le chercheur peut estimer que son travail est accompli. Mais la réussite de Lisaac n'est pas une finalité en soit. C'est plus une question d'égo et de personnes à mon sens que d'intérêt public.
Ce serait injuste que quelqu'un d'autre reprenne son travail pour publier un papier à sa place alors que c'est lui qui l'a implémenté.
Et ? c'est quoi la finalité ? Satisfaire son égo en ayant son nom publié en bas d'un papier ou participer à l'évolution de l'informatique en faisant adopter des idées ?
Il faut malhereusement se protéger un peu si on veut pouvoir y survivre.
Bien sûr, votre problématique est avant tout professionnelle : recherche, budget, compétition, publication, poste, etc.
Mais j'ai envie de dire dans ce cas, venez pas discuter de Lisaac sur LinuxFR si au final vous avez rien à dire dessus parcque-faut-proteger-les-chercheurs. Les logiciels libres ne sont peut être pas adapté à votre contexte métier, et LinuxFR est peut être pas l'endroit idéal pour promouvoir votre techno.
En tout cas de manière général, la culture du secret a toujours été décriée dans la philosophie des logiciels libres. Ici nous croyons que la façon de distribuer un logiciel joue un rôle plus important dans son adoption que dans une politique de contrôle/divulgation au compte goutte d'information.
Je vois pas trop ce que vous espérez avec Lisaac : vous n'avez clairement pas les moyens de faire un langage "industriel". Donc en soit c'est un projet uniquement destiné à être un prototype de laboratoire sans autre avenir que de l'étriper pour y extraire les bonnes idées et les mettre ailleurs.
Y'a une autre possibilité : profiter des "ressources" de la communauté des logiciels libres pour tenter de rendre le projet utilisable et utilisé. Pourtant vous n'avez pas choisi non plus cette voie. Bon courage !
[^] # Re: ca fou les boules
Posté par Ontologia (site web personnel) . Évalué à 0.
Quand à TA vision de LinuxFr, je te rappelle que j'ai fais ce journal pour parler du pattern visiteur pour les optimisations, de la GUII (GUI s'adaptant automatiquement à la taille de l'écran), etc.. toutes choses dont on aime discuter et sont des projets intéressants en eux même. Merci de ne pas chercher la petite bête parce que le fanboy de Microsoft que tu es n'est pas content qu'on veuille pas faire de la R&D gratuite pour eux.
Quand à la recherche, eh oui, le monde n'est pas parfait, dans la recherche il faut publier, c'est comme ça. C'est comme ça que tu acquiers plus de moyens, de liberté, d'opportunité pour créer une équipe de recherche sur ton projet de recherche.
Et dans le monde de la recherche, il y a des types assez immoraux pour voler sans vergogne les travaux des autres. Si tout le monde était respecteux, on pourrait parler de COP, et crois bien que j'en serais le premier ravi.
Te faire le chantre de la philosophie du libre, toi le suporter de Mono, le cheval de troie de MS, ça me fait penser à Fabius qui se fait le chantre de l'extrême gauche, c'est un peu fort de café.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 1.
c'est la R&D pour l'informatique. Microsoft ou autre. Ca profite à tout le monde. On a pas la même conception du partage du savoir.
je te rappelle que j'ai fais ce journal pour parler du pattern visiteur pour les optimisations, de la GUII (GUI s'adaptant automatiquement à la taille de l'écran), etc..
Mais bon sang vas-y donnes des infos techniques ! Parcque dis comme ca, ca n'a rien d'excitant ou nouveau, ca existe déjà ces mots collés à la suite !
Merci de ne pas chercher la petite bête parce que le fanboy de Microsoft que tu es n'est pas content qu'on veuille pas faire de la R&D gratuite pour eux.
C'est moi où vous faites une fixation sur Microsoft ? Je parles de logiciels libres. Les logiciels libres prennent le risque de donner des idées à tout le monde parcqu'ils offrent des libertés à tout le monde, y compris Microsoft, sans disctinction aucune. Si vous adhérez pas à cette idée de logiciel libre, que venez vous faire sur LinuxFR ?!?
il y a des types assez immoraux pour voler sans vergogne les travaux des autres.
Voilà on y vient. Vous avez une toute autre philosophie du savoir et de la façon dont il doit être diffusé et partagé. Vos problématiques c'est pas le partage, c'est la rétention d'information, la recherche du profit personnel (et profesionnel), la recherche de reconnaissance, bref, rien à voir avec la philosophie du libre. Franchement allez voir ailleur : quand j'entend ces propos de "vol de travaux", j'ai l'impression d'entendre Pascal Nègre se pleindre du vol de la piraterie sur internet.
Si tout le monde était respecteux, on pourrait parler de COP, et crois bien que j'en serais le premier ravi.
C'est pas une question de respect, c'est une question d'objectif. Votre objectif c'est la reconnaissance, vous voulez que ce soit votre nom, votre techno, votre langage qui porte tel ou tel "invention".
Pourquoi vous tournez autour du pot ? Retournez à vos labos et assumez votre façon de penser : brevetez à tous va vos idées. Vos directeur de labo seront heureux, vous "protégerez" vos "inventions" du vol, et vous serez heureux !
Te faire le chantre de la philosophie du libre, toi le suporter de Mono, le cheval de troie de MS
Mono, c'est une alternative libre à un truc proprio de MS, comme Linux est une alternative libre à Unix. T'as quelque chose contre Gnash ? Samba ? Wine ? GnuClasspath ? OpenOffice.org ? Autant d'alternative à des technos proprios (où qui l'étaient)...
[^] # Re: ca fou les boules
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est moi où vous faites une fixation sur Microsoft ? Je parles de logiciels libres. Les logiciels libres prennent le risque de donner des idées à tout le monde parcqu'ils offrent des libertés à tout le monde, y compris Microsoft, sans disctinction aucune. Si vous adhérez pas à cette idée de logiciel libre, que venez vous faire sur LinuxFR ?!?
Microsoft est l'ennemi du libre, le libre doit savoir se défendre contre ceux qui cherchent à le détruire, comme la démocratie doit savoir se défendre contre ceux qui veulent sa disparition (les néolibéraux à l'heure actuelle).
Je pense que tu es un des rares sur LinuxFr à aimer Ms.
Mais bon sang vas-y donnes des infos techniques ! Parcque dis comme ca, ca n'a rien d'excitant ou nouveau, ca existe déjà ces mots collés à la suite !
C'est hallucinant un aveuglement pareil ! Tu as un journal, là, plus haut, avec des liens, donnant sur des pdf, des slides, le wiki rempli d'articles, etc...
Le rapport de TER (car c'est un mémoire de maîtrise, tout de même) t'explique ce que les étudiants ont fait sur 16 pages, ce sont des mots collés à la suite, peut être ?
La vingtaine d'articles de Nicolas ne sont pas techniques peut être ?
Les slides sur les différents projet que j'ai cité ne contiennent que du vent ?
Tu les as lu ? Tu sais lire ?
C'est moi où vous faites une fixation sur Microsoft ? Je parles de logiciels libres. Les logiciels libres prennent le risque de donner des idées à tout le monde parcqu'ils offrent des libertés à tout le monde, y compris Microsoft, sans disctinction aucune. Si vous adhérez pas à cette idée de logiciel libre, que venez vous faire sur LinuxFR ?!?
Donner des armes à MS, c'est donner à MS un moyen de nous priver de notre liberté, ce qu'ils feront, et donc de priver tout le monde de liberté.
Néanmoins Lisaac contient d'ors et déjà plein de techniques qui les intéresseraient, ils peuvent déjà se servir.
Voilà on y vient. Vous avez une toute autre philosophie du savoir et de la façon dont il doit être diffusé et partagé. Vos problématiques c'est pas le partage, c'est la rétention d'information, la recherche du profit personnel (et profesionnel), la recherche de reconnaissance, bref, rien à voir avec la philosophie du libre. Franchement allez voir ailleur : quand j'entend ces propos de "vol de travaux", j'ai l'impression d'entendre Pascal Nègre se pleindre du vol de la piraterie sur internet.
Et toi tu es pret à perdre ton boulot pour les beaux yeux d'un connard qui ne manquera te poignarder dans le dos ou pour avoir une belle conscience éthique éthérée d'avoir diffusé tes travaux 6 mois avant ?
Si Benoit ne publie pas, il perd son boulot.
Ses travaux seront publiés, mais on doit attendre qu'ils le soient pour en parler afin d'éviter qu'on lui les volent c'est tout.
Mono, c'est une alternative libre à un truc proprio de MS, comme Linux est une alternative libre à Unix. T'as quelque chose contre Gnash ? Samba ? Wine ? GnuClasspath ? OpenOffice.org ? Autant d'alternative à des technos proprios (où qui l'étaient)...
Mono est à la traine de Microsoft comme ça a été prouvé ici même, et c'est une arme stratégique pour Microsoft. Wine n'est pas stratégique du tout, Samba permet de faire concurrence à MS, OpenOffice supporte ODF donc il n'y a pas plus de problème, et GnuClasspath réimplémente un produit libéré depuis quelques temps. C'est totalement différent.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 3.
\o/ Alors parcque MS c'est les méchants, on respecte pas la philosophie d'ouverture et de partage promulguée par les logiciels libres pour préserver les logiciels libres ??? Ton raisonnement est complètement tordu.
Je pense que tu es un des rares sur LinuxFr à aimer Ms.
J'aime pas spécialement MS. Je suis pragmatique : quand une techno me plaît, je regarde pas son initiateur, je regarde si je peux l'utiliser avec des logiciels libres qui m'offrent suffisament de garantie en terme d'indépendance.
C'est hallucinant un aveuglement pareil ! Tu as un journal, là, plus haut, avec des liens, donnant sur des pdf, des slides, le wiki rempli d'articles, etc...
Ben, j'ai cliqué sur tous les liens, je vois kedal sur GUII. Désolé mais le wiki il ressemble à rien, ca ressemble plus à un fourre-tout bordélique.
Les slides sur les différents projet que j'ai cité ne contiennent que du vent ?
Ben c'est des slides, pas de la doc, sans le discours associé c'est inutile et quasiment vide d'information.
Tu les as lu ? Tu sais lire ?
Ben vas-y, explique !
Donner des armes à MS, c'est donner à MS un moyen de nous priver de notre liberté, ce qu'ils feront, et donc de priver tout le monde de liberté.
\o/ Quel est le rapport avec MS tu m'expliques ? Si la connaissance que vous apportez est intéressante, elle apportera à tout le monde, à commencer aux logiciels libres. Que cela profite aux firmes que t'aime pas est un effet de bord, mais tu ne peux pas prétendre d'un côté être un supporter des libertés et de l'autre vouloir limiter ceux qui en bénificie en voulant utiliser une discrimination basée sur une conception archaïque des gentils et des méchants.
Dans tous les cas, tes propos sont la définition même du FUD : tu cherches à semer le doute et faire peur sur des choses hypothétiques qui se passerait dans le futur.
Néanmoins Lisaac contient d'ors et déjà plein de techniques qui les intéresseraient, ils peuvent déjà se servir.
Bah bas-y, prouve ton FUD, c'est où le pompage par MS des supers-technos de Lisaac ?
Et toi tu es pret à perdre ton boulot pour les beaux yeux d'un connard qui ne manquera te poignarder dans le dos ou pour avoir une belle conscience éthique éthérée d'avoir diffusé tes travaux 6 mois avant ?
Pour mon boulot, je me fais une raison : gagner de la thune est pas forcement compatible avec les logiciels libres. Mais moi je viens pas faire la promotion de ce que je développe au boulot sur LinuxFR, parcque j'estime que c'est hors sujet.
Je ne continuerai pas à parler de ton troll sur Mono qui est sans intérêt dans cette discussion à part te permettre de te défouler.
Par contre si t'as envie de parler techno, vas-y te gène pas. Si une fois encore, faut rien dire, faut tout garder secret, ben remballe ton Lisaac et tes slides, je m'en tapes.
[^] # Re: ca fou les boules
Posté par Victor . Évalué à 2.
Ben, j'ai cliqué sur tous les liens, je vois kedal sur GUII. Désolé mais le wiki il ressemble à rien, ca ressemble plus à un fourre-tout bordélique.
Il ne faut pas perdre de vue que les chercheurs il ont pas le temps de faire de la communication.
si tu es mécontent de ça, dis le à ton (notre) gouvernement pour qu'il mette plus de moyen dans la recherche et dans l'accompagnement de la recherche.
Bien sûr que les chercheurs seraient heureux de faire de belles pages qui expliquent leurs trucs au commun des mortels, mais ils peuvent pas, parce qu'en plus de devoir publier pour survivre, ils doivent s'occuper de préparer des cours, corriger des interros, perdre du temps à monter 50 projets pour avoir une pauvre bourse de thèse, gérer l'administratif des cursus qu'ils encadrent, etc...
(Après, ça dépend peut-être, lisaac c'est peut-être dans une structure où on ne donne pas de cours, j'en sais rien, mais j'en doute :)
C'est pas si simple que ça, on dit du mal sur le publique, mais les mecs là-bas ils foutent pas rien hein !
Ben c'est des slides, pas de la doc, sans le discours associé c'est inutile et quasiment vide d'information.
Bah attend les publications.
Ça se fait pas en 10mn une publi, une doc, c'est un long travail qui demande un temps que les gens n'ont pas forcement, et le problème, c'est toujours le même : les moyens.
Pour mon boulot, je me fais une raison : gagner de la thune est pas forcement compatible avec les logiciels libres. Mais moi je viens pas faire la promotion de ce que je développe au boulot sur LinuxFR, parcque j'estime que c'est hors sujet.
Il y a des gens que ça interesse, et j'en fais partie :)
Pour moi c'est suffisant pour en faire un journal :)
Sinon, d'une manière générale, tu n'as pas tort, il manque quelque chose en communication, mais c'est pas la bonne personne à qui le dire, envoi un courrier au ministère de la l'enseignement supérieur et de la recherche plutôt.
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
Juste que je vois pas l'intérêt de venir faire de l'évangélisme technologique sur LinuxFR. Vous cherchez quoi ? A faire mousser votre techno auprès de geeks libristes ? Dans ce cas faut leur donner à manger de la doc, des tutos, etc. Et surtout pas venir leur dire "désolé on peut rien vous dire parcque sinon Benoît va perdre son taf".
Voilà quoi, à chaque fois que ca parle Lisaac c'est frustrant : ceux qui en parlent ont pas l'air de maîtriser la techno (ca se fini toujours par "faut demander à Benoît), la doc est plus que light. Du coup le sentiment général qui en ressort, c'est un projet qui semble éloigné du libre (dans l'esprit de transparence qui en ressort), ambitieux (on va réinventer tous les concepts), voir prétentieux (car au final on voit rien venir).
Au final ca va se finir comme les 3/4 des projets de recherche français : trop d'ambition par rapports aux moyens, et trop de prétention par rapport aux résultats obtenus.
[^] # Re: ca fou les boules
Posté par Ontologia (site web personnel) . Évalué à 2.
Je confirme, de janvier à juin, Benoit sera occupé à plein temps avec ses cours, ses étudiants préparant leur mémoire de maitrise (pardon master 1), sans compter un stage de DEA (pardon master 2) à encadrer.
Et quand il aura le temps de souffler, il faudra qu'il travaille sur ses publis.
Et nous autres (Nicolas, Mildred, Xavier, moi-même, etc...) avons un métier, une vie, bref nous n'avons pas forcément le temps...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
Tiens bah t'as qu'à voir Mono comme l'exemple que Microsoft fait de la R&D gratuite pour le libre :-p
Et franchement puisque votre bête noir c'est Microsoft, eux sont beaucoup plus ouvert et offrent beaucoup plus de documents techniques à manger aux geeks que nous sommes dans leurs projets de R&D. Je prends pour exemple Singularity. Eux ont pas peur de parler techno comme vous. Eux ont pas peur qu'on leur pique des idées.
[^] # Re: ca fou les boules
Posté par Mildred (site web personnel) . Évalué à 2.
Qu'est ce que tu peux bien avoir contre Mono, c'est un logiciel libre. Il permet d'utiliser des langages super bien, super facilement. Le seul reproche que je peux faire c'est l'inexistence de la documentation sur dbus-sharp :/
[^] # Re: ca fou les boules
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
- Mono est la traîne de MS donc, tout projet mono tourne sous .NET mais pas l'inverse.
- Les api de .NET sont brevetées, toutes applications mono est a risque juridique envers MS. MS peut attaquer en justice n'importe quel auteur d'application si il change les termes des licences de leurs brevets. MS dispose donc d'une arme contre toute application mono que quel soit, si un jour l'une d'elle fait de l'ombre à ses produits.
En utilisant Mono, on devient dépendant de MS et on place sois même sa tête sur le billot.
"La première sécurité est la liberté"
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 3.
La plupart des applications mono... ne tournent pas sous .NET. Pourquoi ? Parcque Mono n'est pas "à la traîne". Mono propose de nombreux API qui ne sont pas disponibles sous .NET (le plus souvent spécifiques à Linux/Gnome). Inversement, .NET propose des API non supportés par Mono (parcque trop spécifique Windows ou pas implémentés).
Les api de .NET sont brevetées, toutes applications mono est a risque juridique envers MS.
Combien de fois va-t-il falloir le répéter :
- les API concernés ne sont pas "nécessaires" pour faire une appli avec Mono telle que F-Spot ou Banshee.
- MS n'a jamais montré la moindre velléité envers Mono, au contraire.
- MS détiens des brevets sur des tas d'autres techno "libres", mais bizzarement les libristes s'attachent avant tout à faire l'inventaire de ce qui tourne autour de Mono, va comprendre.
- Novell détiens des brevets clés sur .NET
- Mono est protégé par l'OIN (IBM, Sony, Sun, etc.)
Arrête le FUD à 2 balles, le risque des brevets est pas plus grand avec Mono qu'avec n'importe quelle autre techno.
[^] # Re: ca fou les boules
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Au contraire, il existe des brevets précis sur les API de .NET détenu par MS. MS détient peu de brevet au contraire de IBM mais ils sont connu pour être un peu moins tendre avec le libre...
"La première sécurité est la liberté"
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
C'est bien ce que je dis : quand il s'agit de mono, les libristes deviennent des spécialistes juridiques prêt à en découdre avec la liste des brevets pour aller y chercher ce qu'ils veulent, mais dès que ca concerne les autres logiciels, on crie juste au FUD.
Pourtant IBM a publié une liste de brevets plus que conséquente qu'il mettait librement à disposition de la communauté open-source, l'OIN qui regroupe Novell IBM Sun et Sony vise à rassembler tout plein de brevets pour "protéger" Linux (le kernel et mono entre autre) contre des attaques.
Faut vraiment être d'une mauvaise totale pour prétendre que MS n'a aucun brevets "utilisés" dans le monde du libre alors que toutes ces autres sociétés en ont.
Oui, MS FUD en menacant sans donner d'exemple concrêt, mais tu remarqueras que RedHat & Co n'ont jamais contredis ce FUD. Tout le monde est d'accord pour dire que le danger est réel, même si personne n'a de liste exhaustive (c'est bien le problème).
Mais Mono est protégé de la même manière que l'est le kernel Linux par l'OIN, donc cessons le FUD de merde contre Mono.
[^] # Re: ca fou les boules
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Bien sûr qu'ils l'ont fait ! Il y a beaucoup de demande pour qu'il montre les brevets et le code en question. Il y a même eu un site dédié au sujet.
"La première sécurité est la liberté"
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
Et tant qu'on y est, explique moi pourquoi la FSF sponsorise un projet GNU visant des objectifs proches de Mono (dotGNU) si c'est pour que ses utilisateurs se retrouvent pieds et poings liés avec MS.
[^] # Re: ca fou les boules
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 2.
dotGNU vise à implémenter ce qui est spécifié à l'ECMA/ISO, comme Mono. Donc y dit qu'il voit le rapport. Comme je l'ai déjà dis, cette pile + la pile d'API Gnome offerte par Mono est largement suffisante pour la majorité des applications Linux.
De plus dotGNU, comme Mono, vise également à implémenter des API pas standardisés comme les WinForms pour permettre à des utilisateurs d'applications uniquement Windows de changer d'OS pour utiliser un OS libre (au pif : Linux), en quoi est-ce mauvais pour l'utilisateur ? C'est la même politique qui a guidé le projet GNU depuis le début.
[^] # Re: ca fou les boules
Posté par Mildred (site web personnel) . Évalué à 2.
Ah ? Pourquoi n'aurait-on pas les moyens de rendre Lisaac utilisable comme langage "industriel" (je suppose que tu parles ici des nombreux manques dont j'ai déjà parlé). Le problème c'est que pour le moment, j'ai l'impression d'être la seule personne dans l'équipe à avoir conscience de ces problèmes (peut être pas, mais c'est mon impression). Ce n'est pas je pense un manque de moyens.
Étriper le langage est une possibilité, mais je ne pense pas que ce soit la bonne. Cela voudrait dire que les qualités de Lisaac seraient séparés ... alors que je pense que c'est justement leur réunion qui donne toute sa qualité au langage.
Y'a une autre possibilité : profiter des "ressources" de la communauté des logiciels libres pour tenter de rendre le projet utilisable et utilisé. Pourtant vous n'avez pas choisi non plus cette voie. Bon courage !
C'est en partie la voie choisie (rappel: le compilateur n'était pas libre avant). Le problème c'est que Benoît n'est pas encore sûr de son choix. Mais le compilateur est libre (y compris la dernière version même si elle n'est pas publiée encore. Mais elle le sera, sans aucun doute).
Ce qui m'étonne c'est qu'à la libération du langage, j'ai été la seule personne à participer au projet. Tout était libre, mais pas grand monde de la comunauté n'est venu.
Alors, quand tu laisse entandre que Lisaac tourne le dos à cette comunauté, laisse moi être en profond désacord avec toi. Seulement, il faut comprendre qu'une libération de logiciel ne se fait pas aussi simplement. Il y a toujours une période de transition (qui dans ce cas est particulièrement longue, je pense par manque d'interêt de la comunauté justement).
Cependant, je m'engage (dans la limite de mes possibilités, toujours) à faire de Lisaac un langage moderne et utilisable au quotidien, comme n'importe quel autre langage. Et libre.
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . Évalué à 3.
Parcque vous êtes suffisament prétentieux pour croire tout refaire en mieux mais avec des moyens (financiers) dérisoires.
Le problème c'est que pour le moment, j'ai l'impression d'être la seule personne dans l'équipe à avoir conscience de ces problèmes (peut être pas, mais c'est mon impression). Ce n'est pas je pense un manque de moyens.
C'est encore pire alors : manque de moyen, et manque de vision. Vous croyez qu'on peut concevoir un langage "de labo" et qu'il sera ensuite trivial de le rendre industriel. Alors qu'un bon langage industriel doit être conçu pour cela. Est ce que l'on transforme une formule1 en Megane ? Non. Est-ce que les 2 sont comparables ? Non.
Mais le compilateur est libre
La licence ne fait pas tout.
Tout était libre, mais pas grand monde de la comunauté n'est venu.
Parcque ce n'était pas attractif : pas industriel donc pas utilisable, de la doc plus que light, de trop grosses lacunes pour y voir un intérêt à l'utiliser, etc.
Alors, quand tu laisse entandre que Lisaac tourne le dos à cette comunauté, laisse moi être en profond désacord avec toi.
Je veux bien croire que toi tu y crois. Mais visiblement cela n'a pas l'air d'être le cas de tout le monde dans votre équipe. Quand je vois plus haut les débats "philosophique" sur le partage du savoir, ca en dit long sur les limites de votre ouverture au libre.
Cependant, je m'engage (dans la limite de mes possibilités, toujours) à faire de Lisaac un langage moderne et utilisable au quotidien, comme n'importe quel autre langage. Et libre.
Faudrait concevoir le bouzin en conséquence... Enfin bon courage, l'objectif est louable.
[^] # Re: ca fou les boules
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
toi être débile donc moi expliquer à toi avec mot et grammaire simple.
Lisaac être libre.
Lisaac est développé par un jeune chercheur CNRS. La raison de vivre d'un chercheur est la publication. Sans publication, plus de chercheur. La publication prend du temps. D'autres chercheurs, dans le même cas, peuvent "voler" des idées pour les publier en premier.
Donc, Benoit, le chercheur, a choisi d'écrire ses articles avant de publier ses dernières fonctionnalités.
C'est quand même moins contraignant que toutes les boites qui font une version light GPL et fermé pour le reste !
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.