Je pense que comme pas mal de monde ici, je trouve ce langage vraiment prometteur, mais pas question de faire quelque chose avec tant que ça ne sera pas entièrement libre.
Sinon j'espère que le langage ne tombera pas dans un certain nombre d'écueils (en plus de la non-'libricité' - ça existe ça??!) : non standardisation/normalisation, pas de librairie standard, etc....
Parmi les écueils possibles, celui qui me semble être assez récurrent à l'INRIA, c'est de faire un langage avec des idées très puissantes (donc potentiellement très bon), mais qui néglige tout le reste qui n'est pas très conceptuellement intéressant, mais qui est pourtant indispensable dans la vraie vie (d'un codeur :).
Je m'explique : j'ai découvert OcamL dans mon école d'ingé, dans le cadre de la programmation fonctionnelle, et ça m'a bien plu. Plus tard sur LinuxFR j'ai appris qu'il était multi-paradigmique, qu'il pouvait être interprété, compilé ou dans une VM. Il montait encore dans mon estime. Pourtant plus tard, alors que j'errais sur le Net à la recherche d'un éventuel langage pour de futurs projets, je me suis aperçu qu'il avait l'air de manquer des choses assez essentielles (à mon sens) dans le langage :
- j'aime les systèmes de plugins, mais d'après la doc, on ne peut charger de module OcamL qu'en mode VM. Du coup c'est assez décevant, je dois me passer du mode compilé (le coup des 3 modes d'exécution est donc un peu faux). Peut-être qu'on peut charger des modules en C ??(mais alors ce n'est plus un programme en OcamL à proprement parler)
- je m'intéresse aux système multi-tâches, mais là encore déception : il y a des lightweight threads, c'est très bien, mais nulle trace de vrais threads qui permettent d'utiliser plusieurs processeur à la fois.
Je précise que je ne suis pas un spécialiste OcamL, donc j'ai très bien pu louper quelque chose (n'hésitez pas à me le signaler). Mais si je ne me trompe pas sur les 2 points plus haut, c'est assez gênant. Parce que s'il n'y avait pas de parser XML ou de bibliothèque d'envoi de mails par exemple, et ben il suffirait de les coder (du moment où il y a la gestion des fichiers ou des sockets pour mes exemples, ou qu'on peut binder avec du C), mais dans les cas que j'ai cités, il faudrait toucher au langage lui même, ce qui n'est plus du même niveau !!
J'ai vu les mêmes manques dans SmartEiffel (coder aussi par l'INRIA). Attention, les gars de l'INRIA sont certainement très compétants et je n'ai pas l'intention de casser du logiciel libre (au contraire). Mais d'un autre côté, on voit souvent des gens vanter leur outil de prédilection (moi le premier), et parfois se plaindre qu'il n'est pas assez utilisé alors qu'il est bien mieux que tout le reste sur tous les plans. Alors que ce n'est pas vrai : en C je vais peux être pas avoir des super objet dynamique sans Virtual Table, avec analyse du flot d'exécution le tout avec des paradigme de haut niveau etc..., mais si je veux faire des plugins, des threads, et ben je pourrais, je ne serais pas bloquer par le langage. Le seul truc qu'on ne pourrait pas techniquement faire sans VM serait une exécution 'sandboxée'. Alors évidemment on peut faire des tas de programmes très bien sans plugins ni threads, mais c'est dommage que ces langages modernes ne permettent pas ce que peuvent des langages vieillissants.
D'ailleurs même si ça me fait un peu mal de le dire, en parcourant rapidement la doc de Mono, je n'ai pas vu de manque si cruel. Ne vous méprenez pas, Mono n'est pas (encore?) installé sur ma machine, je ne fais pas de prosélytisme.
Voilà, en espérant que mes remarques soient constructives.
# J'espère....
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 8.
Sinon j'espère que le langage ne tombera pas dans un certain nombre d'écueils (en plus de la non-'libricité' - ça existe ça??!) : non standardisation/normalisation, pas de librairie standard, etc....
Parmi les écueils possibles, celui qui me semble être assez récurrent à l'INRIA, c'est de faire un langage avec des idées très puissantes (donc potentiellement très bon), mais qui néglige tout le reste qui n'est pas très conceptuellement intéressant, mais qui est pourtant indispensable dans la vraie vie (d'un codeur :).
Je m'explique : j'ai découvert OcamL dans mon école d'ingé, dans le cadre de la programmation fonctionnelle, et ça m'a bien plu. Plus tard sur LinuxFR j'ai appris qu'il était multi-paradigmique, qu'il pouvait être interprété, compilé ou dans une VM. Il montait encore dans mon estime. Pourtant plus tard, alors que j'errais sur le Net à la recherche d'un éventuel langage pour de futurs projets, je me suis aperçu qu'il avait l'air de manquer des choses assez essentielles (à mon sens) dans le langage :
- j'aime les systèmes de plugins, mais d'après la doc, on ne peut charger de module OcamL qu'en mode VM. Du coup c'est assez décevant, je dois me passer du mode compilé (le coup des 3 modes d'exécution est donc un peu faux). Peut-être qu'on peut charger des modules en C ??(mais alors ce n'est plus un programme en OcamL à proprement parler)
- je m'intéresse aux système multi-tâches, mais là encore déception : il y a des lightweight threads, c'est très bien, mais nulle trace de vrais threads qui permettent d'utiliser plusieurs processeur à la fois.
Je précise que je ne suis pas un spécialiste OcamL, donc j'ai très bien pu louper quelque chose (n'hésitez pas à me le signaler). Mais si je ne me trompe pas sur les 2 points plus haut, c'est assez gênant. Parce que s'il n'y avait pas de parser XML ou de bibliothèque d'envoi de mails par exemple, et ben il suffirait de les coder (du moment où il y a la gestion des fichiers ou des sockets pour mes exemples, ou qu'on peut binder avec du C), mais dans les cas que j'ai cités, il faudrait toucher au langage lui même, ce qui n'est plus du même niveau !!
J'ai vu les mêmes manques dans SmartEiffel (coder aussi par l'INRIA). Attention, les gars de l'INRIA sont certainement très compétants et je n'ai pas l'intention de casser du logiciel libre (au contraire). Mais d'un autre côté, on voit souvent des gens vanter leur outil de prédilection (moi le premier), et parfois se plaindre qu'il n'est pas assez utilisé alors qu'il est bien mieux que tout le reste sur tous les plans. Alors que ce n'est pas vrai : en C je vais peux être pas avoir des super objet dynamique sans Virtual Table, avec analyse du flot d'exécution le tout avec des paradigme de haut niveau etc..., mais si je veux faire des plugins, des threads, et ben je pourrais, je ne serais pas bloquer par le langage. Le seul truc qu'on ne pourrait pas techniquement faire sans VM serait une exécution 'sandboxée'. Alors évidemment on peut faire des tas de programmes très bien sans plugins ni threads, mais c'est dommage que ces langages modernes ne permettent pas ce que peuvent des langages vieillissants.
D'ailleurs même si ça me fait un peu mal de le dire, en parcourant rapidement la doc de Mono, je n'ai pas vu de manque si cruel. Ne vous méprenez pas, Mono n'est pas (encore?) installé sur ma machine, je ne fais pas de prosélytisme.
Voilà, en espérant que mes remarques soient constructives.