tu sais pas ce qu'un compilo / une VM malins peuvent faire !
Mouais, c'est quelque chose que l'on entend répété ad nauseam depuis des années, mais en pratique il est rare qu'ils produisent un code plus performant qu'un premier jet bêtement codé à la main. Et de toutes manières, vu qu'en général on passe son temps à appeler des fonctions assez génériques qui ne sont donc pas optimisées pour le cas que l'on utilise, il n'y a pas grand chose d'optimisable par le compilateur...
on gère l'UTF-8 parce qu'on est plus en 1992 et les chinois aussi ont internet
OK, mais on le gère comment ? Faudrait se mettre d'accord sur ce qu'on veut avant de commencer à le gérer, sinon, on gère l'UTF-8 en entrée mais en produisant une sortie au petit bonheur la chance. Par exemple, dans le programme Python d'origine, le "\w" de la regexp ne va pas forcément donner les résultats que l'on attend. Avec les chiffres, par exemple, pour "Vol_714", on pourrait raisonnablement attendre "Lov_714" (comportement de mon programme) ou "Lov_417" comme résultat. Eh bien non, parce que le "\w" compte les chiffres et les "_" comme des caractères de mot, ça va donner "417_lov". Ah non, tiens, en plus ça donne "417_loV", une « erreur » supplémentaire :-) puisque les chiffres n'ont pas de casse et que dans ce cas le programme recopie les caractères tels qu'ils sont entrés).
Quant au Chinois, tu as choisi un bon exemple des emmerdements dans lesquels on est plongé par la complexité et la richesse d'Unicode si on veut le gérer dans son intégralité : dans un texte chinois, il n'y a pas de mots discernables et il n'y a pas de majuscules. Bim, les 2 principales spécification de notre zorglub sautent. Que fait-on ? On inverse tout le bloc d'idéogrammes entre 2 ponctuations, comme le programme d'origine le fait ? Ou pas ? Et surtout quel sens cela a-t-il de rentrer du chinois dans ce programme ?
on met pas de limite de taille arbitraire parce que 140 characters 640kB should be enough for everyone
Ben dans la langue de Franquin, le mot le plus long ayant 25 caractères, avec 64 on should be tranquille. Sinon, on rachètera un caractère supplémentaire pour écrire « 128 » à la place :-)
on a pas (ou alors pas fait exprès et on corrige :-p)
Oui, je constate que c'est le mode de développement actuel. « Allez, cette fonction a un bon nom, je vais l'utiliser ; on verra bien ce que ça donne : avec un peu de bol, ça marche. » ... « hop c'est bon, j'ai testé avec un exemple, ça roule. Ouais, non lire la spécification de la fonction, ce n'est pas la peine puisque ça marche pour l'instant. On verra bien si quelqu'un se plaint » ...
NB : j'ai bien conscience que dans les programmes présentés ici, il ne s'agit pas d'un logiciel critique ou d'un soft facturé 200 000 € à un malheureux pige^ Wclient, mais d'un petit jeu, donc ces reproches(?) ne leur sont pas destinés mais puisque je vois qu'on est d'humeur taquine... :-)
un truc qui fait-le-job-mais-en-fait-pas-pour-X-et-Y-t'as-qu'à-t'en-passer
Ben... au moins dans le truc que j'ai proposé, les caractéristiques et les limites sont assez clairement mises en avant.
Si on respecte ces règles, le comportement devrait être fiable1.
Si on prend le programme d'origine, pour les même données d'entrées, si on l'exécute dans un environnement différent (changement des locales) => BOUM. Alors il vaut peut-être mieux savoir ce qui est supporté et ce qui ne l'est pas par le programme et s'y tenir plutôt que d'avoir un comportement non prévu ou un crash.
là, logiquement, comme quand on fait une remarque sur l'orthographe, je ne doute pas que quelqu'un va me faire remarquer que j'ai oublier de traiter/spécifier un cas particulier :-) Ce que je veux dire, c'est que j'ai essayé d'une part d'être conscient des limites de ma version et de les mentionner et d'autre part de ne traiter qu'un type d'entrée restreint à ce qui fait sens, plutôt que de faire un truc qui est censé tout traiter sans limites, mais qui le fait mal ou de manière inattendue. Et le coup de la non-gestion assumée des signes « multiplier » et « diviser », c'est un geste politique de protestation contre la faute de goût d'avoir collé ces deux signes en plein milieu des majuscules accentuées :-). Sinon, c'est juste 2 fois 2 instructions à rajouter pour les gérer correctement. ↩
[^] # Re: Avec du poil aux pattes
Posté par gnx . En réponse au journal Esod mumixam !. Évalué à 5.
Mouais, c'est quelque chose que l'on entend répété ad nauseam depuis des années, mais en pratique il est rare qu'ils produisent un code plus performant qu'un premier jet bêtement codé à la main. Et de toutes manières, vu qu'en général on passe son temps à appeler des fonctions assez génériques qui ne sont donc pas optimisées pour le cas que l'on utilise, il n'y a pas grand chose d'optimisable par le compilateur...
OK, mais on le gère comment ? Faudrait se mettre d'accord sur ce qu'on veut avant de commencer à le gérer, sinon, on gère l'UTF-8 en entrée mais en produisant une sortie au petit bonheur la chance. Par exemple, dans le programme Python d'origine, le "\w" de la regexp ne va pas forcément donner les résultats que l'on attend. Avec les chiffres, par exemple, pour "Vol_714", on pourrait raisonnablement attendre "Lov_714" (comportement de mon programme) ou "Lov_417" comme résultat. Eh bien non, parce que le "\w" compte les chiffres et les "_" comme des caractères de mot, ça va donner "417_lov". Ah non, tiens, en plus ça donne "417_loV", une « erreur » supplémentaire :-) puisque les chiffres n'ont pas de casse et que dans ce cas le programme recopie les caractères tels qu'ils sont entrés).
Quant au Chinois, tu as choisi un bon exemple des emmerdements dans lesquels on est plongé par la complexité et la richesse d'Unicode si on veut le gérer dans son intégralité : dans un texte chinois, il n'y a pas de mots discernables et il n'y a pas de majuscules. Bim, les 2 principales spécification de notre zorglub sautent. Que fait-on ? On inverse tout le bloc d'idéogrammes entre 2 ponctuations, comme le programme d'origine le fait ? Ou pas ? Et surtout quel sens cela a-t-il de rentrer du chinois dans ce programme ?
Ben dans la langue de Franquin, le mot le plus long ayant 25 caractères, avec 64 on should be tranquille. Sinon, on rachètera un caractère supplémentaire pour écrire « 128 » à la place :-)
Oui, je constate que c'est le mode de développement actuel. « Allez, cette fonction a un bon nom, je vais l'utiliser ; on verra bien ce que ça donne : avec un peu de bol, ça marche. » ... « hop c'est bon, j'ai testé avec un exemple, ça roule. Ouais, non lire la spécification de la fonction, ce n'est pas la peine puisque ça marche pour l'instant. On verra bien si quelqu'un se plaint » ...
NB : j'ai bien conscience que dans les programmes présentés ici, il ne s'agit pas d'un logiciel critique ou d'un soft facturé 200 000 € à un malheureux pige^ Wclient, mais d'un petit jeu, donc ces reproches(?) ne leur sont pas destinés mais puisque je vois qu'on est d'humeur taquine... :-)
Ben... au moins dans le truc que j'ai proposé, les caractéristiques et les limites sont assez clairement mises en avant.
Si on respecte ces règles, le comportement devrait être fiable1 .
Si on prend le programme d'origine, pour les même données d'entrées, si on l'exécute dans un environnement différent (changement des locales) => BOUM. Alors il vaut peut-être mieux savoir ce qui est supporté et ce qui ne l'est pas par le programme et s'y tenir plutôt que d'avoir un comportement non prévu ou un crash.
là, logiquement, comme quand on fait une remarque sur l'orthographe, je ne doute pas que quelqu'un va me faire remarquer que j'ai oublier de traiter/spécifier un cas particulier :-) Ce que je veux dire, c'est que j'ai essayé d'une part d'être conscient des limites de ma version et de les mentionner et d'autre part de ne traiter qu'un type d'entrée restreint à ce qui fait sens, plutôt que de faire un truc qui est censé tout traiter sans limites, mais qui le fait mal ou de manière inattendue. Et le coup de la non-gestion assumée des signes « multiplier » et « diviser », c'est un geste politique de protestation contre la faute de goût d'avoir collé ces deux signes en plein milieu des majuscules accentuées :-). Sinon, c'est juste 2 fois 2 instructions à rajouter pour les gérer correctement. ↩