Si une Pull-Request désigne l'action qui consiste à demander au détenteur du dépôt original de prendre en compte les modifications que vous avez apportées sur votre fork et que vous souhaitez partager, le fait d'accepter votre pull-request a aussi un petit nom qui est le merge. C'est ce qui s'est passé avec une Pull-Request sur le langage de programmation Rust intitulé Avoid "whitelist" (évitez [d'utiliser] « liste blanche »).
Durant les échanges sur le Pull-Request, certains commentaires ont été modérés de par leur nature et l'un des contributeurs a noté que « la réaction à ce PR démontre la raison pour laquelle ce type de changement devrait être fait le plus tôt possible ». Néanmoins, certains développeurs comme Niko Matsakis, qui est également contributeurs, se sont montré en faveur du changement : « je suis favorable à la suppression du terme "whitelist" et au passage à "allowlist" ou à une autre terminologie plus précise (gros +1 à "AssumeUsed" en particulier) ». Il a tout de même demandé si ces changements seraient purement interne et s'il n'allait pas « affecter tous les drapeaux (flags) "visibles par l'utilisateur" ».
Rust rejoint donc le rang de nombreuses entités qui ont décidé de supprimer des termes comme « liste blanche » comme les développeurs de la base de données MySQL, qui ont annoncé leur intention de cesser d'utiliser et de remplacer des termes tels que master, slave, blacklist et whitelist dans le code source et la documentation de la base de données.
« Quiconque utilise la réplication MySQL connaît les termes : ‘master’ et ‘slave’. Les origines de ces mots sont négatives. C’est clair. Chez MySQL, nous avons pris la décision de changer cette terminologie. Déjà, beaucoup d'entre nous ont changé la façon dont nous nous référons à ces rôles dans les billets de blog et les présentations - en utilisant généralement des termes comme ‘primaire’, ‘secondaire’, ‘source’ et ‘réplique’. Nous avons maintenant commencé le processus de modification de la syntaxe MySQL dans notre code source et notre documentation pour faire correspondre tout cela ».
La connotation de la terminologie est également évoquée du côté de Linux par Dan Williams, lors des discussions autour de la proposition qui a été acceptée : « La traite des esclaves africains était un système brutal de misère humaine déployé à l'échelle mondiale. Les décisions relatives au choix des mots dans un projet de logiciel moderne ne sauraient effacer ce malheureux héritage, mais peuvent aller dans le sens de maximiser la disponibilité et l'efficacité de la communauté mondiale des développeurs pour participer au processus de développement du noyau Linux ».
Les ingénieurs de Twitter prévoient eux aussi « d’éviter le langage non inclusif » en supprimant un certain nombre de termes, notamment whitelist, blacklist, master/slave, grandfathered, divers pronoms de genre (comme « les gars » ou « il / lui / son ») mais aussi des termes comme man-hour (qui est la quantité de travail effectuée par le travailleur moyen en une heure. Il est utilisé pour estimer la quantité totale de travail ininterrompu nécessaire pour effectuer une tâche).
D'autres entreprises et projets open source qui ont récemment promis d'apporter des changements similaires et de nettoyer leur jargon technologique incluent GitHub, Microsoft, LinkedIn, Ansible, Splunk, Android, Go, PHPUnit, Curl, OpenZFS, OpenSSL, JP Morgan et autres.
L'objectif principal de ces efforts est de rendre les produits technologiques et les environnements informatiques plus accueillants pour les personnes de couleur. Certains membres de la communauté technologique ont critiqué le mouvement comme étant un signal de vertu superficielle plutôt que comme quelque chose qui aide les personnes de couleur et le racisme systémique.
Que pensez-vous de cette décision ? Au point où nous en sommes, l'industrie gagnerait-elle à trouver un standard afin d'éviter de se retrouver avec des terminologies différentes pour désigner la même chose ? Dans quelle mesure ?
petite citation qui prouve bien le coup de la "cancel culture" :
Moderation note: Some of the comments already posted on this PR are completely inappropriate. While dissent is always encouraged, it must be provided in a constructive manner. Mixing it with personal attacks is not constructive and it will not be tolerated in official Rust community spaces.
quand on creuse un peu, juste 15s on a ça :
Let me expand a little bit on my opinion. I see people upvote/downvote a lot, and I don't want it to happen for a wrong reason. Lemme get this straight: I'm not a troll; I just genuinely can't believe people are seriously into this fancy tolerastency cowshit.[...]
j'ai pas mis le poste en entier, parce que long et je trouve plutôt argumenté et poli mais malheureusement pour son auteur : This comment was marked as disruptive content.
ils trouveront toujours un moyen de censurer des gens, mais bon, ils se disent dans le camp du "bien"...
Mon avis personnel : Si des gens s'offusquent dès qu'on remplace whitelist par allowlist, c'est surtout parce qu'accepter cela c'est aussi admettre que notre confort moderne doit beaucoup a des injustices passées mais qui perdurent aujourd'hui.
Foutaises.
C'est surtout que cela est poussé et justifié par une idéologie totalitaire et raciste. Que derrière modifier du code qui marche sur des prétextes aussi stupides et politiques, ça a aussi des conséquences...
Envoyé par SimonDecoline
Maintenant on peut dire "historiquement on a été plus fort, et aujourd'hui on continue à en profiter et on vous emmerde"
N'importe quoi...
Envoyé par SimonDecoline
mais aller trouver que whitelist/allowlist c'est un drame absolu ou une manoeuvre secréte BLM-illuminati pour gouverner le monde, c'est assez hypocrite.
Et mon message juste en dessus du tien montre des exemples de censures assez flagrantes... mais à part ça, circulez, y'a rien à voir.
C'est pas comme si on avait longuement justifié le contexte dans lequel cela se faisait... mais ça tu t'en fous hein...
Envoyé par SimonDecoline
Allez salut. Et bon 14 juillet : la prise de la bastille par des émeutiers protestant contre le pouvoir et causant 98 morts... ça me rappelle quelque chose... mais en tout cas, ça mérite logiquement d'être la fête nationale, et avec un défilé militaire...
Bah oui, commençons donc les comparaisons absurdes.
Comparer une révolution justifiée par des idéaux solides afin de renverser un pouvoir tyrannique et promouvoir l'idéologie démocratique, avec une émeute qui détruit, tue, et vole, les siens, pour promouvoir une idéologie fasciste, afin de détruire un pouvoir démocratique, justifié par des raisons racistes et des mensonges.
Mais continue donc dans ton déni... quand cette secte aura pris un peu plus de pouvoir, tu vas voir comment tu va rigoler. Quand ils prendront le contrôle de ton quartier avec l'aide de ta mairie, que tu ne pourras même plus rentrer ou sortir de chez toi...
On commence par s'initier dans des collectifs, à demander des petites choses pour jouer sur le biais d'engagement, et tuer les débuts oppositions, comme on voit déjà avec la censure actuelle. À propager son idéologie pour recruter de nouveaux fidèles dans sa secte. Une fois le tout bien verrouillé, suffit juste de grimper les marches de la radicalisation.
Ce n'est pas juste une question de renommer whitelist en allowlist, mais de propager la connerie que "whitelist" serait raciste et qu'il faudrait s'en indigner. Une fois que tu acceptes cela, t'as fais le premier pas dans leur secte. Suffit juste qu'il te fassent faire le second pas, puis le troisième... et avant même que tu t'en aperçoive, il sera déjà trop tard.
j'ai pas mis le poste en entier, parce que long et je trouve plutôt argumenté et poli mais malheureusement pour son auteur : This comment was marked as disruptive content.
ils trouveront toujours un moyen de censurer des gens, mais bon, ils se disent dans le camp du "bien"...
En effet, c'est affligeant de bêtise :
WTF
=> Disruptive content.
What the hell? Instead of doing something useful to compiler you guys create PR like this? Translating white/black connotation to skin color is racism in its purest form.
=> Spam
This is actively harmful to improving the material conditions of Black and other disadvantaged and marginalized groups. It's unquestioned that computer science is a field overwhelmingly dominated by white and Asian (incl. Indian, Middle Eastern, etc.) men. Both Black and Latino people, and women, are extremely disproportionately underrepresented in computer science (citation, citation), and this is something that we should all strive to improve.
The fact is, however, that changing whitelist to allowlist does not do that. I can promise you, with 100% certainty, that there has never in the history of the world, ever, been a black person who genuinely, unironically said "I would become a computer science major, if only they'd stop using the term whitelist". There are about a million complicated sociological and economic factors that explain the disparity, and we ought to strive to do our best to combat them. Here are a couple of genuine ways that you could combat them with far more substantive and material impacts:
Donate (or feature) any one of the dozens of charities that work to improve STEM education in low-income and marginalized communities, like (VoSNL)[https://www.vosnl.org/].
Join a protest
Participate in a mutual aid group
Learn if there is a rent strike or a tenants union in your city
Read a book by a black author
And dozens more.
Even just including a statement at the top of the README or on the website saying "Rust stands with people of color and all victims of oppression." with a link to the BLM webpage would do more material good than this PR.
And yet, despite not making any material improvements to anyone's lives, this PR plays directly into the hands of the alt-right. This only further cements the belief that the "SJWs are speech policing", which is precisely the first step in the alt-right pipeline! Additionally, this furthers the frankly harmful misunderstanding that racial equality is merely removing offensive phrases or whatever, ignoring the far more insidious social factors that play into it.
=> Off-topic
I agree that "allowlist" is not a good term, and it has been expunged from this PR.
=> Off-topic
In my opinion whitelist and blacklist are not exclusive terms, they are totally fine, I don't know why would anyone think otherwise honestly.
=> Off-topic
Really though, is that variable going to be named EXEMPTIONS? Really bad name.
=> Minimized (euh WTF ?)
Well, OK, why do you think that EXEMPTIONS is a better term? It's clearly more difficult to understand. If you want to avoid WHITELIST, you should've at least called it EXCEPTIONS or something, if I understand correctly.
=> Minimized (euh WTF ?)
A policy question for the future: how does the decision to merge this affect future contributions to the language? Will there be lists (ahem) of forbidden words and expressions that people are not allowed to use?
=> Off-topic
If the renaming is purely political it is a mistake and sets a dangerous president. Did you know "Werk-en-Rust" was a slave plantation? What will you do in future if the word Rust becomes "offensive" like a group of people managed to do to the OK sign? What if it's offensive in another language, will those be considered as well?
=> Off-topic
I don't doubt that this sort of initiative stems from good intentions, but this is not a viable approach to setting rules.
How would we amend the style guide? By stating that we should avoid words that might be considered offensive in general? Or in the future? This is an impossible rule to follow. The words "whitelist" and "blacklist", just like a few others, have only recently been deemed problematic in some circles; we've used them for a long time and there were no bad intentions behind it.
Or would we create polls asking people about all the words that they find offensive? Who's opinions would matter most? The ones considering themselves underrepresented? An argument is not made more valid depending on who expresses it.
As already mentioned, some of these changes are an improvement, so it's to the benefit of the community. But let's try not to make the original reasoning behind them become a part of governance.
=> Off-topic
'm just going to be blunt, because there isn't a nice way to put it: These people need to accept that "blacklist" and "whitelist" are not racially charged words. They are commonly used, not exclusive to programming or even IT in general. Just looking in the tech world, I could find you a million instances where these words are used and are not going to be changed. If they can't accept these words, they should just bury their head in the sand and ignore the rest of the world, because they are not going to go away.
PS: I'm uncomfortable with double-negatives, especially in code where things are supposed to follow logic. This PR introduces a double negative (which I pointed out earlier), and I don't see that being addressed. Why is the word "whitelist" worse for a codebase than a double-negative in logic flow? Okay, this was actually addressed and I didn't see it. Fair enough - the main thing I want is for precision and readability to be increased. I still stand by that whitelist and blacklist are perfectly acceptable words that are used way beyond the scope of Rust, and anyone who can't accept them is going to have other problems in the world. I'm not one to go out of my way for something that matters as little as this, but as long as the code isn't getting worse I see no issue with someone addressing it (although I do hope they realize how little it matters in comparison to the rest of the world)
=> Off-topic
It sounds like something that should've been done beforehand. Maybe even RFC with a road-map for adjusting the documentation. As @nikomatsakis pointed out, this is not a one-time change, but a whole precedence to potentially force new rules on future contributions.
=> Off-topic
Personally I see it as a prioritization of opinions clearly linked to the current political situation in the US. Support of this newspeak-light in the form of marking well-known and widely used words as "no longer accepted" is a political action, as it gives power to people behind it to define which words we can use and what exactly should be considered "inclusive". Worryingly, it's not the first time Rust leadership got influenced by inner US politics, and for those who outside of the supported group (and outside US in general) it can be seen as a risk for the project and their investments in it.
Yes, current case can be considered relatively minor, but such pressure has a tendency to escalate when given opportunity (see Overton window). What about "dummy" or "black box" widely used across Rust code base? What about accepting contributions from (let's say) an odious Trump supporter recently involved in a social network scandal? What about reserving seats in Rust teams for people of color and non-binaries? What about blocking citizens of a country which US will designate as an enemy (which arguably already happens in a soft form)?
There are plenty of people in traditionally under-represented groups who have stated, in good faith, that the existing terms are causing them discomfort and making them feel excluded.
Ironically the author of this PR is a white (straight?) male. Not to deny your words, but can someone provide a good evidence that whitelist/blacklist indeed causes discomfort for people in those groups? Ideally before the current events.
=> Off-topic
Meta
Avoiding discussion while at the same time attacking the other side (without clarifying a target) is not constructive from your point and has heated up the unnecessary debate.
Any summary on the content and its inappropriateness + short description on the specifics why the words are better in a technical manner would have stopped it at its beginning and also would make better documentation.
This can also be expected for commonly used words to show good intent. Even if you think they are not appropriate.
Content
May you explain the difference between the phrase "permit" and "allow" or are they arbitrary chosen as indications of a filter to be applied? This feels inconsistent to me. The opposite of allow is disallow, so this does not feel very fitting.
Could you change this to either 1. permit and deny or 2.allow and disallow ? I would favor the latter.
Also you use exemptions to describe ALLOWED_TO_BE_SIMILAR. similarities feels more consistent.
=> Off-topic
Et la conclusion :
Now that the PR has been merged and this PR seems to have attracted trolls, I'm going to lock it for good. As Niko said above, name improvements can be iterated on in follow up PRs. Thank you to everyone who participated in this PR constructively!
Mais qu'on les envoye en Chine !
Au moins ils apprendront ce qu'est l'esclavage, et à quel point ça fait du bien d'être du côté censuré.
L'année 2020 est marquée par une quantité impressionnante de d'épidémie . Après le covid une épidémie (de conneries ) !.
La marque de l'équipe de foot américain "Redskins" doit changer de nom.
Même chose pour la marque de chaussure qui est dans le viseur de plusieurs associations ... jugé trop raciste.
Il y a Banania et le slogan " y'a bon " ... oups pardon mince c'est raciste envers les antillais et caribéens ... C'est pour dire le niveau de connerie de certains ... Il y a plus urgent à traiter je pense
Mon avis personnel : Si des gens s'offusquent dès qu'on remplace whitelist par allowlist, c'est surtout parce qu'accepter cela c'est aussi admettre que notre confort moderne doit beaucoup a des injustices passées mais qui perdurent aujourd'hui. Maintenant on peut dire "historiquement on a été plus fort, et aujourd'hui on continue à en profiter et on vous emmerde" mais aller trouver que whitelist/allowlist c'est un drame absolu ou une manoeuvre secréte BLM-illuminati pour gouverner le monde, c'est assez hypocrite.
Le whitesllist/ blacklist vient d'une opposition ombre/lumière.
On voit ce qui est a la lumière, on ne voit pas ce qui est dans le noir .
Si des personne voit une quelconque référence à une couleur de peau, oui ça me gène car c'est profondément raciste.
Pour le terme maitre / esclave , c'est comme ci changer le terme mettrais fin à ce principe.
Le principe d'esclavage a toujours existé et (hélas) existera toujours (il suffit de voir l'esclavage moderne avec le principe de stage non rémunéré <_< ).
Ce que tu appelles "immense contribution de la bourgeoisie", j'appelle ça de la récupération politique dont le "peuple" se foutait complèment.
C'est la bourgeoisie qui a poussé à la Révolution... et qui s'est servie du mécontentement du peuple.
Envoyé par SimonDecoline
Mais bon, admettons. Mais dans ce cas, pourquoi tu rejettes l'idéologie d'une vraie équité des populations (indépendamment de la couleur de peau), sous prétexte de certaines actions violentes ?
t'as rien suivi de l'actualité toi...
Ce n'est pas une idéologie d'une vraie équité, et cela ne l'a jamais été... C'est une idéologie raciste et de discrimination. Et pour les "quelques actions violentes"... c'est au contraire toute le cœur de leur idéologie, et sa conséquence.
Envoyé par SimonDecoline
Sérieux ? Il y a quantité d'études qui sortent régulièrement à ce sujet.
Y'a aussi une quantité d'études qui sortent régulièrement pour dire que le vaccin cause l'autisme, que ceci ou cela...
Faut voir plus loin que le simple nombre d'études...
Envoyé par SimonDecoline
Par contre, j'aimerais bien avoir des preuves de tes grandes affirmations, par exemple sur la secte mondiale qui va controler nos quartiers...
Jamais entendu parlé d'Evergreen ?
Jamais entendu parlé de CHAZ ?
Sur les 103 entreprises testées, le groupe identifie "entre 5 et 15 entreprises discriminantes",
Entre 5 et 15% donc...
À noter qu'il y a un gros biais vu que 2 profils identiques sont envoyés pour un même poste... Faut voir comment les RH régissent en voyant cela... sachant que l'ordre d'envoi des CV peut jouer.
On notera que ça combine candidatures et demande d'informations.
Concernant le protocole de l'étude, j'ai l'impression qu'il n'y a pas que le nom qui change... donc ça n'a pas l'air d'être des dossiers totalement identiques. Et sur la discrimination géographique, il faut aussi voir les entreprises et l'origine géographique affichée... parce que sur certains domaines sensibles, tu te fais bloquer parce que tu n'as pas le droit de recruter des personnes venant de certains pays, ou ayant des liens avec certains pays.
Pour en revenir au fameux "le code c'est la doc", on peut prendre du code pas trop avancé de rust (puisqu'on semble y être) et tu peux bien évidemment me dire ce que le code de cette fonction fait dans le détail je suppose : https://github.com/rust-lang/rust/bl...et_impl.rs#L23 Et bien évidemment, les commentaires ne servent complètement à rien.
Déjà je n'ai jamais fait de Rust.
Ensuite ta fonction fait déjà 100 lignes, mais je sais qu'elle me retourne un vecteur d'implémentation de "blankets", je présume que c'est un concept de Rust ?
#[stable(feature = "rust1", since = "1.0.0")]impl<T: fmt::Display + ?Sized> ToString for T {#[inline]
default fn to_string(&self) -> String {use fmt::Write;
letmut buf = String::new();
buf.write_fmt(format_args!("{}", self))
.expect("a Display implementation returned an error unexpectedly");
buf.shrink_to_fit();
buf
}}
Traduction : pour tout type T qui implémente le trait Display, ce type implémente aussi le trait ToString et voici l'implémentation par défaut de la méthode to_string (requise par le trait ToString).
Si on traduisait ça en POO, on dirait que la classe abstraite Display dérive de la classe ToString et que le code de Display contiendrait une implémentation de la méthode virtuelle to_string de ToString. En vrai, le système de type de Rust n'obéit pas aux mêmes contraintes que l'héritage en POO, mais je donne quand même une analogie pour que ce soit plus clair.
De manière plus générale :
Implementations of a trait on any type that satisfies the trait bounds are called blanket implementations
Du coup, la fonction get_blanket_impls citée par imperio a visiblement pour rôle de chercher les implémentations par défaut pour les traits que définit le type ty en paramètre.
Personnellement, je n'ai pas compris les détails de l'implémentation. En amont, je crois qu'il faut d'abord comprendre ce à quoi correspond le type core::DocContext et je n'ai pas le temps de regarder ça. Il y a aussi des abréviations que je ne comprends pas, typiquement tcx.
Un facteur x30 ? T'es sûr que tu n'exagères pas un peu ?
Ok, pour des optimisations d'I/O, réduction de la complexité de l'algorithme, utilisations de bibliothèques de calculs, bonnes options de compilations, éviter les copies/allocations inutiles, et 2/3 bons principes, voire passer sur GPU... mais me dire que tu gagnes un facteur de x30 avec un code "non-propre", je suis sceptique.
Le nommage, l'indentation, retours à la ligne, et au pire des fonctions inlines, c'est pas ça qui va modifier tes performances. Passer à l'assembleur, tu gagneras des pouillèmes, et certainement pas un facteur x30, si au départ tu utilisais des bibliothèques adaptées.
À la limite, faire plusieurs opérations en un seul parcours en évitant des copies... mais un facteur x30... ça me semble quand même un peu beaucoup.
Si ça arrive, j'ai déjà eu des cas ou l'on passe par exemple de 5 jours à 2 heures mais qui est passé à 3h30 quand il a fallu rajouter des controls juste pour rassurer et que le code soit lisible et surtout compréhensible par tous.
Malheureusement, bien souvent, on confond code illisible (lié à la subtilité du langage) et code crade.
Il y a des développeurs axés mathématiques et d'autres plutôt littéraires. Les uns sont bons pour faire des algorithmes, comprennent facilement des enchaînements d'opérations avec des signes pas forcément très clair. Le problème est que ce code est compréhensible principalement par eux-mêmes. D'autres sont meilleurs à un niveau organisationnel et langagier, ils se focalisent sur comment dire à la machine ce qu'elle doit faire avec un enchaînement de fonctions et variables bien nommées permettant de lire le programme comme un texte. Les deux aspects du métier sont nécessaires mais je vois les premiers comme des personnes à l'esprit purement logique qui sont moins intéressés notamment par l'expérience utilisateur d'un programme. Tant que ça marche et que c'est rapide ça leur va.
Il y a un langage qui est très critiqué car souvent difficile à lire (enfin, soi-disant) qui a été créé par un linguiste, ce langage est le perl...
A tous, faudrait peut-être définir le terme de code sale, non ?
Si une Pull-Request désigne l'action qui consiste à demander au détenteur du dépôt original de prendre en compte les modifications que vous avez apportées sur votre fork et que vous souhaitez partager, le fait d'accepter votre pull-request a aussi un petit nom qui est le merge. C'est ce qui s'est passé avec une Pull-Request sur le langage de programmation Rust intitulé Avoid "whitelist" (évitez [d'utiliser] « liste blanche »). 
Que pensez-vous de cette décision ?
Envoyé par SimonDecoline
t'as rien suivi de l'actualité toi...