Autre métrique, beaucoup plus "brute", sur la même base de code:
% find -type f -exec cat {} \+ > /tmp/concat
sed 's/[0-9]//g' /tmp/concat | wc -c
3598252
% sed 's/[^0-9]//g' /tmp/concat | wc -c
173930
% sed 's/[^&"'\''(-_)=]//g' /tmp/concat | wc -c
672044
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi...
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation, au moins en C ou C++, et dans mon expérience. Mais honnêtement, je doute très fort que le langage change la donne tant que ça, ou que des expériences plus... digitales, je suppose, puissent faire mieux que doubler la valeur des chiffres, et dans ce cas, je doute fort qu'il y ait moins de (, ), -, =, ...
[^] # Re: Mouais, à voir
Posté par freem . En réponse au lien L’après Bépo : Ergo‐L. Évalué à 3.
Autre métrique, beaucoup plus "brute", sur la même base de code:
Moins de 5% des caractères sont des chiffres, contre plus de 18% qui sont des caractères accessibles sans modificateurs d'aucune sorte. En vrai, je m'attendais quand même à moins de caractères non alphanumériques et plus d'alpha, comme quoi...
Toujours est-il que très clairement, bloquer une ligne pour les chiffres est inefficace pour de la programmation, au moins en C ou C++, et dans mon expérience. Mais honnêtement, je doute très fort que le langage change la donne tant que ça, ou que des expériences plus... digitales, je suppose, puissent faire mieux que doubler la valeur des chiffres, et dans ce cas, je doute fort qu'il y ait moins de (, ), -, =, ...