Je pense qu'il faut faire une distinction entre ce qu'est Lisaac et ce que tu attends d'un outil de travail. Lisaac, si j'ai bien compris, c'est de la recherche, avec des objectifs plus ou moins bien définis. Ce que tu attends d'un outil de travail, c'est par exemple les garanties de sécurité fournies par l'utilisation d'une machine virtuelle, un framework complet, une bibliothèque fournie, etc.
Attaquer Lisaac sur ces points n'est pas pertinent, sauf s'il s'agit d'attaquer ses objectifs. Si tu nous dit que Lisaac a parmis ses objectifs quelque chose qui le rend intrinsèquement moins XXX que Java, alors c'est une remarque intéressante. Si tu nous dit que dans l'implémentation actuelle, il est moins XXX que Java, qu'est-ce que ça signifie ? (remplacer XXX par l'épithète de son choix)
Ça ne peut signifier qu'une chose, c'est qu'étant donné l'état "en développement" de Lisaac, tu ne le choisirais pas pour un projet sérieux à but productif. J'ose espérer que personne ne choisirait un langage dans un stade aussi expérimental pour ça.
Si on commence à flinguer tous les nouveaux langages qui ne sortent pas directement aussi aboutis que le framework Java, où va-t-on ? D'ailleurs, même si quelqu'un sortait un langage aussi abouti que Java du jour au lendemain, on lui ferait le reproche qu'il n'existe pas de programmeurs sachant l'utiliser.
Maintenant, sur le point précis dont on parlait, parce que je m'égare: le langage Lisaac, comme le langage Java, permet d'incorporer du code natif facilement. La plateforme Lisaac, à l'opposée de la plateforme Java, ne permet (peut-être) pas de limiter cela. Cependant, la plateforme actuelle, on s'en fiche un peu, ce qui est intéressant c'est les concepts. Je n'ai pas vu dans ce qu'il a été dit de Lisaac quoi que ce soit qui me laisse penser qu'on ne puisse pas compiler à destination d'une machine virtuelle, et donc profiter des mêmes bénéfices en matière de sécurité. Mais c'est de ça qu'il serait intéressant de discuter, pas du nombre de bugs ou de fonctionnalités de l'implémentation actuelle, qui est du code destiné à la recherche.
Un chercheur n'est pas une équipe d'ingénieurs, enfin. Si les concepts sont suffisamment intéressants et forment un tout cohérent, alors les ingénieurs prendront le relai et en feront quelque chose de fini.
(L'ingénieur peut être la même personne que le chercheur, mais ce n'est pas la même phase du travail de "recherche et développement")
[^] # Re: C'est trop compliqué !
Posté par Yusei (Mastodon) . En réponse au journal Des langages de haut niveau. Évalué à 3.
Attaquer Lisaac sur ces points n'est pas pertinent, sauf s'il s'agit d'attaquer ses objectifs. Si tu nous dit que Lisaac a parmis ses objectifs quelque chose qui le rend intrinsèquement moins XXX que Java, alors c'est une remarque intéressante. Si tu nous dit que dans l'implémentation actuelle, il est moins XXX que Java, qu'est-ce que ça signifie ? (remplacer XXX par l'épithète de son choix)
Ça ne peut signifier qu'une chose, c'est qu'étant donné l'état "en développement" de Lisaac, tu ne le choisirais pas pour un projet sérieux à but productif. J'ose espérer que personne ne choisirait un langage dans un stade aussi expérimental pour ça.
Si on commence à flinguer tous les nouveaux langages qui ne sortent pas directement aussi aboutis que le framework Java, où va-t-on ? D'ailleurs, même si quelqu'un sortait un langage aussi abouti que Java du jour au lendemain, on lui ferait le reproche qu'il n'existe pas de programmeurs sachant l'utiliser.
Maintenant, sur le point précis dont on parlait, parce que je m'égare: le langage Lisaac, comme le langage Java, permet d'incorporer du code natif facilement. La plateforme Lisaac, à l'opposée de la plateforme Java, ne permet (peut-être) pas de limiter cela. Cependant, la plateforme actuelle, on s'en fiche un peu, ce qui est intéressant c'est les concepts. Je n'ai pas vu dans ce qu'il a été dit de Lisaac quoi que ce soit qui me laisse penser qu'on ne puisse pas compiler à destination d'une machine virtuelle, et donc profiter des mêmes bénéfices en matière de sécurité. Mais c'est de ça qu'il serait intéressant de discuter, pas du nombre de bugs ou de fonctionnalités de l'implémentation actuelle, qui est du code destiné à la recherche.
Un chercheur n'est pas une équipe d'ingénieurs, enfin. Si les concepts sont suffisamment intéressants et forment un tout cohérent, alors les ingénieurs prendront le relai et en feront quelque chose de fini.
(L'ingénieur peut être la même personne que le chercheur, mais ce n'est pas la même phase du travail de "recherche et développement")