* Pour les exceptions : c'est des GOTOS, et les GOTOS, c'est mal
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?
Certes, mais contrairement aux exceptions, il n'y a pas un décrochement complet du programme. Les exceptions te cassent la séquentialité, le while non.
Alors oui, une machine ce n'est qu'un GOTO(adresse) + écriture/lecture, mais y'a différentes manières de le faire.
* Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'
j'ai adapté le raisonnement à mon principal lecteur (je prends de l'avance sur le coup des chercheurs).
Enfin, si t'as quelque chose de constructif à ajouter sur la gestion des erreurs, on sera ravi de voir ce que c'est. Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?
le "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" peut en fait être remplacé par "arrête de saouler, on cherche".
Si je te dit que c'est un défi à relever c'est que c'est pas encore fait. On le dit pour montrer la direction dans laquelle on va et si ça intéresse des gens, ils peuvent venir donner leur avis. Je ne parle pas de toi qui vient juste dire 'c'est naze" - même si c'est un avis.
*Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille
allons donc, il faut de tout pour faire un monde...
Mais la recherche, c'est pas mal plus intéressant que de continuer a implémenter des trucs bricolés (façon exception). Tu vois, on cherche, pour faire quelque chose de mieux. Toi tu dois bien te "branler la nouille" sur autre chose...
sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains.
J'ai pas dis ça, c'est pour replacer les choses dans leur contexte. 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...
Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
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...
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires. On essaie de faire quelque chose d'innovant et ça prend du temps.
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Sinon, t'as déjà codé en Lisaac ?
parceque si ce n'est pas le cas, je t'invite cordialement à le faire et à remonter les erreurs/bugs. On a toujours besoin de gens de bonnes volontés pour faire avancer un projet.
[^] # Re: beaucoup de blabla, peu d'info
Posté par BigRatonTon . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 3.
Pour moi les exceptions offrent une sémantique beaucoup plus riche que les gotos, ont un usage beaucoup plus spécialisé, et n'ont au final pas grand chose à voir avec. Nan parcque sinon si on va par là, une boucle while, c'est un GOTO conditionnel non ?
Certes, mais contrairement aux exceptions, il n'y a pas un décrochement complet du programme. Les exceptions te cassent la séquentialité, le while non.
Alors oui, une machine ce n'est qu'un GOTO(adresse) + écriture/lecture, mais y'a différentes manières de le faire.
* Après il est vrai que la gestion des erreurs fait parti des défis...
C'est pour ca qu'il me semble intéressant d'en discuter. Les exceptions je suis bien d'accord que c'est pas la panacée, mais en attendant c'est ce qu'il se fait de mieux. Donc voilà, si on peut faire avancer le débat là dessus plutôt que de faire des rapides raisonnements à 2 francs 'exception = goto donc cmal'
j'ai adapté le raisonnement à mon principal lecteur (je prends de l'avance sur le coup des chercheurs).
Enfin, si t'as quelque chose de constructif à ajouter sur la gestion des erreurs, on sera ravi de voir ce que c'est. Parceque tu parles de débat, mais tu ne le fais pas plus avancé que mon collègue ou moi...
*Les modules cassent l'optimisation globale : oui, c'est donc un défi a relevé. Si t'es motivé tu peux le faire.
Je vois que t'es aussi enclin à répondre aux questions que ton collègue : quel intérêt de venir nous dire "on s'est réuni et on a discuter de la modularité' si tout ce que vous avez à dire au final c'est "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" ?
le "oué ca sera fait, plus tard, t'as qu'à le faire si t'es motivé" peut en fait être remplacé par "arrête de saouler, on cherche".
Si je te dit que c'est un défi à relever c'est que c'est pas encore fait. On le dit pour montrer la direction dans laquelle on va et si ça intéresse des gens, ils peuvent venir donner leur avis. Je ne parle pas de toi qui vient juste dire 'c'est naze" - même si c'est un avis.
*Je te rappelle aussi que le Lisaac est **principalement** développé par une seule personne. Pas par une équipe de 200 ingénieurs de chez microsoft (qui se font battre par le Lisaac sur le terrain des performances, soit dit en passant)
Voilà tout est résumé dans cette phrase, notamment entre les parenthèses. On à affaire à des chercheurs qui se branle la nouille
allons donc, il faut de tout pour faire un monde...
Mais la recherche, c'est pas mal plus intéressant que de continuer a implémenter des trucs bricolés (façon exception). Tu vois, on cherche, pour faire quelque chose de mieux. Toi tu dois bien te "branler la nouille" sur autre chose...
sur un langage révolutionnaire-parcquil-est-plus-performant-que-ce-que-font-ces-connards-de-ricains.
J'ai pas dis ça, c'est pour replacer les choses dans leur contexte. 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...
Les perfs "brutes" c'est gentil, mais Lisaac est un langage qui ne propose pas de gestion des erreurs, qui ne propose pas de gestion des modules, bref des choses élémentaires qui ont directement un impact sur les perfs : alors revenez avec un langage un minimum complet, après on refera les benchs et on comparera les perfs avec ce que fait MS (ou autre hein, y'a pas que MS).
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...
De plus, la gestion d'erreur n'est PAS élémentaire. Les modules ne sont PAS non plus élémentaires. On essaie de faire quelque chose d'innovant et ça prend du temps.
Ou alors arrêtez la prétention à 2 francs, les communiqués publicitaires vides de contenus intéressants, et montrez nous ce qui nous (moi en tout cas) intéresse : des critiques ettayés de l'existant, des idées d'améliorations possibles, avec exemples à l'appui, etc.
on va bientôt refaire les shootout benchmark. tu verras par toi même.
Sinon, t'as déjà codé en Lisaac ?
parceque si ce n'est pas le cas, je t'invite cordialement à le faire et à remonter les erreurs/bugs. On a toujours besoin de gens de bonnes volontés pour faire avancer un projet.
Bonne soirée