Les exceptions te cassent la séquentialité, le while non.
Bah oué, en même temps c'est leur objectif : le programme fait face à une situation exceptionnelle et non prévue, et il ne sait pas quoi faire : il lève une exception et casse la séquentialité plutôt que de continuer comme si de rien n'était au risque de faire des conneries.
Ca vaut ce que ca vaut, mais ca me paraît acceptable. T'as un meilleur comportement face à une telle situation ?
Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
Oué mais moi je viens pas poster un journal pour dire "oué nous on va inventer (c'est même pas on va chercher, non, on va inventer) un truc ouachement mieux parcque l'existant il est pourri". Alors pas la peine de renvoyer la balle, je pensais que vous aviez quelque chose d'intéressant à apporter. Je sais pas, peut être élaborer sur ce qui se cache derrière l'utilisation d'un jeu de règles ?
peut en fait être remplacé par "arrête de saouler, on cherche".
Ben j'ai envie de dire, arrêtez de nous saouler avec Lisaac tant que vous avez rien à dire à part nous informer que votre réunion de l'été dernier c'était cool.
Tu vois, on cherche, pour faire quelque chose de mieux.
L'objectif est louable, c'est d'ailleur assez excitant. M'enfin vous avez pas l'air de savoir ce que vous chercher effectivement à résoudre comme problème. Tu dis : les exceptions c'est mal, ca casse la séquentialité. Ok admettons, mais alors commencez par définir à quels critères doit coller un système de gestion idéal des erreurs. Bref, définissez l'objectif. De ce que je dois en déduire, un des critères c'est que les ce système idéal ne doit pas casser la séquentialité. Je propose de discuter de ce critère (cf début de mon post), ca me paraît intéressant.
Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Je suis bien d'accord. C'est pourquoi cela me paraît d'autant plus prétentieux que d'annoncer "nous on fait mieux qu'eux" alors que la comparaison est totalement faussée vu que vous faites abstraction de la plupart des contraintes auxquelles doivent faire face les langages "industriels".
Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
Peut être que c'est pas qu'un jump (GOTO) ?
Faut-il le rappeler, mais les exceptions sont censés être rares et être levées que dans des situations exceptionnelles ? Les perfomances sont-elles donc le critère primordial pour définir un gestionnaire d'erreur ?
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires.
Je dis pas que leurs conception/implémentation est élémentaire, je dis que ce sont des fonctionnalités élémentaires des langages modernes, des fonctions indispensables pour qu'un langage soit utilisable de nos jours. Comme la gestion mémoire, la sécurité, etc. Faire l'impasse dessus lors de la conception d'un langage amène à Lisaac : on se focalise sur les perfs en oubliant le reste, et on se congratule en regardant des benchs. Après on constate qu'il manque des trucs "élémentaires" pour en faire un vrai langage qui puisse espérer sortir d'un labo. On commence par se rassurer en disant : c'est normal, ca répond à un marché de niche (comprendre les utilisateurs qui n'ont pas besoins des choses élémentaires et uniquement des perfs). Ensuite on se dit que la gestion des erreurs c'est pas si mal, même dans l'embarqué, que la modularité c'est pas si mal dès qu'on travaille en équipe, et là on s'apercoit que les perfs "pures" c'est gentil mais ca sert à rien tout seul et que peut être qu'il aurait fallu y penser dès le départ.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Les shootout c'est pas la vrai vie, les shootouts se focalisent uniquement sur les perfs et pas sur les autres choses "élémentaires" qui font qu'un langage est de qualité.
Sinon, t'as déjà codé en Lisaac ?
Quand y'aura tous les trucs de base, oué pourquoi pas.
[^] # 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.
Bah oué, en même temps c'est leur objectif : le programme fait face à une situation exceptionnelle et non prévue, et il ne sait pas quoi faire : il lève une exception et casse la séquentialité plutôt que de continuer comme si de rien n'était au risque de faire des conneries.
Ca vaut ce que ca vaut, mais ca me paraît acceptable. T'as un meilleur comportement face à une telle situation ?
Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
Oué mais moi je viens pas poster un journal pour dire "oué nous on va inventer (c'est même pas on va chercher, non, on va inventer) un truc ouachement mieux parcque l'existant il est pourri". Alors pas la peine de renvoyer la balle, je pensais que vous aviez quelque chose d'intéressant à apporter. Je sais pas, peut être élaborer sur ce qui se cache derrière l'utilisation d'un jeu de règles ?
peut en fait être remplacé par "arrête de saouler, on cherche".
Ben j'ai envie de dire, arrêtez de nous saouler avec Lisaac tant que vous avez rien à dire à part nous informer que votre réunion de l'été dernier c'était cool.
Tu vois, on cherche, pour faire quelque chose de mieux.
L'objectif est louable, c'est d'ailleur assez excitant. M'enfin vous avez pas l'air de savoir ce que vous chercher effectivement à résoudre comme problème. Tu dis : les exceptions c'est mal, ca casse la séquentialité. Ok admettons, mais alors commencez par définir à quels critères doit coller un système de gestion idéal des erreurs. Bref, définissez l'objectif. De ce que je dois en déduire, un des critères c'est que les ce système idéal ne doit pas casser la séquentialité. Je propose de discuter de ce critère (cf début de mon post), ca me paraît intéressant.
Tu peux pas demander à 1 personne de faire les choses comme 200 ingénieurs d'une multinationale qui a plus de moyen que la recherche publique française...
Je suis bien d'accord. C'est pourquoi cela me paraît d'autant plus prétentieux que d'annoncer "nous on fait mieux qu'eux" alors que la comparaison est totalement faussée vu que vous faites abstraction de la plupart des contraintes auxquelles doivent faire face les langages "industriels".
Oh oui, les exceptions sont extrêmement consommatrice de ressource, c'est bien connu... c'est vrai qu'un jump, ça doit mettre ton processeur à genoux...
Peut être que c'est pas qu'un jump (GOTO) ?
Faut-il le rappeler, mais les exceptions sont censés être rares et être levées que dans des situations exceptionnelles ? Les perfomances sont-elles donc le critère primordial pour définir un gestionnaire d'erreur ?
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires.
Je dis pas que leurs conception/implémentation est élémentaire, je dis que ce sont des fonctionnalités élémentaires des langages modernes, des fonctions indispensables pour qu'un langage soit utilisable de nos jours. Comme la gestion mémoire, la sécurité, etc. Faire l'impasse dessus lors de la conception d'un langage amène à Lisaac : on se focalise sur les perfs en oubliant le reste, et on se congratule en regardant des benchs. Après on constate qu'il manque des trucs "élémentaires" pour en faire un vrai langage qui puisse espérer sortir d'un labo. On commence par se rassurer en disant : c'est normal, ca répond à un marché de niche (comprendre les utilisateurs qui n'ont pas besoins des choses élémentaires et uniquement des perfs). Ensuite on se dit que la gestion des erreurs c'est pas si mal, même dans l'embarqué, que la modularité c'est pas si mal dès qu'on travaille en équipe, et là on s'apercoit que les perfs "pures" c'est gentil mais ca sert à rien tout seul et que peut être qu'il aurait fallu y penser dès le départ.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Les shootout c'est pas la vrai vie, les shootouts se focalisent uniquement sur les perfs et pas sur les autres choses "élémentaires" qui font qu'un langage est de qualité.
Sinon, t'as déjà codé en Lisaac ?
Quand y'aura tous les trucs de base, oué pourquoi pas.