obstinate

Someone seeking a job that you control can probably be said to be like a coworker for the purposes of analyzing power imbalances.

We have been inundated by posts like these lately as these creepy dudes have been outed. I have felt as you do on several of them. IMO, this one comes the closest to being a real apology. Doesn't make up for what he did, not by a mile. Doesn't mean he should ever be allowed to be in a position of authority over women again. But for me it was a positive step.

I wouldn't say perfectionism and sales-orientedness are on the same dimension. However, I have noticed that being given the hard-sell is more often than not associated with the product being sub par. A product or project that is doing very good work often doesn't have to sell quite as hard, because the work speaks for itself. (My experience on this issue mostly deals with internal teams. I don't know how much this applies to external teams.)

This is especially true when two products have teams of about equal size, experience, and expertise. Time spent selling is time not spent making a better product. All other things being equal, every hour spent selling is one less hour spent working on making your product better.

If not fines, then imprisonment for contempt of court is a remedy judges have at their disposal. I'm sure it would not take very long for Kholsa to get the point.

The purpose of sanctions in a situation like this is to compel the recipient of those sanctions to do the court's bidding. They should just ratchet the sanctions up until he does what has been ordered. If ten thousand dollars won't do it, make it a hundred. If that doesn't do it, multiply it by ten again. Eventually he'll either comply or no longer have any assets. Either way, the problem will be solved.

Actually, such behavior has gotten people killed in those contexts.

Nobody is going to die if you can't date someone.

Again, I advocate a conservative approach to getting a date with a coworker. One request, declined for any reason, should be treated as a firm no absent explicit signals to the contrary (request for a rain check, some other sort of proactive, explicitly date-seeking behavior from the other party). Your odds of getting into trouble under this rule are so vanishingly small as to be nonexistent. If you choose some less conservative rule, including, apparently, whatever rule you've been following up to this point, your risks are higher.

Of course, there's also the issue of not wanting to make your woman coworkers uncomfortable. I would hope that would be something of intrinsic value to you, and that on this basis alone you might change your behavior after seeing its impact in the past. The fact that you're still arguing about this makes me doubt that you do value their comfort the way that I think you should. But I don't know how to tell you that you should care about other people in a way that's going to stick. :(

- Reparations to all he harmed directly.

- Further reparations to groups representing those similarly situated.

- Meaningful engagement with mental health professionals to attempt to work on the source of the problem.

- Less defensive, less self-promotional apologies.

These four are the bare minimum. Until he has done each of these, he's receiving a failing grade from me.

You think that the women you've worked with have been promoted . . . because you were fantasizing about them instead of engaging with them? Not, for e.g., maybe because they were more capable than average?

IMO, you should seek therapy. You sound like you need it more than most.

Normally people have to do some penance before forgiveness, especially as the crimes grow more heinous. Continuing to live the rich and privileged life you were leading before, more or less untouched by the hand of justice, does not count for much in this dimension.

Disclosure, this comes to mind because of something that happened between me and a colleague of equal rank in a volunteer organization who went directly from "I don't think I can see a movie tonight" to "This situation is making me uncomfortable" with nothing in between.

Did you ask multiple times? This sounds like what could easily happen when someone won't take the initial "no," implicit or not, for an answer. Based on the rest of your comment, I expect so.

A few important points:

1. Repeated asking has been held to be sexual harassment, if repeated for long enough.

2. Here's a simple rule: ask once, and only once. She knows where you work. If she's interested, she'll ask for a rain check and get back to you.

I just don't think this is suitable verbal behavior for supposedly rational adults

3. Rational adults understand and respond to signalling. They don't demand that all communication happen explicitly and on their terms, because they know that such demands are ineffective for all purposes, will not be heeded, and might make them social pariahs.

I dunno. A 30% code size win is non-trivial. I'm all for filing an issue first and seeing how likely it is that there is uptake from the dev team and desire to fix the problem. However, if no fix is forthcoming . . . code size has fairly well known effects on performance.

Yes, yes. Or governments can enforce a more equitable split through taxes. But you still have to give some benefit to those who save, else there will be no reason to do aught but consume all one produces.

On some level, this is basically "capitalism 101." If I don't need my resources now, I can put them to work so that I can later benefit from them. This leads to me having productive assets, which pay me some return.

If I could not acquire productive assets, there would be much less reason to save. And it's unclear how one would save, as banks would likely not exist either. You can solve this problem somewhat by having a centrally planned economy. But then you have the problems that hit those.

Construction and rent also vary with fanciness. Rent because rent is more expensive in the fancy parts of town. Construction because the quality of finishes is a significant factor in construction costs.

What it costs to open a fancy restaurant with top quality finishes including walls dripped with rose gold resin.

But . . . substantial effort is already being put in globally. Not enough by far, but much more than zero. This would seem to put the lie to your claim that nothing will be done until there is no choice, by contradiction.

She's also a socialist, for what it's worth, and involved in lobbying for quality affordable housing. That doesn't make her immune from attacks of classism, but it might affect how one judges what she says.

(Also worth noting that McMansions are typically homes to the upper middle class and the rich, not the poor.)

Yours seems like a flippant response, but I don't think that it is. We have to be wary of confirmation bias here on HN. Would someone even think to publish a study where no effect was found? And then would someone post that link to HN? And then would it get upvoted? It's important to remember that we are not seeing a uniform sample of news stories here. We are seeing a highly biased selection, and it's important to appropriately discount things appropriately.

To be clear, I don't think this is the only thing that makes python slow. It's probably one of the top five or ten things preventing it from being fast, though.

Well of course. :) If you don't write perf sensitive code, don't worry about perf. But if you do, in many cases avoiding hash tables can become important.

There's also FarmHash, whose 32-bit version is 2x as fast as xxHash on little endian machines (at least according to this benchmark suite https://github.com/rurban/smhasher).

In fact, what performance oriented devs need to be taught about these days is how to not use hash tables, or, more generally, dictionaries. They are a super-easy data structure to reach for, but often it is possible to arrange your data such that their use is unnecessary.

One example that was brought up elsewhere in the thread is the way python looks up variables in successive scope dictionaries. This is obviously terrible for performance, and that's a big part of why Python is slow.

But how are other languages fast? Doesn't every language have to resolve variable names to memory locations? Well, yes, but fast languages do this mostly at compile time. How? Well, I'm not an expert in this, but at a high level, each variable is assigned a location in memory or registers, and then future references to that variable are rewritten to refer to the memory location by register name or memory address. This takes the whole "looking up a name" issue out of the path of work that has to get done at runtime. And you've switched from looking up things in tables to operating directly on registers and memory locations.

BTW, this has nothing to do with high-versus-low level. It's more about how mutable the process of name resolution is after program compilation. One could theoretically write an assembly language where memory locations are names, not numbers. If reflective features like runtime scope editing are available, this would be a very low-level language that still requires some kind of dictionary lookup at runtime.

I think you might be a little confused. Even in hash tables with chaining, one does not tend to spend much time traversing linked lists, because the typical bucket will have only one member. This depends on the load factor of the table, but most practical implementations will eventually rebucket and rehash if their load factor grows too high. "Getting the key loaded" -- i.e. finding the memory location that contains the key -- is O(1) on average in all practical hash tables. It does not typically require any traversal at all.

You keep on talking about ordered tables like red black trees, as in this comment, which is another sign that makes me wonder if you might be confused.

You can implement the sorted vector of keys with a hash function instead of a coindexed vector of values

So you're saying you're going to hash the keys, then sort them according to the hash, with tie breaking on the key itself? I'm not aware of any sorted table that does this, but I'm sure some exist. I suppose you'd get something of a win if N was large, and the keys had long common prefixes, and you didn't care about the ordering property.

But in that case you'd probably use an actual hash table, not the algorithm you just described. Unless there's something I'm missing.

sorted vector of keys . . . reserve necessary memory and sort it . . . unsorted coindexed arrays . . .

Most of the things you mentioned are not hash tables, but members of a parent concept, dictionaries. Hash tables all by definition involve some sort of hashing of the key. The two main categories of hash table are chained hash tables (std::unordered_map does this, at least in the implementations I'm aware of) and open addressed hash tables, which use probing instead of secondary data structures to resolve conflicts.

You only need anecdotes to prove that it's not bullshit.

Oh dear. No. That's not true at all. Suppose I have back pain. Then I eat some dirt. Then I feel better. Then I start claiming that dirt ingestion cures back pain. Someone would be well within their rights to call that bullshit, despite my anecdote. Even if I could find a dozen people who had the same experience, it would still be bullshit.

Even if I did, it would still be an anecdote. It would prove nothing either way. For that we have to look to data.

You know that thing about anecdotes. There are a lot of explanations for your situation getting better concurrently with chiro, but not because of chiro. For example, regression to the mean, placebo effect, etc.

That said, I had been under the impression that chiro is about as effective for lower back pain as evidence-based physical therapy. But that doesn't mean it is effective. It could equally well mean that we don't know of many good treatments for lower back pain, and thus that physical therapy is only good as a placebo (chiropractic).

Depends on the team, right? It was a major quality of life bump for me when I recently transferred to a team with whose members I enjoy spending time.

In the same sense as Tetris is -- that is, unchallenging at slow pace, extremely difficult to do quickly.