Je ne critique pas les journaux qui ont fait valoir le point 1, mais l'imbécile qui a dessiné Mahomet avec une mèche.
Malheuresement, ces caricatures sont en face (le monde musulmans, et surtout certains partis politiques) utilisée pour supprimer le point 1 (la liberté d'expression) sous reserve "diplomatique" du point 2 (caricatures stupides).
Ca tombe bien : c'est pil poil ce que les dessinateurs danois voulaient démontrer.
Je pense que tu as psychologiquement raison si tu penses à l'élite dirigeantes des pays protestataire qui profite de cet évèvenment (dont ils n'ont cure eux-même) pour assoir leur légitimité. Comme le disait Ignatio Ramonet sur inter tout à l'heure, pour beaucoup de musulmans, l'occident c'est Abou Graib, pour beaucoup d'occidentaux, les musulman c'est Ben Laden. Il parlait là des masses peu informées.
Je crois que les masses (manipulées) manifestantes se fichent un peu des arguties savantes sur la bonne mesure de la liberté d'expression et voient un blasphème, la goutte qui fait déborder le vase.
Va vraiment falloir qu'on organise des échanges culturel moyen-orient/europe parce que sinon ça va péter. Mais c'est sans doute trop tard....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Effectivement, je craint aussi qu'il y ait quelques problèmes car d'après ce qu'il expliquait, cela nécessitait tout de même une carte graphique "assez" récente (je suppose supérieur en nveau à une Gforce 2 peut être).
Mais les effets sont assez conséquent aussi.
Par contre je me demande si au passage la Xlib va enfin devenir asynchrone....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai posé, haleine retenue, la question au démonstrateur de Novell. Celui-ci m'a expliqué, que bien entendu, le code était totalement GPL, écrit par des salariés de Novell.
Je lui demande "Si je comprend bien, dans environ 9 mois, je suis quasiment sûr de retrouver ça dans ma distrib, quelle qu'elle soit ?"
Il me répond "Si vous avez de bon driver pour votre carte 3D, tout à fait".
C'est pour le moment une version beta, et ce sera bientôt accessible à tous quand ce sera au point.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'ai regardé celle de Java, effectivement c'est très intéressant de voir jusqu'où on peut aller en utilisant un support graphique seul.
Je pense que toute pédagogie soit s'adapter, non seulement à la psychologie cognitive de son récepteur, mais aussi chercher à lui demander le moins de réflexions, d'effort possible pour comprendre. s'approprier les concepts. Ce qui n'est pas antinomique avec une activité et un questionnement intelectuel. Il s'agit juste de la phase d'appropriation des concepts.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Effectivement il ya un différence fondamentale entre le libéralisme et le néolibéralisme.
Le libéralisme, en gros et pour faire très court, est une philosophie politique qui présuppose que le marché est le meilleur moyen de réguler la société. Les libéraux classiques, comme Adam Smith, le créateur pensent que l'Etat doit garantir la Loi (et que celle-ci sont souveraine : un Etat de droit), garantir la sécurité des citoyens ET, pour beaucoup de penseur libéraux, corriger les effets négatifs du marché. Adam Smith expliquait déjà à la fin du XVIIIème que la correction étatique était nécessaire pour des domaines comme la culture car la "pauvreté de l'eprit marchand" aboutirait à son anéantissement.
A l'époque du Keynesianisme triomphant (1935-1975), les néolibéraux, farouches adversaires du Keynesianisme développèrent une idéologie stipulant que l'Etat ne doit absolument pas intervenir dans l'économie (car sous la coupe des "groupes de pression"), ne doit pas toucher au droit du travail, des flux de capitaux, etc...
C'est ce que l'on appelle l'école "Monétariste". Le lien qui me fait office de signature contient un série d'emmisions consacré à expliquer l'émergence de cette idéologie.
Le néolibéralisme a été soutenu par les milieux financier qui, dès le début, donnèrent des moyens à son développement idéologique et à son audience.
Ils ont sciemment utilisé la technique qui s'est mis en place naturellement pour l'invasion d'UNIX sur le marché : On s'occupe de formater les étudiants, de les convaincre, comptant sur eux pour diffuser l'idéologie.
J'ai un jour posé la question à Jean-François Khan de définir cette différence entre le libéralisme et néolibéralisme et si sa non reconnaissance dans la discussion politique française.
Il m'a répondu que le néolibéralisme était au libéralisme ce que le stalinisme était à la social-démocratie.
Cette idéologie, je le pense et je l'affirme, mènera à la destruction de notre civilisation. Elle veut organiser la précarité dans la vie de tous, la domination totale et absolue d'une classe dirigeante possédante, elle veut détruire la démocratie qui la dérange et l'empêche d'exploiter les êtres humains.
Cette idéologie abouti déjà, dans certains secteurs, à des monopoles privé, à la conurrence fiscale, à la précarisation généralisé, à la mise sous conditions de guerre entre les hommes.
En France, les néolibéraux patentés sont très souvent d'anciens activiste d'extreme droite dans leur jeunesse. Patrick Devedjian, Gloasgen, Madelin, Novelli, etc... Tous ces députés UMP qui derrière Sarko, brulent de tuer l'Etat et brule de virer Chirac qui, pour une fois visionnaire, leur dit souvent (ce qui est absolument insuportable à leur oreilles)
"Le libéralisme finira comme le Marxisme"
Le néolibéralisme est une idéologie très proche du marxisme-stalinisme , la première comptant de nombreux transfuge de la seconde.
Il faut que l'opinion comprenne cette distinction, c'est fondamental
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pense depuis quelques temps qu'il est indispensable, pour mieux "évangéliser" l'utilisation d'un outil techniquement difficile d'accès, de beaucoup travailler à la forme du message, de l'explication.
Le proberbe "Un dessin vaut mieux qu'un long discours" est et sera toujours valable. Regarder une vidéo, un peu humoristique qui plus est, sera toujours plus efficace pédagogiquement que d'imposer une documentation lourde, très formelle et ardue.
C'est une question de psychologie cognitive : regarder une vidéo où un schéma nécessite beaucoup mois d'énergie à l'étudiant que de mener un long processus mental dans lequel celui-ci va se reconstruire une représentation personnelle d'un concept à partir d'une formalisation potentiellement très éloigné de sa façon de se représenter les choses.
Lire est surement beaucoup plus fatiguant que de regarder une vidéo, ou d'écouter...
Mais cela dépend aussi de l'auditoire, certains sont plus à l'aise avec un livre, d'autres préfèrent un cours.
Il y a des gens auditifs, d'autres visuels. Certains sont plutôt déductifs, d'autres inductifs...
L'internet d'aujourd'hui permet de diffuser en ligne des vidéo, de l'audio, etc... On peut maginer (ça se fait déjà) des cours/conférences en ligne, pour expliquer pas mal d'idées simple à comprendre en fait.
En tout cas félicitation à ce labo de Standford, c'est sympa et très clair, le but étant de faire comprendre le concept de pointeur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Devant la puissance de l'argumentation j'ai mis le temps...
A la réflexion, moi qui défend constamment la nécessité méthodologique d'intégrer les deux approches (ascendantes et descendantes), je suis en train de tomber dans le travers en privilégiant une approche asendante pour lesquelles j'ai d'ailleurs toujours eu un faible.
N'ayant pas eu à mettre au point de gros projets dans l'industrie, n'ayant qu'une connaissance théorique d'UML, j'avoue avoir du mal à définir les problématiques.
Je pense que tu serais plus à même d'emmetre quelques idées à ce sujet. Je serai ravi de créer un petit projet visant à relever un ensemble de problématiques et de tenter de trouver des solutions.
Il serait intéressant de tenter de rêver :
- C'est à dire de définir un formalisme permettant de définir avec moins de difficultés qu'UML, avec plus d'intuitivité sans perdre de vue l'exactitude. Je veux dire "plus d'intuitivité" par la définition d'un formalisme qui nécessite moins de se plier au formalisme objet classique, de "faire rentrer un bateau miniature dans une bouteille" comme on le fait actuellement.
- Paralèllement de définir un langage permettant de supporter ce formalisme plus accessible par des primitives structurelles plus étendu, par de la reconaissance de forme, etc...
J'aurai donc quelques questions :
Les formalismes existant, comme UML, te satisfassent-ils pleinement ?
Pourquoi ?
Ne serait-il pas possible de définir un formalisme de spécification de plus haut niveau ?
Concernant le SQL.
1/ Le concept
Imagine cet exemple : J'ai une arborescence d'objets contenant chacun une pièce référencée (une nomenclature, quoi).
Je veux lister l'ensemble des pièces dont le grand-père est la référence 'A20' et dont le diamètre est supérieur à 20 mm.
Si je code ça à la main, c'est prise de tête, il faut faire un algo où je parcours l'arbre, où je teste le type des objets pour être sûr de pouvoir appeler le getter "diamètre".
Je te passe l'algorithme.
Avec mon système, je fait
arbre est l'arobrescence de pièce.
p est un ensemble de référence.
p := select obj from arbre where obj.père.père.is_ref "A21" and obj.diamètre > 20;
2/ L'application
Tu confond le concept et l'implémentation ou plutôt - comme je te pense trop fin pour faire cette erreur - tu me fait (gentillement) un procès d'intention en te basant sur SQL.
Si "select * from test where A=B and B=C " est plus lent ou rapide que "select * from test where C=B and B=A" alors que ces deux assertions sont logiquement équivalente, alors c'est le moteur qui a un problème.
Je pense probable que dans un second temps (voire à la première implémentation), un algorithme d'analyse de flot sera mis au point pour pondre, grâce à une heuristique, un algo rapide de calcul de la requête.
"Peut-être un problème lié à l'utilisation de java? (genre dit rapidement: un design de m... :p)."
Je n'aurait pas la prétention de dire que mon design était bon (bien que j'ai eu une excellente note sur celui-ci justement), mais ça m'a permis de me rendre compte que le design à une importance un peu trop profonde pour des détails un peu fin.
Je veux dire par là qu'à chaque fois que ton logiciel et/ou composant change, tu dois souvent changer pas mal de choses dans la logique des tes objets.
En gros le design peut avoir des causes léthales.
C'est très bien expliqué dans http://java.sun.com/developer/technicalArticles/Interviews/l(...) qui fut une des bases de ma réflexion.
J'aimerai aussi concevoir un langage dans lequel le design a moins d'importance, pour aboutir à un langage à composants adaptatif.
Ce n'est certes pas avec ce que j'ai présenté que cela se fera.
Enfin, tu remarques bien que ma contribution est d'un style universitaire, c'est normal puisque c'est un texte que l'on est ammené à soumetre à une conférence de recherche dans les tous prochains jours.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
J'aimerai bien qu'un chercheur tente une étude sur la question pour établir la répartition sociologique (en terme de revenu et culturel) des auteurs du travail au noir.
Si on peut avoir quelques idées dans le batiment (quoique), ce domaine est-il majoritaire.
PS : Elles sont passionantes les émissions sur ton site http://dsedh.free.fr
C'est toi qui les fait ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
C'est pas en ligne, c'est le numéro de cette semaine.
Faut lire les articles version papiers, Les articles de plusieurs pages sont assez intéressants, en tout cas pas plus mauvais que ceux qu'on lit dans libé/lemonde/lepoint/nouvelle obs/etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
([HS]tiens ça me fait penser qu'il faut je réponde à ton autre commentaire ;)
C'est un résumé très rapide de l'article que je te conseilles de lire pour te faire ta propre opinion.
Personnelement, je ne vois pas ça comme une histoire de "coûts".
Je parlais de Keynes plus haut, bien sûr que l'argent est redirigé ailleurs, j'en donnait un exemple.
Je pense qu'il faut plutôt considérer ses informations pour deux raisons:
1/ La raison invoquée par Marianne est qu'il faut selon le magasine replacer les choses face à loffensive médiatique néolibérale qui est menée actuellement.
2/ C'est une question de direction et redirection des flux, et de l'efficacité de ces directions de flux
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
On peut donc objectivement considérer que le travail au noir est taxé à 20% s'il est bien réinjecté dans la consomation.
En considérant bien sûr que la population travaillant au noir est susceptible de le faire, bien sûr..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Ca me fait penser à ce que keynes expliquait sans sa "théorie générale" : Si un agent économique (un humain) est doté d'un salaire, il va le dépenser, ce qui va induire (la consommation) des bénéfices pour les commerçant, les fabricaznts, donc des salaires, donc de la consommation. Il y a un effet démultiplicateur.
J'en viens à ce que tu disais : J'avais sympathisé, lorsque j'habitais dans mon précédent apart' avec mon voisin qui était carleur.
Il m'a raconté que 40 % de son salaire était issu du travail au noir. En gros ce salaire, lui permettait de payer son loyer et finissait en majorité dans de l'alcool, des soirée en boite, etc...
Si on form un tout avec son salaire légal, ça lui augmentait son pouvoir d'achat qui n'aurait augmenté que de 20 % sinon, voir pas du tout, car créer une société travaillant à quart temps est impossible de par la structure fiscale.
Je crois que c'est un exemple à méditer...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je l'ai aussi changé, parce que ce dialogue hyper mal fait m'énerve depuis longtemps, mais FireFox plante à chaque fois que je sauve quoi que ce soit.
Suis-je tout seul à avoir ce problème ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Mais c'est un débat très secondaire, je suis bien conscient de pinailler sur des détails.
Moi je veux un SQL objet, rien d'autre, je veux pouvoir y mettre des sous requêtes, des group by, etc...
De plus, SQL, tout le monde connaît.
C'est exactement ce que j'aurais à lui reprocher:
- avec un garbage collector certains te prétendent que tu n'as plus à penser à la mémoire, c'est faux! (c'est même plus difficile de contrôler sa mémoire avec un GC!). Il faut évidemment relativiser, peu d'application de nos jours sont réellement tracassée par leur mémoire...
Effectivement, dans certains cas particuliers un Gc peu poser des problèmes.
Fort bien.
Je peu paraître extrémiste, mais je pense qu'il faut en finir avec la gestion à la main de la mémoire, il faut en finir avec les pointeurs.
Il est certes jouissif pour certains de jouer avec, mais, dans le cadre d'un gros projet de plusieurs centaines de milliers de lignes, il faut en finir, c'est un facteur de bug beaucoup trop important.
Je pense d'autre part que c'est au compilateur de gérer finement la mémoire, car un être humain ne pourra jamais le faire aussi bien, en tout cas à partir d'une certaine taille. Demander à un humain de gérer les emplacements mémoire de chaque données, à la main, pour que celle-ci se trouve contigue en mémoire afin d'accélerer le cache est très vite beaucoup trop complexes.
J'ai d'autres exemples de ce style.
Comme tu le dit, la mémoire n'est plus un problème pour la plupart des applications.
Je dirai même que c'est le boulot de compilateur de gérer celle-ci correctement, après analyse de flot.
- avec la prog objet, certains vendent le fait que l'analyse compte (et vive UML et autre formalisme) et que l'implémentation est un détail... c'est à nouveau faux. (ça amène des design élégant, mais jamais implémenté, ou des design "génrique" ne proposant pas de solution concrète dans un cas pratique)
Je ne m'occupe pas de méthode design pour le moment. Je m'occupe de créer un (des, car d'autres suiveront) langage(s) permettant d'exprimer le mieux et le plus vite possible l'intuition du développeur, que celui-ci ne soit pas obligé de se plier à des circonlocutions typiquement informaticienne pour implémenter des concepts évident pour un être humain normalement constitué.
Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple.
Il te faut parcourir une collection, trier selon l'équipe (un test) si ce n'est pas déjà fait, vérifier le type, calculer le module des positions, et le cas échéant appeler une méthode que tu devra avoir pensé pour répondre à un problème très précis (genre "aidez moi, j'ai plus de fioul").
Ce genre de chose ça me gonfle.
C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors.
Bref. Avec une requête SQL, un foreach, et surtout le concept de messages conditionnels en multicast, c'est réglé en 5 lignes.
Après, après... Quand j'aurai le langage fonctionnel qui aura le mérite de commencer à me satisfaire (parce que je serai satisfait qua quand on balancera les spécifs à la machine et qu'il programmera pour nous, on y arrivera un jour qu'on le veuille ou non), là je penserai peut être à réfléchir (ou trouver des gens pour ça) aux méthodes de formalisations type UML adaptée à ce langage.
Mais tout d'abord il faut commencer par le compilateur.
- en C# tu peux déjà appeler un delegate de façon asynchrone, mais s'ils ont pensés au perf (pool de thread etc), tu as des cas explosifs (genre le delegate qui appelle des delegate etc...). Dans certains cas, ça passe par un message, à nouveau tu te retrouves parfois avec un appel bloqué qui attends des dizaines de messages avant de poursuivre!
D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe.
Lisaac est un langage objet à prototype.
Dans un objet que tu écris, tu définis le parent, comme une variable (dans la section INHERIT)
Comme tout est objet vivant, tu peu définir finement qui est ton parent, et tu peux même en changer à l'exécution quand tu le désir.
Donc pas besoin de delegate pour dérouter des messages vers des parents comme l'explique : http://csharpro.developpez.com/page10.php
Tu fait
section INHERIT
+ mon_parent : TYPE_PARENT := TYPE_PARENT;
section PUBLIC
- toto <-
(
mon_parent.method;
);
- tu présentes un formalisme comme étant le truc qui permet de ne pas "avoir de problème" c'est vrai dans un monde théorique (et encore), un formalisme peut être vu comme un langage plus éloigné de la machine et plus proche de l'humain, cela ne le rend pas complet, correct, et surtout cela ne facilite pas forcément les choses. (pense à certains design pattern exprimé en qq mots, qq lignes de codes, et un schéma UML incompréhensible! Cependant, UML n'est pas le seul formalisme, il en existe sans doute de plus adapté selon le cas).
C'est effectivement le plus gros problème. C'est pour cela qu'il faut réfléchir au maximum à une abstraction qui nécessite le moins possible de comprendre ce sur quoi elle s'appuie (comme tcp s'appuie sur ip) pour s'assurer de la maîtriser correctement.
C'est un gros travail.
Ce que nous proposons dans cette publi n'est qu'un modèle et il n'est pas certains que l'implémentation en soit fidèle.
Je pense néanmoins que le fait chaque thread sera dans un monde clot au niveau des données facilitera pas mal les choses.
Après c'est à voir, je pense particulièrement à l'émergence qui est un phénomène structurel.
C'est là que les méthodes joueront leur rôles. Elle sont d'ors en conception dans des labos.
- Dans le même ordre d'idée, je ne pense pas que masqer l'existence de thread soit souhaitable, même le thread, qui est déjà une abstraction ne peut en général pas être utilisée tel quel, un développeur doit se demander comment se comporte son CPU (surtout sur un système multi-proc) s'il veut être efficace. Je ne doute pas de l'intéret d'une telle abstraction dans certains cas (je pense notemment au business rules engine), mais je me pose des questions sur la pertinence de mettre cela dans le langage même.
la pertinence de le mettre dans le langage même consiste à proposer l'absraction pour les "certains cas" dont tu parles.
Un type qui fait une GPAO, un ERP, a autre chose à faire que de se prendre la têtes avec des priorités dans des threads.
Après n'oublie pas que ce qui est proposé est extension du langage que ce soit bien clair ! :-)
Rien ne t'empêche de ne pas utiliser les agents (bref de programmer en objet classique), de gérer toi même tes threads à la main, etc...
Ce que l'on présente dans cette publi, c'est une fonctionnalitée suplémentaire ! Rien d'autres.
Ceux qui jugeront utile de l'utilser l'utiliseront, les autres non. Tu as le choix.
Concernant l'impact sur les performances, les thread ont un coût (dépendant de l'os et de la façon dont tu fais cela, par exemple, par défaut sous windows, chaque nouveau thread à un tas dédiés de 1Mo!), et encore plus si tu ne partages pas la mémoire, un deepcopy sera coûteux en temps et en mémoire!
Enfin ta recherche me semble de toute façon intéressante, je suis impatient de pouvoir tester les premières implémentation!
Pour le coût, on s'adaptera aux OS existants bien que la fnalité de ce langage est de tourner sur IsaacOS qui sera un OS temps réel à terme et intégralement objet.
Pour l'implémentation ça risque de prendre du temps, surtout si messieurs les chercheurs tardent à donner le poste que Benoit Sonntag mérite...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je pense qu'il ya possibiité d'obtenir de bonnes perfs sur le système de requêtes en optimisant celle-ci d'une part (coupes dans l'arbre, compilation inline de l'algo de calcul de la requête) et d'autre part en réorganisant les données de tel façon qu'on puisse retrouver assez vite les données.
Dans un contexte ou tout est compilé (ie que des micro objets), on pourrait utiliser l'analyse de flot pour organiser des indexs prévus pour "coller" à la requête.
Quand au thread, je vois pas de problèmes de perfs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Concernant le "SQL/Objet", je comprends l'intéret, c'est aussi ce qui se fait en autre en C# 3.0 il me semble (avec sans doute quelques différences qui m'échappe), et si c'est bien pensé, et applicable aussi bien aux données externes qu'internes, ça devrait en effet grandement simplifié la façon de penser des programmes (avec par contre le danger de mélanger les couches et de créer des composants fortement couplés sans même s'en rendre compte). Permets-moi juste de préciser que c'est surtout du sucre syntaxique tournant autour des lambdas expressions et l'utilisation de fonction en first class object.
Premièrement, je ne me suis pas gêné pour le mettre, parce que j'y ai pensé tout seul (SQL est mon "langage" de prog préféré). J'ai découvert, à l'occasion d'unjournal de TImaniac que C#3 l'incluerait. Bien que ça ne me plaise pas dans la forme retenue.
Je veux SQL intégré dans le langage, car j'en ai plus que marre de passer mon temps à parcourir des collections pour tester tel ou tel critères.
Deuxièmement, c'est effectivement du sucre syntaxique qui nécessite une modification du compilo (c'est pour ça qu'on l'a mis), mais qui simplifie la vie. C'est ça qui compte.
Concernant l'aspect massivement multithread, je suis perplexe, j'ai l'impression que ça permettrait d'éviter la complexité syntaxique de ce genre de construction, mais j'ai un doute sur la simplication réelle, au contraire j'ai peur que cela rende un programme extrèmement complexe à comprendre. Quelle mécanismes existent-ils pour gérer les effets de bord? Dans tous les langages, c'est le problème, encore plus dans les langages objets (et leur idée de "remplacer un composant par un autre", pense par exemple à java et le fait que toute les méthodes soit virtuelles).
C'est déjà très complexe de faire un modèle objet single thread, gérer plus de 3 threads interdépendantes est vite un enfer... je n'oserais pas proposer à mon équipe de dev d'utiliser ce genre de chose, je vois déjà les cascades de threads créées sans même s'en rendre compte ;)
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads" TU devra penser en terme d'agent vivant, sur le qui vive, attendant des évènement extérieurs.
C'est dans l'émergence de comportements que tu risque effectivement d'avoir quelques problèmes, surtout si ton agent réagit directement à des évènements extérieur.
Mais grâce au système de message (message synchrone objet classiq ou message asynchrone du type boite au lettre (le point 3/)), tu pourras rendre tes agent un tant soi peu "cognitif", limiter leur réactivité, et ainsi avoir des comportements émergeants limités.
Il existe (la méthode VOYELLE par ex) des formalismes permettant de ne pas avoir de problème, il est certain qu'il sera nécessaire de bien les formaliser avant de lacher un tel langage dans l'industrie, mais je pense que si quelques règles de base sont bien appliquée, tu n'aura pas de problème car, comme je le répète plus haut :
1/ Les threads sont autonomes et travaillent sur des données qui ne se balladent pas entre threads : toutes les données échangées se feront par copie, de sorte qu'il n'y ai pas de conflit
2/ C'est le compilateur qui gère tous les monitors et autres problème de synchro. Pour le programmeur, il ya des processus indépendants qui s'envoient des messages.
Enfin, as-tu des données sur les perf de ce langage? Je me doute que c'est encore expérimental, mais est-ce théoriquement possible de faire quelque chose de compétitif? (à savoir: le classique trade-off entre temps de dev et hardware nécessaire)
Pour le moment le compilateur n'étant pas implémenté, on en sait rien.
Par contre, sache que lisaac (l'actuel) est certainement le langage objet le plus performant au monde, il va beaucoup plus loin qu'Eiffel dont il est un descendant (et en même temps un sur ensemble) :-)
voir : http://isaacos.loria.fr/li_speed.html
Je ne sais pas ce que ça donnera, mais connaissant Benoit Sonntag, je prévoit que ça ira très très vite... ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
Je veux bien croire que le jargon aide à exprimer ses pensées en peu de mots, mais l'économie de mots a un coût, pour le lecteur, lorsqu'il s'agit de comprendre. Il n'y a pas de honte à utiliser une ou deux phrases à la place de mots comme ontologisation hein :)
Il s'agit plus de flemme que de honte. J'adore les phrases denses et concises, sans doute parce que j'ai horreur de perdre mon temps.
Tapper m'ennuie, alors vive les préfixes et les suffixes. Après je vais peut être parfois trop loin...
- On passe progressivement d'une représentation des données à une description des données. Par exemple (simpliste) le champ "size" d'un objet "array" peut-être représenté par un entier (non distinguable des autres entiers), ou bien décrit comme étant la taille du tableau (et donc pas un entier quelconque). La description implique entre autres que le champ size a une influence sur le nombre d'itérations d'un parcours du tableau, sur la place qu'occupe ce tableau en mémoire, etc. Si l'on se contente de représenter les données sans les décrire, alors c'est au programmeur d'interpréter leur signification dans sa tête.
- Ça serait bien que ce passage de représentation à description ne soit pas limité aux données, mais soit aussi appliqué au traitement des données. Là j'avoue que j'ai du mal à trouver rapidement un exemple pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien que l'on puisse programmer des design patterns. Pour l'instant on ne peut pas les programmer, ce sont des concepts que le programmeur doit adapter à sa situation, mais avec des langages de plus haut niveau, ça serait possible.
Imagine, que tu utilise dans ton programme une liste chainée de couple de réels
{(3.5,5.4),(8.4,8.6),...}.
Imaginons que dans toutes les manipulations que tu effectue dessus, il se trouve que tu respectes les axiomes d'espaces vectoriels (ie. dans ta tête lorsque tu programmes, ta liste chainée est une liste de vecteurs).
Tu additionne tes couples, tu utilises des matrices, etc...
Un "prépocesseur" détecte alors que ta liste chainée est une liste de vecteurs d'un espace vectoriel. Il te propose d'emblée tout un tas de fonctions, il vérifie que ton code ne contient pas d'erreurs mathématiques, etc...
Par exemple, si tu modélise des agents sur un terrain (de foot par exemple), et que tu décris ceux-ci par des vecteurs, tu auras automatiquement la possibilité de leur donner une direction en radian, en degré, et un module.
Si tu modélise un balon, il suffira de le définir comme objet physique doté d'une masse (le type OBJET_MASSIQUE) et il analysera le contexte d'utilisation de ton balon pour toi, te proposant calcul de trajectoire, etc...
C'est plutôt vers cette idée.
Programmer, c'est créer de toutes pièces une structure cohérente (Coherens "qui tien ensemble"). Un truc issu de ton cerveau que tu crée à partir de rien, à part les primitives offertes par ton langage.
Là, par reconnaissance de forme, l'environnement de dev détecte les objets que tu veux décrire et t'assiste en t'offrant des structures toutes faites.
On aura une réprésentation standard du concept de client, d'entreprise, d'employé, de pièce, etc... Avec à chaque fois des propriétés et des contraintes.
C'est entre "écrire de la lib" et "concevoir un moteur de reconnaissance de forme".
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
- Pour qu'un langage/paradigme soit adopté, il faut entre autre, qu'il apporte quelque chose, j'ai du mal à résumer les avantages de ce que tu présentes! comment résumerais-tu cela toi?
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
- list_reapro : SET[PIECE] <-
(
+ result : SET[PIECE] := SET[PIECE].create; // on créé un ensemble de pièces
result := select refs from stock where qte<seuil // on liste les pièces
//stock est une collection d'objets pièces.
result // on les renvoient
);
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
- coupe_piste_selon_filtre_actif typefiltre : FILTRE volume_under volum : INTEGER <-
// ce header permet de couper toutes les pistes utilisant un filtre, dont le niveau sonore est en dessous de volum
(
// un filtre est un calcul effectué en temps réel sur flux son : equaliseur, disto
//phaser, etc...
+ list_soundagent : AGENT;
list_soundagent := select_agent from list_agent_playing where filtre_actif.type = typefiltre and volume<= volum;
list_soundagent.foreach {
x : AGENT;
x.mute;
};
);
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: chut
Posté par Ontologia (site web personnel) . En réponse au journal [HS] : où sont les musulmans modérés dans cette histoire de caricatures ?. Évalué à -1.
Malheuresement, ces caricatures sont en face (le monde musulmans, et surtout certains partis politiques) utilisée pour supprimer le point 1 (la liberté d'expression) sous reserve "diplomatique" du point 2 (caricatures stupides).
Ca tombe bien : c'est pil poil ce que les dessinateurs danois voulaient démontrer.
Je pense que tu as psychologiquement raison si tu penses à l'élite dirigeantes des pays protestataire qui profite de cet évèvenment (dont ils n'ont cure eux-même) pour assoir leur légitimité. Comme le disait Ignatio Ramonet sur inter tout à l'heure, pour beaucoup de musulmans, l'occident c'est Abou Graib, pour beaucoup d'occidentaux, les musulman c'est Ben Laden. Il parlait là des masses peu informées.
Je crois que les masses (manipulées) manifestantes se fichent un peu des arguties savantes sur la bonne mesure de la liberté d'expression et voient un blasphème, la goutte qui fait déborder le vase.
Va vraiment falloir qu'on organise des échanges culturel moyen-orient/europe parce que sinon ça va péter. Mais c'est sans doute trop tard....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: chut
Posté par Ontologia (site web personnel) . En réponse au journal [HS] : où sont les musulmans modérés dans cette histoire de caricatures ?. Évalué à 2.
Si c'est ce que tu penses, c'est ce que je pense aussi. Et c'est quelques chose qu'on entend pas assez dans les médias :
1/ La liberté d'expression ne se négocie pas.
2/ Certaines de ses caricatures sont bêtes, stupide et surtout, pas drôles.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Diffusion ?
Posté par Ontologia (site web personnel) . En réponse au journal Novell et les effet graphique. Évalué à 2.
Mais les effets sont assez conséquent aussi.
Par contre je me demande si au passage la Xlib va enfin devenir asynchrone....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Diffusion ?
Posté par Ontologia (site web personnel) . En réponse au journal Novell et les effet graphique. Évalué à 4.
Je lui demande "Si je comprend bien, dans environ 9 mois, je suis quasiment sûr de retrouver ça dans ma distrib, quelle qu'elle soit ?"
Il me répond "Si vous avez de bon driver pour votre carte 3D, tout à fait".
C'est pour le moment une version beta, et ce sera bientôt accessible à tous quand ce sera au point.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# re : test
Posté par Ontologia (site web personnel) . En réponse au message (test signature). Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Une voie prometteuse
Posté par Ontologia (site web personnel) . En réponse au journal mais apprenez donc à coder...!. Évalué à 2.
Je pense que toute pédagogie soit s'adapter, non seulement à la psychologie cognitive de son récepteur, mais aussi chercher à lui demander le moins de réflexions, d'effort possible pour comprendre. s'approprier les concepts. Ce qui n'est pas antinomique avec une activité et un questionnement intelectuel. Il s'agit juste de la phase d'appropriation des concepts.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas le mot...
Posté par Ontologia (site web personnel) . En réponse au journal Pourquoi l'aversion d'une majorité, dans l'opinion, pour le mot 'libéral' ?. Évalué à 2.
Le libéralisme, en gros et pour faire très court, est une philosophie politique qui présuppose que le marché est le meilleur moyen de réguler la société. Les libéraux classiques, comme Adam Smith, le créateur pensent que l'Etat doit garantir la Loi (et que celle-ci sont souveraine : un Etat de droit), garantir la sécurité des citoyens ET, pour beaucoup de penseur libéraux, corriger les effets négatifs du marché. Adam Smith expliquait déjà à la fin du XVIIIème que la correction étatique était nécessaire pour des domaines comme la culture car la "pauvreté de l'eprit marchand" aboutirait à son anéantissement.
A l'époque du Keynesianisme triomphant (1935-1975), les néolibéraux, farouches adversaires du Keynesianisme développèrent une idéologie stipulant que l'Etat ne doit absolument pas intervenir dans l'économie (car sous la coupe des "groupes de pression"), ne doit pas toucher au droit du travail, des flux de capitaux, etc...
C'est ce que l'on appelle l'école "Monétariste". Le lien qui me fait office de signature contient un série d'emmisions consacré à expliquer l'émergence de cette idéologie.
Le néolibéralisme a été soutenu par les milieux financier qui, dès le début, donnèrent des moyens à son développement idéologique et à son audience.
Ils ont sciemment utilisé la technique qui s'est mis en place naturellement pour l'invasion d'UNIX sur le marché : On s'occupe de formater les étudiants, de les convaincre, comptant sur eux pour diffuser l'idéologie.
J'ai un jour posé la question à Jean-François Khan de définir cette différence entre le libéralisme et néolibéralisme et si sa non reconnaissance dans la discussion politique française.
Il m'a répondu que le néolibéralisme était au libéralisme ce que le stalinisme était à la social-démocratie.
Cette idéologie, je le pense et je l'affirme, mènera à la destruction de notre civilisation. Elle veut organiser la précarité dans la vie de tous, la domination totale et absolue d'une classe dirigeante possédante, elle veut détruire la démocratie qui la dérange et l'empêche d'exploiter les êtres humains.
Cette idéologie abouti déjà, dans certains secteurs, à des monopoles privé, à la conurrence fiscale, à la précarisation généralisé, à la mise sous conditions de guerre entre les hommes.
En France, les néolibéraux patentés sont très souvent d'anciens activiste d'extreme droite dans leur jeunesse. Patrick Devedjian, Gloasgen, Madelin, Novelli, etc... Tous ces députés UMP qui derrière Sarko, brulent de tuer l'Etat et brule de virer Chirac qui, pour une fois visionnaire, leur dit souvent (ce qui est absolument insuportable à leur oreilles)
"Le libéralisme finira comme le Marxisme"
Le néolibéralisme est une idéologie très proche du marxisme-stalinisme , la première comptant de nombreux transfuge de la seconde.
Il faut que l'opinion comprenne cette distinction, c'est fondamental
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Une voie prometteuse
Posté par Ontologia (site web personnel) . En réponse au journal mais apprenez donc à coder...!. Évalué à 6.
Le proberbe "Un dessin vaut mieux qu'un long discours" est et sera toujours valable. Regarder une vidéo, un peu humoristique qui plus est, sera toujours plus efficace pédagogiquement que d'imposer une documentation lourde, très formelle et ardue.
C'est une question de psychologie cognitive : regarder une vidéo où un schéma nécessite beaucoup mois d'énergie à l'étudiant que de mener un long processus mental dans lequel celui-ci va se reconstruire une représentation personnelle d'un concept à partir d'une formalisation potentiellement très éloigné de sa façon de se représenter les choses.
Lire est surement beaucoup plus fatiguant que de regarder une vidéo, ou d'écouter...
Mais cela dépend aussi de l'auditoire, certains sont plus à l'aise avec un livre, d'autres préfèrent un cours.
Il y a des gens auditifs, d'autres visuels. Certains sont plutôt déductifs, d'autres inductifs...
L'internet d'aujourd'hui permet de diffuser en ligne des vidéo, de l'audio, etc... On peut maginer (ça se fait déjà) des cours/conférences en ligne, pour expliquer pas mal d'idées simple à comprendre en fait.
En tout cas félicitation à ce labo de Standford, c'est sympa et très clair, le but étant de faire comprendre le concept de pointeur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 1.
A la réflexion, moi qui défend constamment la nécessité méthodologique d'intégrer les deux approches (ascendantes et descendantes), je suis en train de tomber dans le travers en privilégiant une approche asendante pour lesquelles j'ai d'ailleurs toujours eu un faible.
N'ayant pas eu à mettre au point de gros projets dans l'industrie, n'ayant qu'une connaissance théorique d'UML, j'avoue avoir du mal à définir les problématiques.
Je pense que tu serais plus à même d'emmetre quelques idées à ce sujet. Je serai ravi de créer un petit projet visant à relever un ensemble de problématiques et de tenter de trouver des solutions.
Il serait intéressant de tenter de rêver :
- C'est à dire de définir un formalisme permettant de définir avec moins de difficultés qu'UML, avec plus d'intuitivité sans perdre de vue l'exactitude. Je veux dire "plus d'intuitivité" par la définition d'un formalisme qui nécessite moins de se plier au formalisme objet classique, de "faire rentrer un bateau miniature dans une bouteille" comme on le fait actuellement.
- Paralèllement de définir un langage permettant de supporter ce formalisme plus accessible par des primitives structurelles plus étendu, par de la reconaissance de forme, etc...
J'aurai donc quelques questions :
Les formalismes existant, comme UML, te satisfassent-ils pleinement ?
Pourquoi ?
Ne serait-il pas possible de définir un formalisme de spécification de plus haut niveau ?
Concernant le SQL.
1/ Le concept
Imagine cet exemple : J'ai une arborescence d'objets contenant chacun une pièce référencée (une nomenclature, quoi).
Je veux lister l'ensemble des pièces dont le grand-père est la référence 'A20' et dont le diamètre est supérieur à 20 mm.
Si je code ça à la main, c'est prise de tête, il faut faire un algo où je parcours l'arbre, où je teste le type des objets pour être sûr de pouvoir appeler le getter "diamètre".
Je te passe l'algorithme.
Avec mon système, je fait
arbre est l'arobrescence de pièce.
p est un ensemble de référence.
2/ L'application
Tu confond le concept et l'implémentation ou plutôt - comme je te pense trop fin pour faire cette erreur - tu me fait (gentillement) un procès d'intention en te basant sur SQL.
Si "select * from test where A=B and B=C " est plus lent ou rapide que "select * from test where C=B and B=A" alors que ces deux assertions sont logiquement équivalente, alors c'est le moteur qui a un problème.
Je pense probable que dans un second temps (voire à la première implémentation), un algorithme d'analyse de flot sera mis au point pour pondre, grâce à une heuristique, un algo rapide de calcul de la requête.
"Peut-être un problème lié à l'utilisation de java? (genre dit rapidement: un design de m... :p)."
Je n'aurait pas la prétention de dire que mon design était bon (bien que j'ai eu une excellente note sur celui-ci justement), mais ça m'a permis de me rendre compte que le design à une importance un peu trop profonde pour des détails un peu fin.
Je veux dire par là qu'à chaque fois que ton logiciel et/ou composant change, tu dois souvent changer pas mal de choses dans la logique des tes objets.
En gros le design peut avoir des causes léthales.
C'est très bien expliqué dans http://java.sun.com/developer/technicalArticles/Interviews/l(...) qui fut une des bases de ma réflexion.
J'aimerai aussi concevoir un langage dans lequel le design a moins d'importance, pour aboutir à un langage à composants adaptatif.
Ce n'est certes pas avec ce que j'ai présenté que cela se fera.
Enfin, tu remarques bien que ma contribution est d'un style universitaire, c'est normal puisque c'est un texte que l'on est ammené à soumetre à une conférence de recherche dans les tous prochains jours.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: en fait phpmyadmin marche plus
Posté par Ontologia (site web personnel) . En réponse au message Apache veut pas faire tourner php. Évalué à 1.
Shame on me !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# en fait phpmyadmin marche plus
Posté par Ontologia (site web personnel) . En réponse au message Apache veut pas faire tourner php. Évalué à 1.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: pour le travail au noir .....
Posté par Ontologia (site web personnel) . En réponse au journal Repenser le problème de la dette de l'Etat. Évalué à 2.
Si on peut avoir quelques idées dans le batiment (quoique), ce domaine est-il majoritaire.
PS : Elles sont passionantes les émissions sur ton site http://dsedh.free.fr
C'est toi qui les fait ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un peu naif?
Posté par Ontologia (site web personnel) . En réponse au journal Repenser le problème de la dette de l'Etat. Évalué à 2.
Faut lire les articles version papiers, Les articles de plusieurs pages sont assez intéressants, en tout cas pas plus mauvais que ceux qu'on lit dans libé/lemonde/lepoint/nouvelle obs/etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Un peu naif?
Posté par Ontologia (site web personnel) . En réponse au journal Repenser le problème de la dette de l'Etat. Évalué à 2.
C'est un résumé très rapide de l'article que je te conseilles de lire pour te faire ta propre opinion.
Personnelement, je ne vois pas ça comme une histoire de "coûts".
Je parlais de Keynes plus haut, bien sûr que l'argent est redirigé ailleurs, j'en donnait un exemple.
Je pense qu'il faut plutôt considérer ses informations pour deux raisons:
1/ La raison invoquée par Marianne est qu'il faut selon le magasine replacer les choses face à loffensive médiatique néolibérale qui est menée actuellement.
2/ C'est une question de direction et redirection des flux, et de l'efficacité de ces directions de flux
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: pour le travail au noir .....
Posté par Ontologia (site web personnel) . En réponse au journal Repenser le problème de la dette de l'Etat. Évalué à 2.
En considérant bien sûr que la population travaillant au noir est susceptible de le faire, bien sûr..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: pour le travail au noir .....
Posté par Ontologia (site web personnel) . En réponse au journal Repenser le problème de la dette de l'Etat. Évalué à 2.
Ca me fait penser à ce que keynes expliquait sans sa "théorie générale" : Si un agent économique (un humain) est doté d'un salaire, il va le dépenser, ce qui va induire (la consommation) des bénéfices pour les commerçant, les fabricaznts, donc des salaires, donc de la consommation. Il y a un effet démultiplicateur.
J'en viens à ce que tu disais : J'avais sympathisé, lorsque j'habitais dans mon précédent apart' avec mon voisin qui était carleur.
Il m'a raconté que 40 % de son salaire était issu du travail au noir. En gros ce salaire, lui permettait de payer son loyer et finissait en majorité dans de l'alcool, des soirée en boite, etc...
Si on form un tout avec son salaire légal, ça lui augmentait son pouvoir d'achat qui n'aurait augmenté que de 20 % sinon, voir pas du tout, car créer une société travaillant à quart temps est impossible de par la structure fiscale.
Je crois que c'est un exemple à méditer...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: gcu
Posté par Ontologia (site web personnel) . En réponse au journal tootella.org. Évalué à -2.
Après cela n'engage que moi..
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est pas GNOME...
Posté par Ontologia (site web personnel) . En réponse au message firefox 1.5 et les fenetres "save as" et "open file". Évalué à 2.
Suis-je tout seul à avoir ce problème ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# QQ idées
Posté par Ontologia (site web personnel) . En réponse au message bzip2-1.0.3-3mdk.i586.rpm. Évalué à 2.
2/ essaye avec l'option --no-verify-rpm
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
Ca m'intéresse qu'est ce qui ne te plait pas? que proposes-tu de mieux/différent?
C'est la syntaxe qui ne me plaît pas. je la trouve compliqué.
Certes on peut faire
c'est un sucre syntaxique qui ne me plait pas.
Mais c'est un débat très secondaire, je suis bien conscient de pinailler sur des détails.
Moi je veux un SQL objet, rien d'autre, je veux pouvoir y mettre des sous requêtes, des group by, etc...
De plus, SQL, tout le monde connaît.
C'est exactement ce que j'aurais à lui reprocher:
- avec un garbage collector certains te prétendent que tu n'as plus à penser à la mémoire, c'est faux! (c'est même plus difficile de contrôler sa mémoire avec un GC!). Il faut évidemment relativiser, peu d'application de nos jours sont réellement tracassée par leur mémoire...
Effectivement, dans certains cas particuliers un Gc peu poser des problèmes.
Fort bien.
Je peu paraître extrémiste, mais je pense qu'il faut en finir avec la gestion à la main de la mémoire, il faut en finir avec les pointeurs.
Il est certes jouissif pour certains de jouer avec, mais, dans le cadre d'un gros projet de plusieurs centaines de milliers de lignes, il faut en finir, c'est un facteur de bug beaucoup trop important.
Je pense d'autre part que c'est au compilateur de gérer finement la mémoire, car un être humain ne pourra jamais le faire aussi bien, en tout cas à partir d'une certaine taille. Demander à un humain de gérer les emplacements mémoire de chaque données, à la main, pour que celle-ci se trouve contigue en mémoire afin d'accélerer le cache est très vite beaucoup trop complexes.
J'ai d'autres exemples de ce style.
Comme tu le dit, la mémoire n'est plus un problème pour la plupart des applications.
Je dirai même que c'est le boulot de compilateur de gérer celle-ci correctement, après analyse de flot.
- avec la prog objet, certains vendent le fait que l'analyse compte (et vive UML et autre formalisme) et que l'implémentation est un détail... c'est à nouveau faux. (ça amène des design élégant, mais jamais implémenté, ou des design "génrique" ne proposant pas de solution concrète dans un cas pratique)
Je ne m'occupe pas de méthode design pour le moment. Je m'occupe de créer un (des, car d'autres suiveront) langage(s) permettant d'exprimer le mieux et le plus vite possible l'intuition du développeur, que celui-ci ne soit pas obligé de se plier à des circonlocutions typiquement informaticienne pour implémenter des concepts évident pour un être humain normalement constitué.
Si tu prend une bataille navale, le concept "un croiseur envoie un message à tous les croiseurs de son équipe, dans un rayon de 400km" devient très vite un bordel immonde (et encore c'est un exemple très simple.
Il te faut parcourir une collection, trier selon l'équipe (un test) si ce n'est pas déjà fait, vérifier le type, calculer le module des positions, et le cas échéant appeler une méthode que tu devra avoir pensé pour répondre à un problème très précis (genre "aidez moi, j'ai plus de fioul").
Ce genre de chose ça me gonfle.
C'est en devant programmer ce truc précis, lors d'un projet en formation, que les idées à la base de cette publi (il n'y pas tout d'ailleurs) me sont venues car j'en avai plus que marre d'écrire 1500 boucles, en java qui plus est, où tu dois récupérer et caster ce que contiennent tes vectors.
Bref. Avec une requête SQL, un foreach, et surtout le concept de messages conditionnels en multicast, c'est réglé en 5 lignes.
Après, après... Quand j'aurai le langage fonctionnel qui aura le mérite de commencer à me satisfaire (parce que je serai satisfait qua quand on balancera les spécifs à la machine et qu'il programmera pour nous, on y arrivera un jour qu'on le veuille ou non), là je penserai peut être à réfléchir (ou trouver des gens pour ça) aux méthodes de formalisations type UML adaptée à ce langage.
Mais tout d'abord il faut commencer par le compilateur.
- en C# tu peux déjà appeler un delegate de façon asynchrone, mais s'ils ont pensés au perf (pool de thread etc), tu as des cas explosifs (genre le delegate qui appelle des delegate etc...). Dans certains cas, ça passe par un message, à nouveau tu te retrouves parfois avec un appel bloqué qui attends des dizaines de messages avant de poursuivre!
D'après le peu que j'en ai compris, le delegate est
1/ un sous-concept de messages entre objet
2/ un bricolage conçu pour contourner les limites de l'objet à classe.
Lisaac est un langage objet à prototype.
Dans un objet que tu écris, tu définis le parent, comme une variable (dans la section INHERIT)
Comme tout est objet vivant, tu peu définir finement qui est ton parent, et tu peux même en changer à l'exécution quand tu le désir.
Donc pas besoin de delegate pour dérouter des messages vers des parents comme l'explique : http://csharpro.developpez.com/page10.php
Tu fait
- tu présentes un formalisme comme étant le truc qui permet de ne pas "avoir de problème" c'est vrai dans un monde théorique (et encore), un formalisme peut être vu comme un langage plus éloigné de la machine et plus proche de l'humain, cela ne le rend pas complet, correct, et surtout cela ne facilite pas forcément les choses. (pense à certains design pattern exprimé en qq mots, qq lignes de codes, et un schéma UML incompréhensible! Cependant, UML n'est pas le seul formalisme, il en existe sans doute de plus adapté selon le cas).
C'est effectivement le plus gros problème. C'est pour cela qu'il faut réfléchir au maximum à une abstraction qui nécessite le moins possible de comprendre ce sur quoi elle s'appuie (comme tcp s'appuie sur ip) pour s'assurer de la maîtriser correctement.
C'est un gros travail.
Ce que nous proposons dans cette publi n'est qu'un modèle et il n'est pas certains que l'implémentation en soit fidèle.
Je pense néanmoins que le fait chaque thread sera dans un monde clot au niveau des données facilitera pas mal les choses.
Après c'est à voir, je pense particulièrement à l'émergence qui est un phénomène structurel.
C'est là que les méthodes joueront leur rôles. Elle sont d'ors en conception dans des labos.
- Dans le même ordre d'idée, je ne pense pas que masqer l'existence de thread soit souhaitable, même le thread, qui est déjà une abstraction ne peut en général pas être utilisée tel quel, un développeur doit se demander comment se comporte son CPU (surtout sur un système multi-proc) s'il veut être efficace. Je ne doute pas de l'intéret d'une telle abstraction dans certains cas (je pense notemment au business rules engine), mais je me pose des questions sur la pertinence de mettre cela dans le langage même.
la pertinence de le mettre dans le langage même consiste à proposer l'absraction pour les "certains cas" dont tu parles.
Un type qui fait une GPAO, un ERP, a autre chose à faire que de se prendre la têtes avec des priorités dans des threads.
Après n'oublie pas que ce qui est proposé est extension du langage que ce soit bien clair ! :-)
Rien ne t'empêche de ne pas utiliser les agents (bref de programmer en objet classique), de gérer toi même tes threads à la main, etc...
Ce que l'on présente dans cette publi, c'est une fonctionnalitée suplémentaire ! Rien d'autres.
Ceux qui jugeront utile de l'utilser l'utiliseront, les autres non. Tu as le choix.
Concernant l'impact sur les performances, les thread ont un coût (dépendant de l'os et de la façon dont tu fais cela, par exemple, par défaut sous windows, chaque nouveau thread à un tas dédiés de 1Mo!), et encore plus si tu ne partages pas la mémoire, un deepcopy sera coûteux en temps et en mémoire!
Enfin ta recherche me semble de toute façon intéressante, je suis impatient de pouvoir tester les premières implémentation!
Pour le coût, on s'adaptera aux OS existants bien que la fnalité de ce langage est de tourner sur IsaacOS qui sera un OS temps réel à terme et intégralement objet.
Pour l'implémentation ça risque de prendre du temps, surtout si messieurs les chercheurs tardent à donner le poste que Benoit Sonntag mérite...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Je pense qu'il ya possibiité d'obtenir de bonnes perfs sur le système de requêtes en optimisant celle-ci d'une part (coupes dans l'arbre, compilation inline de l'algo de calcul de la requête) et d'autre part en réorganisant les données de tel façon qu'on puisse retrouver assez vite les données.
Dans un contexte ou tout est compilé (ie que des micro objets), on pourrait utiliser l'analyse de flot pour organiser des indexs prévus pour "coller" à la requête.
Quand au thread, je vois pas de problèmes de perfs.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Premièrement, je ne me suis pas gêné pour le mettre, parce que j'y ai pensé tout seul (SQL est mon "langage" de prog préféré). J'ai découvert, à l'occasion d'unjournal de TImaniac que C#3 l'incluerait. Bien que ça ne me plaise pas dans la forme retenue.
Je veux SQL intégré dans le langage, car j'en ai plus que marre de passer mon temps à parcourir des collections pour tester tel ou tel critères.
Deuxièmement, c'est effectivement du sucre syntaxique qui nécessite une modification du compilo (c'est pour ça qu'on l'a mis), mais qui simplifie la vie. C'est ça qui compte.
Concernant l'aspect massivement multithread, je suis perplexe, j'ai l'impression que ça permettrait d'éviter la complexité syntaxique de ce genre de construction, mais j'ai un doute sur la simplication réelle, au contraire j'ai peur que cela rende un programme extrèmement complexe à comprendre. Quelle mécanismes existent-ils pour gérer les effets de bord? Dans tous les langages, c'est le problème, encore plus dans les langages objets (et leur idée de "remplacer un composant par un autre", pense par exemple à java et le fait que toute les méthodes soit virtuelles).
C'est déjà très complexe de faire un modèle objet single thread, gérer plus de 3 threads interdépendantes est vite un enfer... je n'oserais pas proposer à mon équipe de dev d'utiliser ce genre de chose, je vois déjà les cascades de threads créées sans même s'en rendre compte ;)
C'est en effet un énorme problème (comme le souligne "Joel on software" : http://french.joelonsoftware.com/Articles/LeakyAbstractions.(...) ).
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads" TU devra penser en terme d'agent vivant, sur le qui vive, attendant des évènement extérieurs.
C'est dans l'émergence de comportements que tu risque effectivement d'avoir quelques problèmes, surtout si ton agent réagit directement à des évènements extérieur.
Mais grâce au système de message (message synchrone objet classiq ou message asynchrone du type boite au lettre (le point 3/)), tu pourras rendre tes agent un tant soi peu "cognitif", limiter leur réactivité, et ainsi avoir des comportements émergeants limités.
Il existe (la méthode VOYELLE par ex) des formalismes permettant de ne pas avoir de problème, il est certain qu'il sera nécessaire de bien les formaliser avant de lacher un tel langage dans l'industrie, mais je pense que si quelques règles de base sont bien appliquée, tu n'aura pas de problème car, comme je le répète plus haut :
1/ Les threads sont autonomes et travaillent sur des données qui ne se balladent pas entre threads : toutes les données échangées se feront par copie, de sorte qu'il n'y ai pas de conflit
2/ C'est le compilateur qui gère tous les monitors et autres problème de synchro. Pour le programmeur, il ya des processus indépendants qui s'envoient des messages.
Enfin, as-tu des données sur les perf de ce langage? Je me doute que c'est encore expérimental, mais est-ce théoriquement possible de faire quelque chose de compétitif? (à savoir: le classique trade-off entre temps de dev et hardware nécessaire)
Pour le moment le compilateur n'étant pas implémenté, on en sait rien.
Par contre, sache que lisaac (l'actuel) est certainement le langage objet le plus performant au monde, il va beaucoup plus loin qu'Eiffel dont il est un descendant (et en même temps un sur ensemble) :-)
voir : http://isaacos.loria.fr/li_speed.html
Je ne sais pas ce que ça donnera, mais connaissant Benoit Sonntag, je prévoit que ça ira très très vite... ;-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Et le langage humain de mes rêves...
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 2.
Il s'agit plus de flemme que de honte. J'adore les phrases denses et concises, sans doute parce que j'ai horreur de perdre mon temps.
Tapper m'ennuie, alors vive les préfixes et les suffixes. Après je vais peut être parfois trop loin...
- On passe progressivement d'une représentation des données à une description des données. Par exemple (simpliste) le champ "size" d'un objet "array" peut-être représenté par un entier (non distinguable des autres entiers), ou bien décrit comme étant la taille du tableau (et donc pas un entier quelconque). La description implique entre autres que le champ size a une influence sur le nombre d'itérations d'un parcours du tableau, sur la place qu'occupe ce tableau en mémoire, etc. Si l'on se contente de représenter les données sans les décrire, alors c'est au programmeur d'interpréter leur signification dans sa tête.
- Ça serait bien que ce passage de représentation à description ne soit pas limité aux données, mais soit aussi appliqué au traitement des données. Là j'avoue que j'ai du mal à trouver rapidement un exemple pertinent, mais j'ai l'impression que ça revient à dire: ça serait bien que l'on puisse programmer des design patterns. Pour l'instant on ne peut pas les programmer, ce sont des concepts que le programmeur doit adapter à sa situation, mais avec des langages de plus haut niveau, ça serait possible.
Imagine, que tu utilise dans ton programme une liste chainée de couple de réels
{(3.5,5.4),(8.4,8.6),...}.
Imaginons que dans toutes les manipulations que tu effectue dessus, il se trouve que tu respectes les axiomes d'espaces vectoriels (ie. dans ta tête lorsque tu programmes, ta liste chainée est une liste de vecteurs).
Tu additionne tes couples, tu utilises des matrices, etc...
Un "prépocesseur" détecte alors que ta liste chainée est une liste de vecteurs d'un espace vectoriel. Il te propose d'emblée tout un tas de fonctions, il vérifie que ton code ne contient pas d'erreurs mathématiques, etc...
Par exemple, si tu modélise des agents sur un terrain (de foot par exemple), et que tu décris ceux-ci par des vecteurs, tu auras automatiquement la possibilité de leur donner une direction en radian, en degré, et un module.
Si tu modélise un balon, il suffira de le définir comme objet physique doté d'une masse (le type OBJET_MASSIQUE) et il analysera le contexte d'utilisation de ton balon pour toi, te proposant calcul de trajectoire, etc...
C'est plutôt vers cette idée.
Programmer, c'est créer de toutes pièces une structure cohérente (Coherens "qui tien ensemble"). Un truc issu de ton cerveau que tu crée à partir de rien, à part les primitives offertes par ton langage.
Là, par reconnaissance de forme, l'environnement de dev détecte les objets que tu veux décrire et t'assiste en t'offrant des structures toutes faites.
On aura une réprésentation standard du concept de client, d'entreprise, d'employé, de pièce, etc... Avec à chaque fois des propriétés et des contraintes.
C'est entre "écrire de la lib" et "concevoir un moteur de reconnaissance de forme".
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas tout compris
Posté par Ontologia (site web personnel) . En réponse au journal Le langage de mes rêves. Évalué à 3.
1/ Possibilité d'écrire des applications multithreadées assez facilement. Du fait que Lisaac reste un langage objet, on pourra utiliser les fonctionalités agent au minimum : par exemple, les clauses de déclanchement de comportement ne seront activés que pour la réception de messages (voir 3/).
Tu n'as plus à te préoccuper de mutex et autres monitors
2/ L'intégration d'un SQL/Objet dans le langage qui devient en passant persistant. Imagine que lors du développement d'une GPAO, tu as besoin d'écrire une fonction "réapro" te renvoyant l'ensemble des pièces que l'on doit racheter (le seuil de quantité minimal dans le stock a été enfoncé).
Là le compilateur, te vérifie le typage, gère la BDD pour toi (on architecturera la chose de sorte que l'on puisse interfacer tout SGBD avec)
Les requêtes peuvent se faire sur des objets ou des agents présent en mémoire : tu n'as plus à parcourir des collections afin de récupérer les infos que tu y veux.
Avec un tel système, en faisant un select bien sentie, tu peux sélectionner une liste de thread (des agents) correspondant à des critères précis, récupérer la liste de ceux-ci et leur envoyer un message.
Par exemple dans un logiciel de son multipiste, tu veux couper toutes les pistes utilisant l'effet phaser.
Tu généralise ton code :
C'est un exemple trop simple pour que cela soit vraiment intéressant, mais imagine des requêtes beaucoup plus complexes, où le fait de programmer la requêtes à la main en faisant une boucle listant une collection (ce qui suppose de prévoir les bonnes méthodes public te renvoyant les informations voulues, te facilitant la tâche, etc... ) n'est plus utile.
Tu peux gagner un temps fou !
3/ Les messages asynchrones seront fortement implantés dans le langage. Tu pourras envoyer des messages particulier, attendre un reply, demander la liste historique des messages de tel objet ou tel agent, etc...
Dans le modèle, les primitives présentés suffisent à permettre de définir, dans la librairie, un service de messages très complet.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: ça fonctionne
Posté par Ontologia (site web personnel) . En réponse au message dumper le flux des Jt (de TF1). Évalué à 2.
Moi j'ai fait ça :
Le script wcat
#/bin/sh
wget -q -O - $1
Le script eRadio :
#!/bin/sh
echo 'Nom du fichier cible : '$1-`date | awk '{print $1"-"$3"-"$2"-"$6}'`.rm
echo adresse source $2
echo ligne de commande :
echo mplayer -nosound -noframedrop -dumpfile /home/montaigne/Documents/Emissions/$1-`date | awk '{print $1"-"$3"-"$2"-"$6}'`.rm -dumpstream $2
mplayer -nosound -noframedrop -dumpfile /home/montaigne/Documents/Emissions/$1-`date | awk '{print $1"-"$3"-"$2"-"$6}'`.rm -dumpstream $2
Quand à chercher l'adresse, en général, il faut chercher les asf, asx, mms, .rm, rpm, rtsp . Tu finis pas trouver
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker