Mais pour rester dans la discution en cours : « on en à rien à foutre »...
Peut-être que les contrats hérités de Lisaac ou autre sont mieux que les assertions, mais ça ne change pas le fait qu'ils ne détecterons pas les bugs qui me prennent le plus de temps à corriger et qui parfois nécéssitent des techniques de debuggage particulière telles que de multiple compilations avec génération de logs.
Donc on en reviens au même point, dire que la compilation par module n'est pas utile et vive les optimisations globales, c'est réducteur. Et, à mon avis, Lisaac n'est pour l'instant pas un bon choix de ce point de vue pour un gros projet.
On a ici un bon exemple de ce que j'ai du mal à apprécier dans les journeaux et news sur Lisaac et que j'ai éssayer plusieur fois d'expliquer. Si on prend le message de NB http://linuxfr.org/comments/1087340.html#1087340 il dit à propos de la compilation séparée :
«On ne le fera jamais. Cela ne sert à rien. On rend possible de faire un .o mais le but n'est pas d'en lier plusieurs mais sois de faire des plugin soit de se lier à du code autre.»
C'est un point de vue relativement tranché, auquel TIM répond par :
«Donc là t'es en train de dire à tous les utilisateurs :
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.»
C'est une réponse un peu provocante mais qui n'a rien de particulier dans ce journal, ils donne des cas ou l'on a envie de faire de la compilation séparée. Ce qu'on peut lui reprocher c'est de ne pas vraiment détailler pourquoi on veut une compilation séparée.
Mais NB montre qu'il a bien compris le problème quand on voit sa réponse, donc pas de problème de clartée :
«Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.»
C'est encore très tranché. Et surtout un détail qui m'avait échapé, il dit que lisaac se compile en quelques secondes mais que GCC fait ramer le tout. Donc en gros lisaac c'est plus que quelques secondes de compilation... C'est quelques minutes pour un «petit» programme de 50kloc. Sur un gros projets ça va devenir ingérable.
Et il ajoute : «les bugs sont attrapé par le compilo en majorité.» à quoi je lui répond que tout les bugs ne peuvent pas être attrapé de cette manière.
Et la ça dérape, avec quelques messages pour montrer que sur un gros projets une compilation globale c'est pas gérable dans tous les cas, et expliquer qu'il y a des bug que l'on ne peut pas débugger sans refaire plusieurs compilation, on obtient comme réponses à côté de la plaque.
NB admet quand même que «C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.»
Sauf que quelques minute peu devenir une heure ou plus sur un gros projet, et on a l'impression qu'il admet plus qu'il ne faut pas faire du debuggage test/erreur même s'il n'y a que ça de possible.
Ensuite, après avoir détailler le cas d'exemple pour mieux faire comprendre, on se prend encore une réponse qui n'a rien à voir avec le shmilblic suivit de :
«Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".»
La c'est de la mauvaise foi. On dit que pour un gros projet, avec une compilation longue c'est un problème, et on me répond que pour un autre projet, bien plus petit, la compilation est rapide !!!
Si je vais voir un vendeur en lui disant «les pommes que vous m'avez vendues sont pourries» il ne vas pas me répondre «oui mais mes poires que j'ai vendue à votre voisin ne le sont pas». On s'en fou que lisaac ce compile super vite, nous on va le compiler au pire une fois, alors que notre projet qu'on doit débugger et qui prend une heure à compiler, on va devoir le faire plusieur fois par jour peut-être.
Il y a une petite lueur d'espoir apres. Alors que le fil est partit d'une affirmation comme quoi la compilation séparée ne sert à rien et date de la préhistoire, on obtient un :
«A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.»
On se dit que peut-être sur ce cas, un jour ça marchera. Mais en même temps, on nous dit souvent qu'il est domage qu'il n'y ait pas plus de gens à dévelloper en lisaac... Moi, ça ne me donne pas envie.
Et la tu arrive pour me dire que «oui mais, au lieu de mettre des assertions, tu met des contrats hérité, c'est bien mieux»
Sauf que ça n'a aucun rapport... Les bugs que l'on peut détecter par contrat on peut aussi les détecter par assertion. Au pire je vais oublier de mettre une assertion et ton héritage la met automatiquement. Mais ça ne change rien au problème des bugs qui ne peuvent pas être détecter avec c'est méthodes.
C'est super les contrats pour vérifier les bornes ou les invariants ou autres, mais ça ne marche pas pour tout. Je me suis fait chiez à expliquer un exemple ou il n'y a pas vraiment l choix et ou un contrat qu'il soit hériter ou pas ne change rien.
Ça donne vraiment l'impression classique des discution autour de lisaac avec sa communauté. Quand on montre un problème lié à Lisaac, ça commence par une levée de bouclier dans le genre «Lisaac c'est génial, nous on fait les chose bien les autres le font mal» et ensuite si on réussit à montrer que vous avez tord, on arrive parfois à vous arrachez un petit «tu as peut-être vaguement raison dans un univers parallel» et le plus souvent on à le droit à un «mais nous on a ce truc qui n'a rien à voir et qui ne résoud pas ton problème mais qui est vachement cool».
Je suis désolé, mais moi ça ne me donne pas envie. C'est pourtant pas compliqué d'expliqué que «pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets».
Ensuite soit tu rajoute «on admet le problème mais notre cible actuelle est les projets de taille raisonable qui ne sont pas génés par cela» ou «on y réfléchit et ce sera implémenter dans le futur».
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
PS: Je ne prétend pas détenir la vérité absolue et j'admet que ce que je dis dans ce message est mon interprétation de ce qui c'est dit ici. Mais si j'ai mal interpreté vos propos, je ne suis peut-être pas le seul, et si Lisaac est autant un sujet à troll c'est peut-être que l'on est nombreux à pas vous comprendre correctement.
[^] # Re: Surprise
Posté par beagf . En réponse au journal Lisaac: sorti de la 0.39beta. Évalué à 3.
Peut-être que les contrats hérités de Lisaac ou autre sont mieux que les assertions, mais ça ne change pas le fait qu'ils ne détecterons pas les bugs qui me prennent le plus de temps à corriger et qui parfois nécéssitent des techniques de debuggage particulière telles que de multiple compilations avec génération de logs.
Donc on en reviens au même point, dire que la compilation par module n'est pas utile et vive les optimisations globales, c'est réducteur. Et, à mon avis, Lisaac n'est pour l'instant pas un bon choix de ce point de vue pour un gros projet.
On a ici un bon exemple de ce que j'ai du mal à apprécier dans les journeaux et news sur Lisaac et que j'ai éssayer plusieur fois d'expliquer. Si on prend le message de NB http://linuxfr.org/comments/1087340.html#1087340 il dit à propos de la compilation séparée :
«On ne le fera jamais. Cela ne sert à rien. On rend possible de faire un .o mais le but n'est pas d'en lier plusieurs mais sois de faire des plugin soit de se lier à du code autre.»
C'est un point de vue relativement tranché, auquel TIM répond par :
«Donc là t'es en train de dire à tous les utilisateurs :
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.»
C'est une réponse un peu provocante mais qui n'a rien de particulier dans ce journal, ils donne des cas ou l'on a envie de faire de la compilation séparée. Ce qu'on peut lui reprocher c'est de ne pas vraiment détailler pourquoi on veut une compilation séparée.
Mais NB montre qu'il a bien compris le problème quand on voit sa réponse, donc pas de problème de clartée :
«Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.»
C'est encore très tranché. Et surtout un détail qui m'avait échapé, il dit que lisaac se compile en quelques secondes mais que GCC fait ramer le tout. Donc en gros lisaac c'est plus que quelques secondes de compilation... C'est quelques minutes pour un «petit» programme de 50kloc. Sur un gros projets ça va devenir ingérable.
Et il ajoute : «les bugs sont attrapé par le compilo en majorité.» à quoi je lui répond que tout les bugs ne peuvent pas être attrapé de cette manière.
Et la ça dérape, avec quelques messages pour montrer que sur un gros projets une compilation globale c'est pas gérable dans tous les cas, et expliquer qu'il y a des bug que l'on ne peut pas débugger sans refaire plusieurs compilation, on obtient comme réponses à côté de la plaque.
NB admet quand même que «C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.»
Sauf que quelques minute peu devenir une heure ou plus sur un gros projet, et on a l'impression qu'il admet plus qu'il ne faut pas faire du debuggage test/erreur même s'il n'y a que ça de possible.
Ensuite, après avoir détailler le cas d'exemple pour mieux faire comprendre, on se prend encore une réponse qui n'a rien à voir avec le shmilblic suivit de :
«Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".»
La c'est de la mauvaise foi. On dit que pour un gros projet, avec une compilation longue c'est un problème, et on me répond que pour un autre projet, bien plus petit, la compilation est rapide !!!
Si je vais voir un vendeur en lui disant «les pommes que vous m'avez vendues sont pourries» il ne vas pas me répondre «oui mais mes poires que j'ai vendue à votre voisin ne le sont pas». On s'en fou que lisaac ce compile super vite, nous on va le compiler au pire une fois, alors que notre projet qu'on doit débugger et qui prend une heure à compiler, on va devoir le faire plusieur fois par jour peut-être.
Il y a une petite lueur d'espoir apres. Alors que le fil est partit d'une affirmation comme quoi la compilation séparée ne sert à rien et date de la préhistoire, on obtient un :
«A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.»
On se dit que peut-être sur ce cas, un jour ça marchera. Mais en même temps, on nous dit souvent qu'il est domage qu'il n'y ait pas plus de gens à dévelloper en lisaac... Moi, ça ne me donne pas envie.
Et la tu arrive pour me dire que «oui mais, au lieu de mettre des assertions, tu met des contrats hérité, c'est bien mieux»
Sauf que ça n'a aucun rapport... Les bugs que l'on peut détecter par contrat on peut aussi les détecter par assertion. Au pire je vais oublier de mettre une assertion et ton héritage la met automatiquement. Mais ça ne change rien au problème des bugs qui ne peuvent pas être détecter avec c'est méthodes.
C'est super les contrats pour vérifier les bornes ou les invariants ou autres, mais ça ne marche pas pour tout. Je me suis fait chiez à expliquer un exemple ou il n'y a pas vraiment l choix et ou un contrat qu'il soit hériter ou pas ne change rien.
Ça donne vraiment l'impression classique des discution autour de lisaac avec sa communauté. Quand on montre un problème lié à Lisaac, ça commence par une levée de bouclier dans le genre «Lisaac c'est génial, nous on fait les chose bien les autres le font mal» et ensuite si on réussit à montrer que vous avez tord, on arrive parfois à vous arrachez un petit «tu as peut-être vaguement raison dans un univers parallel» et le plus souvent on à le droit à un «mais nous on a ce truc qui n'a rien à voir et qui ne résoud pas ton problème mais qui est vachement cool».
Je suis désolé, mais moi ça ne me donne pas envie. C'est pourtant pas compliqué d'expliqué que «pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets».
Ensuite soit tu rajoute «on admet le problème mais notre cible actuelle est les projets de taille raisonable qui ne sont pas génés par cela» ou «on y réfléchit et ce sera implémenter dans le futur».
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
PS: Je ne prétend pas détenir la vérité absolue et j'admet que ce que je dis dans ce message est mon interprétation de ce qui c'est dit ici. Mais si j'ai mal interpreté vos propos, je ne suis peut-être pas le seul, et si Lisaac est autant un sujet à troll c'est peut-être que l'on est nombreux à pas vous comprendre correctement.