I asked Karen Sandler. This is the reason for the selection of groups:

<karenesq> JordiGH: I saw the lobsters thread. the expansion within the US to the non-gender related criteria was based on the publication by multiple tech companies of their own diversity statistics. We just expanded our criteria to the groups who were by far the least represented.

He had a pretty fair description of where the disputes were coming from. Far as what you’re saying on Outreachy, the Asian part still fits into it as even cultural diversity classes I’ve seen say the stereotypes around Asians are positive for stuff like being smart or educated. Overly positive to the point that suicide due to pressure to achieve was a bit higher according to those sources. There’s lots of Asians brought into tech sector due to a mix of stereotypes and H1-B. The commonness of white males and Asians in software development might be why they were excluded with the white males. That makes sense to me if I look at it through the view they likely have of who is privileged in tech.

Well, if you were a woman or identified as one they would accept you, regardless if you were Asian or not. I do wonder why they picked to outreach to the particular groups they picked.

And you have to pick some groups. If you pick none/all, then you’re not doing anything different than GSoC, and there already is a GSoC, so there would be no point for Outreachy.

It is discrimination, that’s what discrimination means. But that doesn’t automatically make it unfair or net wrong.

The alternative is inclusive supply plus random selection. You identify the various groups that exist. Go out of your way to bring in potential candidates of a certain number in each one. The selection process is blind. Whoever is selected gets the help. Maybe auditable process on top of that. This is a fair process that boosts minorities on average to whatever ratio you’re doing the invite. It helps whites and males, too.

That’s the kind of thing I push. Plus, different ways to improve the blindness of the evaluation processes. That is worth a lot of research given how much politics factors into performance evaluations in workplaces. It affects everyone but minority members even more per the data. Those methods, an equal pull among various categories, and blind select are about as fair as it gets. Although I don’t know exact methods, I did see GapJumpers describing something that sounds closer to this with positive results. So, the less-discriminating way of correcting imbalances still achieves that goal. The others aren’t strictly necessary.

The next scenario is specific categories getting pulled in more than everyone with organizations helping people in the other ones exclusively to boost them. That’s what’s going on here. Given the circumstances, I’m not going to knock them even if not as fair as other method. They’re still helping. It looks less discriminatory if one views it at a high level where each group addresses those they’re biased for. I did want to show the alternative since it rarely gets mentioned, though.

It’s a simple calculus of opprotunity. Allowing those who already have ample opprotunity (i.e. white, cis, males) into Outreachy’s funding defeats the point of specifically targeting those who don’t have as much opprotunity. It wouldn’t do anything to help balance the amount of opprotunity in the world, which is Outreachy’s end goal here.

It’s the author’s idea that they deserve opprotunity which is the problem. It’s very entitled, and it betrays that the author can’t understand that they are in a priviledged position that prevents them from receiving aid. It’s the same reason the wealthy don’t need tax cuts.

What’s not up for debate is that companies or people should be able to give their money however they feel like it.

That is debatable. But, I too think Outreachy is well within their rights.

So, in your anecdotal experience, other people’s anecdotal experience is unreliable? 😘

I think that the information asymmetry that you had with your anecdotes affected some of the reactions you got. For one, if someone considers your actions negative in some way, they are conditioned by society to assume that you were being prejudiced. If your workplace was one that had more of a negative connotation (perhaps a debt collection service or what have you) that goes double. That’s a reason for the percieved negativity that your white male colleagues didn’t even have to consider, and they concluded that you were just being moderately nice. Notice that you didn’t have to be specifically discriminatory, nor was it necessarily fair. It’s just one more negative thing that happens because prejudice does exist. I would imagine that you would not have so many negative reactions if you explained exactly what you were doing vis-a-vis the randomization of greetings and such. I think I would discount percieved discrimination if someone did that to me.

The point is a bit bluntly made, but it’s for a reason. There’s a certain kind of internet posting style which uses techniques like changing “social justice movement” to “social injustice movement” to frame the author’s point of view. Once upon a time “Micro$oft” was common in this posting style.

For extreme cases of this, see RMS’ writing (Kindle=Swindle, etc).

(The problem with these techniques, IMO, is that they’re never as clever and convincing as the person writing them thinks that they are. Maybe they appeal to some people who already agree with that point of view, but they can turn off anyone else…)

There are no bytecodes involved. All of the languages share a common AST representation where nodes can be compiled and specialised if they are frequently executed.

It’s a skill that becomes easier as you do it, admittedly. When dealing with spaghetti, you only have to be as smart as the person who wrote it, which is usually not very smart :D.

As others have noted, where many fail is too much abstraction, too many layers of indirection. My all time worst experience was 20 method calls deep to find where the code actually did something. And this was not including many meaningless branches that did nothing. I actually wrote them all down on that occasion for proof of the absurdity.

The other thing that kills when working with others code is the functions/methods that don’t do what they’re named. I’ve personally wasted many hours debugging because I skipped over the funtion that mutated that data it shouldn’t have, judging from it’s name. Pro tip; check everything.

Or you can record what lines of code are actually executed. I’ve done that for Lua to see what the code was doing (and using the results to guide some optimizations).

Well, I wouldn’t say “incredibly skilled” so much as “stubborn and simple-minded”–at least in my case.

When doing debugging, it’s easiest to step through iterative changes in program state, right? Like, at the end of the day, there is no substitute for single-stepping through program logic and watching the state of memory. That will always get you the ground truth, regardless of assumptions (barring certain weird caching bugs, other weird stuff…).

Helper functions tend to obscure overall code flow since their point is abstraction. For organizing code, for extending things, abstraction is great. But the computer is just advancing a program counter, fiddling with memory or stack, and comparing and branching. When debugging (instead of developing), you need to mimic the computer and step through exactly what it’s doing, and so abstraction is actually a hindrance.

Additionally, people tend to do things like reuse abstractions across unrelated modules (say, for formatting a price or something), and while that is very handy it does mean that a “fix” in one place can suddenly start breaking things elsewhere or instrumentation (ye olde printf debugging) can end up with a bunch of extra noise. One of the first things you see people do for fixes in the wild is to duplicate the shared utility function, and append a hack or 2 or Fixed or Ex to the function name and patch and use the new version in their code they’re fixing!

I do agree with you generally, and I don’t mean to imply we should compile everything into one gigantic source file (screw you, JS concatenators!).

Ill add that one of the motivations of improved structure (eg functional prigramming) is to make it easier to do those patches. Especially anything bringing extra modularity or isolation of side effects.

Yes, vim also makes it easy to look at different parts of the same buffer at the same time, which makes big files comfortable to use. And vice versa, many small files are manageable, but more cumbersome in vim.

I miss the functionality of looking at different parts of the same file in many IDEs.

Yes! There are so many more ways of analysis and presentation possible without the shackles of text files. To give a very simple example, I’d love to be able to substitute function calls with their bodies when looking at a given function - then repeat for the next level if it wasn’t enough etc. Or see the bodies of all the functions which call a given function in a single view, on demand, without jumping between files. Or even just reorder the set of functions I’m looking at. I haven’t encountered any tools that would let me do it.

Some things are possible to implement on top of text files, but I’m pretty sure it’s only a subset, and the implementation is needlessly complicated.

Anyone who truly thinks this would be better ought to go learn some lisp.

Yes, I’m 100% in agreement.