Je comprends pas un mot de russe, pourtant les russes le parlent depuis leur plus tendre enfance.
S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.
"Les identifiants sélectionnés sont, parmis les identifiants, ceux qui sont paires". Je ne vois pas ce qui perturbe. Le { | | ... } quand tu viens d'un autre langage ça surprend si tu découvre et après 2h c'est assimilé, soit tu ne découvre pas.
J’ai trop vu cet argument appliqué à perl pour y accorder la moindre crédibilité. Le problème est que oui, une structure, ça s’assimile assez vite, mais souvent elle n’est pas seule. Et qu’à force, on se retrouve avec des choses qui sont peut-être lisibles pour un spécialiste, mais :
- je ne suis pas convaincu que ce soit plus lisible qu’une forme moins concise, même pour le spécialiste en question
- c’est clairement moins lisible pour un non-spécialiste
Pourtant tu interdit certaines boucles et certaines autres constructions pour des raisons de lisibilité. On est loin, très loin, de parties du C++ comme la programmation par template.
Encore une fois, tu vas largement au-delà de ce que j’ai dit. Je dis qu’une construction qui n’apporte que de la concision (on est donc à des années lumières de ce qu’apportent les templates en C++ ou la métaprogrammation) n’apporte pas forcément de la lisibilité. Que
for(auto item : maliste) // super
réussit à être à la fois plus lisible et plus concis en toute circonstance, mais que
int a = mafonction(b,c)?4:mafonction2(b+c);
est en général inférieur en lisibilité à
int a;
if(mafonction(b,c)) {
a = 4;
}
else {
a = mafonction2(b + c);
}
En clair, je dis qu’utiliser des fonctions du langage super cool là où ça ne sert à rien relève du pédantisme plus que d’autre chose (là encore, cf perl pour voir à quoi ça mène). Après, chacun est libre de s’exprimer comme il veut, et chaque langage fait les choix qu’il veut. Et encore une fois, il faut faire preuve de mesure : l’excès, dans un sens ou dans un autre, n’est jamais bon.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Rust vs Go
Posté par whity . En réponse à la dépêche Rust 0.12 : non, pas le jeu vidéo, le langage !. Évalué à 2.
S’ils le parlent aussi mal que les Français parlent leur propre langue, ça va plutôt dans mon sens : une trop grande complexité ne sert à rien. Combien de Français aujourd’hui comprennent les implications d’un imparfait du subjonctif ? Bon ben ils ne s’en servent pas, c’est tout.
J’ai trop vu cet argument appliqué à perl pour y accorder la moindre crédibilité. Le problème est que oui, une structure, ça s’assimile assez vite, mais souvent elle n’est pas seule. Et qu’à force, on se retrouve avec des choses qui sont peut-être lisibles pour un spécialiste, mais :
- je ne suis pas convaincu que ce soit plus lisible qu’une forme moins concise, même pour le spécialiste en question
- c’est clairement moins lisible pour un non-spécialiste
Encore une fois, tu vas largement au-delà de ce que j’ai dit. Je dis qu’une construction qui n’apporte que de la concision (on est donc à des années lumières de ce qu’apportent les templates en C++ ou la métaprogrammation) n’apporte pas forcément de la lisibilité. Que
réussit à être à la fois plus lisible et plus concis en toute circonstance, mais que
est en général inférieur en lisibilité à
En clair, je dis qu’utiliser des fonctions du langage super cool là où ça ne sert à rien relève du pédantisme plus que d’autre chose (là encore, cf perl pour voir à quoi ça mène). Après, chacun est libre de s’exprimer comme il veut, et chaque langage fait les choix qu’il veut. Et encore une fois, il faut faire preuve de mesure : l’excès, dans un sens ou dans un autre, n’est jamais bon.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0