* la syntaxe, c'est clairement une question de goût. Je viens du C++, et quand je suis passé à Lisaac, clairement au début c'est dur. En développant le mod pour Kate, je me suis rendu compte qu'en fait cette syntaxe est geniale, pour plusieurs raisons à mes yeux :
- très peu de règles de grammaire. En 10 minutes tu connais toute la syntaxe, même les finesses.
- conceptuelle et stricte : certes c'est abstrait et tranché, mais une fois maitrisé tu obtiens une expressivité sans faille. L'aspect tranché est une force, car le langage ne part pas n'importe où, meme si ca peut deplaire.
- La sémantique est nette car limitée à quelques trucs (pas besoin d'apprendre des centaines de notions), tout le reste est de la lib, donc il suffit de lire le code ou regarder la doc générée. Par exemple, le fait que les blocs soient à evaluation tardive t'assure que si tu as :
(cond1) && {cond2}, en lisant le slot '&&' de BOOLEAN (et surtout de TRUE et FALSE), tu es certain que le bloc {cond2} ne sera evalué que si cond1 est vraie. Je ne fais reference à aucune spec, à aucune norme, mais à la lib.
- tu n'es limité quasiment que par ton imagination. Tu veux avoir telle construction specifique à ton projet en cours ? en general tu peux la faire. C'est limite si tu ne crées pas un langage vraiment dédié à chaque projet, dans un formalisme qui est celui du Lisaac. En cela Lisaac se rapproche de meta-langages, mais cela n'engage que moi bien sûr.
* concurrence : pour l'instant le modèle COP n'est pas encore implémenté, mais tu peux voir à quoi ca ressemble dans le manuel, il y est décrit. Donc tous les tests sont mono-proc, meme si executés sur du multi-coeur/proc.
* interaction avec les bibliothèques : tu peux écrire directement du code C en lisaac, mais ca fout l'analyse de flot en l'air donc c'est pas genial. En plus il y a des restrictions si je me souviens bien, pour le typage. Après pour l'intégration de bibliothèques ayant leurs propres structures de données, tu peux le faire en ecrivant les prototypes associés à ces structures, avec la section Mapping pour les membres. Cela dit, il faudrait tester cela plus avant pour voir jusqu'où ca peut aller.
[^] # Re: license et divers points techniques
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 7.
* la syntaxe, c'est clairement une question de goût. Je viens du C++, et quand je suis passé à Lisaac, clairement au début c'est dur. En développant le mod pour Kate, je me suis rendu compte qu'en fait cette syntaxe est geniale, pour plusieurs raisons à mes yeux :
- très peu de règles de grammaire. En 10 minutes tu connais toute la syntaxe, même les finesses.
- conceptuelle et stricte : certes c'est abstrait et tranché, mais une fois maitrisé tu obtiens une expressivité sans faille. L'aspect tranché est une force, car le langage ne part pas n'importe où, meme si ca peut deplaire.
- La sémantique est nette car limitée à quelques trucs (pas besoin d'apprendre des centaines de notions), tout le reste est de la lib, donc il suffit de lire le code ou regarder la doc générée. Par exemple, le fait que les blocs soient à evaluation tardive t'assure que si tu as :
(cond1) && {cond2}, en lisant le slot '&&' de BOOLEAN (et surtout de TRUE et FALSE), tu es certain que le bloc {cond2} ne sera evalué que si cond1 est vraie. Je ne fais reference à aucune spec, à aucune norme, mais à la lib.
- tu n'es limité quasiment que par ton imagination. Tu veux avoir telle construction specifique à ton projet en cours ? en general tu peux la faire. C'est limite si tu ne crées pas un langage vraiment dédié à chaque projet, dans un formalisme qui est celui du Lisaac. En cela Lisaac se rapproche de meta-langages, mais cela n'engage que moi bien sûr.
* concurrence : pour l'instant le modèle COP n'est pas encore implémenté, mais tu peux voir à quoi ca ressemble dans le manuel, il y est décrit. Donc tous les tests sont mono-proc, meme si executés sur du multi-coeur/proc.
* interaction avec les bibliothèques : tu peux écrire directement du code C en lisaac, mais ca fout l'analyse de flot en l'air donc c'est pas genial. En plus il y a des restrictions si je me souviens bien, pour le typage. Après pour l'intégration de bibliothèques ayant leurs propres structures de données, tu peux le faire en ecrivant les prototypes associés à ces structures, avec la section Mapping pour les membres. Cela dit, il faudrait tester cela plus avant pour voir jusqu'où ca peut aller.