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
[^] # 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