Non non, pas de problème, je crois qu'on est plutôt d'accord. Je n'ai pas de solution non plus pour faire évoluer un langage sans tout péter.
Le choix d'interpréter les caractères comme des facteurs dans les jeux de données est problématique, puisque de toutes manières certains jeux de données peuvent contenir à la fois des colonnes de texte qui correspondent à des caractères et d'autres à des facteurs. Il aurait été tout à fait possible de développer des heuristiques pour se gourer le moins possible (par exemple, il est très peu probable qu'une colonne qui contienne des chaines de caractères toutes différentes puisse représenter un facteur), mais ça aurait été atroce en termes de maintenance. Un choix existait par défaut, il était critiquable, mais c'était comme ça. Ce qui est embêtant, c'est de changer, surtout qu'il existait quand même des arguments dans les deux sens, ansi qu'une option stringsAsFactors qui permettait de basculer entre les deux comportements. Mais bon, c'est fait, c'est fait...
Après, R possède de très nombreux bugs d'interface sur des fonctions de base; soit des noms de paramètres ou de fonctions incohérents (par exemple simplify dans sapply vs SIMPLIFY dans mapply, nrow mais row.names dans data.frame vs nrow() et rownames()), soit des interfaces hyper bugogènes (comme le premier paramètre dans sample() qui change de sens en fonction de sa longueur), soit des ordres de paramèters incohérents (do.call a la fonction qui vient en premier et qui s'appelle "what", lapply a la fonction qui vient en deuxième et qui s'appelle FUN...). Quitte à péter la compatibilité lors d'un changement majeur de version, autant le faire un bon coup et réparer plusieurs problèmes à la fois... La méthode choisie c'est plutôt de retirer le pansement millimètre par millimètre, je ne suis pas convaincu.
[^] # Re: Ma plus commune erreur
Posté par arnaudus . En réponse au journal Gnu R version 4.0.0 est disponible. Évalué à 2. Dernière modification le 29 avril 2020 à 15:55.
Non non, pas de problème, je crois qu'on est plutôt d'accord. Je n'ai pas de solution non plus pour faire évoluer un langage sans tout péter.
Le choix d'interpréter les caractères comme des facteurs dans les jeux de données est problématique, puisque de toutes manières certains jeux de données peuvent contenir à la fois des colonnes de texte qui correspondent à des caractères et d'autres à des facteurs. Il aurait été tout à fait possible de développer des heuristiques pour se gourer le moins possible (par exemple, il est très peu probable qu'une colonne qui contienne des chaines de caractères toutes différentes puisse représenter un facteur), mais ça aurait été atroce en termes de maintenance. Un choix existait par défaut, il était critiquable, mais c'était comme ça. Ce qui est embêtant, c'est de changer, surtout qu'il existait quand même des arguments dans les deux sens, ansi qu'une option stringsAsFactors qui permettait de basculer entre les deux comportements. Mais bon, c'est fait, c'est fait...
Après, R possède de très nombreux bugs d'interface sur des fonctions de base; soit des noms de paramètres ou de fonctions incohérents (par exemple simplify dans sapply vs SIMPLIFY dans mapply, nrow mais row.names dans data.frame vs nrow() et rownames()), soit des interfaces hyper bugogènes (comme le premier paramètre dans sample() qui change de sens en fonction de sa longueur), soit des ordres de paramèters incohérents (do.call a la fonction qui vient en premier et qui s'appelle "what", lapply a la fonction qui vient en deuxième et qui s'appelle FUN...). Quitte à péter la compatibilité lors d'un changement majeur de version, autant le faire un bon coup et réparer plusieurs problèmes à la fois... La méthode choisie c'est plutôt de retirer le pansement millimètre par millimètre, je ne suis pas convaincu.