apprécies tu que tes impôts soient utilisés à maintenir ce genre de blague
Pour M, penses-tu qu'une réécriture dans un langage "commun" de toutes les règles + la vérification que ça tourne à l'identique + formation des utilisateurs + réécriture des codes qui communiquent avec d'autres systèmes, reviendrait moins cher que le simple maintien fonctionnel des moulinettes de calcul ?
Je n'en suis franchement pas sûr. Le M — avec ses défauts que tu relèves1 — permet une écriture simple des règles d'imposition. Tout bug dans ce système pourrait toucher potentiellement 37,1 millions de contribuables et conséquemment le budget de l'état... une décision de réécriture d'un tel système ne se fait pas à la légère (cf l'échec du projet Louvois pour la rémunération des militaires, et autres grands échecs).
On aurait un article disant que l'IRS publie un DSL pour le calcul des impôts aux États-Unis, tout le monde trouverait ça très bien et moderne (faire un langage qui permet d'exprimer simplement tes contraintes sous formes de règles que tu peux lier au code législatif et aux champs des documents de saisie des déclarations d'impôts...), il y aurait des 'if' et probablement ils auraient évité les petits trucs qui te turlupinent tant.
Je peux comprendre ton ras le bol sur des normes et des trucs anciens que tu te coltines encore maintenant (encore plus lorsque la définition de trucs modernes reprennent ces contraintes). Il y a des choses qui évoluent très très lentement, des installations certifiées auxquelles tu ne veux pas toucher... et aussi la résistance au changement de la part des gens. L'informatique a le grand inconvénient d'être en perpétuelle mutation avec beaucoup d'effets de modes ou de technos éphémères, ça complique nettement la construction de choses pérennes pour les gens qui doivent voir plus loin que le mois qui viens, et ça ralentit la prise en compte des nouveaux standards (note: je ne justifie en rien les raisons qui ont conduites à faire "DSN" et "FEC", je ne sais pas ce que c'est et je n'ai pas les billes pour me faire un avis) .
1 J'ai regardé le code de la moulinette Python, l'implémentation du posifitf() fait réellement un return int(value > 0). Je trouva ça con aussi, mais je n'étais pas devant le clavier au moment où il a fallu coder l'interpréteur M dans je ne sais quel langage d'origine, et je ne connais pas l'expérience du développeur au moment où il a écrit son code.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Sur M
Posté par lolop (site web personnel) . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à 8.
Très bas. Non.
Pour M, penses-tu qu'une réécriture dans un langage "commun" de toutes les règles + la vérification que ça tourne à l'identique + formation des utilisateurs + réécriture des codes qui communiquent avec d'autres systèmes, reviendrait moins cher que le simple maintien fonctionnel des moulinettes de calcul ?
Je n'en suis franchement pas sûr. Le
M— avec ses défauts que tu relèves1 — permet une écriture simple des règles d'imposition. Tout bug dans ce système pourrait toucher potentiellement 37,1 millions de contribuables et conséquemment le budget de l'état... une décision de réécriture d'un tel système ne se fait pas à la légère (cf l'échec du projet Louvois pour la rémunération des militaires, et autres grands échecs).On aurait un article disant que l'IRS publie un DSL pour le calcul des impôts aux États-Unis, tout le monde trouverait ça très bien et moderne (faire un langage qui permet d'exprimer simplement tes contraintes sous formes de règles que tu peux lier au code législatif et aux champs des documents de saisie des déclarations d'impôts...), il y aurait des 'if' et probablement ils auraient évité les petits trucs qui te turlupinent tant.
Je peux comprendre ton ras le bol sur des normes et des trucs anciens que tu te coltines encore maintenant (encore plus lorsque la définition de trucs modernes reprennent ces contraintes). Il y a des choses qui évoluent très très lentement, des installations certifiées auxquelles tu ne veux pas toucher... et aussi la résistance au changement de la part des gens. L'informatique a le grand inconvénient d'être en perpétuelle mutation avec beaucoup d'effets de modes ou de technos éphémères, ça complique nettement la construction de choses pérennes pour les gens qui doivent voir plus loin que le mois qui viens, et ça ralentit la prise en compte des nouveaux standards (note: je ne justifie en rien les raisons qui ont conduites à faire "DSN" et "FEC", je ne sais pas ce que c'est et je n'ai pas les billes pour me faire un avis) .
1 J'ai regardé le code de la moulinette Python, l'implémentation du
posifitf()fait réellement unreturn int(value > 0). Je trouva ça con aussi, mais je n'étais pas devant le clavier au moment où il a fallu coder l'interpréteur M dans je ne sais quel langage d'origine, et je ne connais pas l'expérience du développeur au moment où il a écrit son code.Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN