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.
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 ;)
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)
[^] # Re: Pas tout compris
Posté par tene . En réponse au journal Le langage de mes rêves. Évalué à 3.
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.
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 ;)
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)