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.
Ca m'intéresse qu'est ce qui ne te plait pas? que proposes-tu de mieux/différent?
Ne penses-tu pas qu'il s'agit d'un autre sujet? peut-être l'occasion de faire un autre journal, ou tu développes cela?
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads"
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...
- 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)
- 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!
- 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).
- 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.
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!
[^] # Re: Pas tout compris
Posté par tene . 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?
Ne penses-tu pas qu'il s'agit d'un autre sujet? peut-être l'occasion de faire un autre journal, ou tu développes cela?
Mais le modèle est justement conçu pour que tu n'ais pas à penser aux threads"
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...
- 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)
- 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!
- 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).
- 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.
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!