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