* Le lisaac dispose d'un gestionnaire de mémoire
Je sais très bien que Lisaac propose la gestion mémoire. Je critiquais seulement l'absence de gestion des modules et de la configuration.
Ces autres qualités que tu décris sont très bien, mais il manque des choses beaucoup plus basiques, c'est ca que je voulais rappeler.
déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein.
Autant de situation complexe qu'il faut effectivement les gérer. Des situations qui deviennent courantes dans les architectures complexes et distribuées... qui font qu'elles ne sont plus exceptionnelles et ne sont donc pas gérées par les exceptions. La gestion de ce type d'erreur doit faire pleinement parti des fonctionnalités du logiciel.
Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Soit les erreurs sont gérés par le code "métier", et dans ce cas elles ne sont pas gérés par les exceptions qui doivent être réservées aux comportements exceptionnels et non prévu. Donc non, leur efficacité n'est pas la priorité (même si c'est toujours mieux).
Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur.
Oué rien à voir avec un comportement exceptionnel donc.
Enfin se pose toujours le problème de la séquentialité : dans certains cas il n'est pas du tout envisageable de continuer l'exécution du programme là où il était rendu (il peut être continué par ailleur sans doute), tu proposes quoi si tu ne veux pas de rupture dans la séquentialité ?
Vous voulez tout faire mieux que tout le monde, et au final y'a rien d'utilisable qui sort. C'est dommage, y'a peut être des concepts intéressant dans Lisaac, mais inexploitable en l'état à toujours vouloir repousser les limites de l'état de l'art.
Quand Ontologia avait commencé à parler de Lisaac, il avait mis en avant les perfs liées aux optimisations globales faites par le compilateur. Pourquoi ne pas partir de cet apport pour essayer de faire un langage"quasi-industriel" ? Ne serais-ce que pour valider que c'est utilisable au quotidien l'optimisation globale. C'est justement là que ca devient intéressant : faire en sorte que ce soit utile pour tout le monde.
[^] # Re: beaucoup de blabla, peu d'info
Posté par TImaniac (site web personnel) . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 3.
Je sais très bien que Lisaac propose la gestion mémoire. Je critiquais seulement l'absence de gestion des modules et de la configuration.
Ces autres qualités que tu décris sont très bien, mais il manque des choses beaucoup plus basiques, c'est ca que je voulais rappeler.
déconnexion d'un agent, erreur d'un agent, coupure réseaux, refus de traiter une demande, etc... on peut en avoir plein.
Autant de situation complexe qu'il faut effectivement les gérer. Des situations qui deviennent courantes dans les architectures complexes et distribuées... qui font qu'elles ne sont plus exceptionnelles et ne sont donc pas gérées par les exceptions. La gestion de ce type d'erreur doit faire pleinement parti des fonctionnalités du logiciel.
Donc oui, la gestion des erreurs devra être **relativement** efficace. Les exceptions sont pour l'instant suffisantes, rien n'empêche d'essayer de trouver autre chose pour le future.
Soit les erreurs sont gérés par le code "métier", et dans ce cas elles ne sont pas gérés par les exceptions qui doivent être réservées aux comportements exceptionnels et non prévu. Donc non, leur efficacité n'est pas la priorité (même si c'est toujours mieux).
Dès que t'as une erreur, tu passes dans un état chargé de traiter l'erreur.
Oué rien à voir avec un comportement exceptionnel donc.
Enfin se pose toujours le problème de la séquentialité : dans certains cas il n'est pas du tout envisageable de continuer l'exécution du programme là où il était rendu (il peut être continué par ailleur sans doute), tu proposes quoi si tu ne veux pas de rupture dans la séquentialité ?
Vous voulez tout faire mieux que tout le monde, et au final y'a rien d'utilisable qui sort. C'est dommage, y'a peut être des concepts intéressant dans Lisaac, mais inexploitable en l'état à toujours vouloir repousser les limites de l'état de l'art.
Quand Ontologia avait commencé à parler de Lisaac, il avait mis en avant les perfs liées aux optimisations globales faites par le compilateur. Pourquoi ne pas partir de cet apport pour essayer de faire un langage"quasi-industriel" ? Ne serais-ce que pour valider que c'est utilisable au quotidien l'optimisation globale. C'est justement là que ca devient intéressant : faire en sorte que ce soit utile pour tout le monde.