kaymanb

Very cool! I implemented some shared-memory atomic snapshots in Rust [0] and also did my best to take automated testing very seriously. I started out using loom [1], the library mentioned in the article, but latter switched to shuttle [2].

Shuttle's approach is to be randomized, instead of exhaustive like loom. However, the scheduler does still give probabilistic guarantees about finding bugs. I found that shuttle was faster and scaled to more complicated test scenarios.

Similar to the article, shuttle also lets you save the random seed if a particular schedule causes the test suite to fail. Being able to quickly reproduce failing tests is really important and enables you write explicit test cases for bugs that were previously caught and fixed [3].

[0] https://github.com/kaymanb/todc/tree/main/todc-mem [1] https://github.com/tokio-rs/loom [2] https://github.com/awslabs/shuttle [3] https://github.com/kaymanb/todc/blob/0e2874a70ec8beed8fae773...

I see this as typical of organizations that value creating a more inclusive environment for their developers.

Also, for what it's worth, Jenkins changed their terminology to use "agent" instead of slave in 2020 [0]. These efforts might seem futile in isolation, but they add up over time.

[0] https://www.jenkins.io/blog/2020/06/18/terminology-update/

I've been working on implementations of classic algorithms in distributed computing, and used Turmoil for testing correctness in message-passing / HTTP systems [0].

Overall, my experience has been positive. When it works, it's great. A pattern I've been following is to have a single fixture that returns a simulation of the system under a standard configuration, for example N replicas of an atomic register, so that each test looks like: 1. Modify the simulation with something like`turmoil::hold("client", "replica-1")`. 2. Submit a request to the server. 3. Make an assertion about either the response, or the state of the simulation once the request has been made. For example, if only some replicas are faulty, the request should succeed, but if too many replicas are faulty, the request / simulation should time-out.

One of the things I have found difficut is that when a test fails, it can be hard to tell if my code is wrong, or if I am using Turmoil incorrectly. I've had to do some deep-dives into the source in order to fully understand what happens, as the behavior sometimes doesn't line-up with my understanding of the documentation.

[0] https://github.com/kaymanb/todc/tree/main/todc-net

I've only seen the first four episodes, but they are fantastic. It is incredible how from ages 7 to 14 to 21 to 28 some individuals seem to barely change at all, whereas others appear to be a completely different person in each episode.

Very cool! Reminds me of the Trans European Alpine Route (TEAR) someone put together a few years ago.

https://www.mountainsandme.ca/tear-overview

I'm not really up to date, but a couple recent papers that I found interesting were:

In theoretical distributed computing, The Space Complexity of Concencus From Swap [0] solves a problem that has been open for a couple decades, and won Best Paper at PODC 2022.

In quantum complexity theory, MIP^* = RE [1] was really big deal when it was published in 2020. It got a (relative) ton of press coverage, and there are lots of articles and blog post available that give a high-level of the result and techniques used. I like this one [2] from Quanta Magazine.

[0] https://dl.acm.org/doi/abs/10.1145/3519270.3538420

[1] https://arxiv.org/abs/2001.04383

[2] https://www.quantamagazine.org/landmark-computer-science-pro...

What does the diversity of the groups have to do with anything? Trans people are (in general) oppressed in today's society, and the be perpetrators of that oppression are (in general) cis people. It should follow that trans folk finding a community of their own is admirable, but a community of cis-only folk should have to justify they're existence as something other than a tool to maintain oppression.

I have seen the most positive change from being more compassionate towards myself.

It is so easy to put pressure, shame, and negativity onto yourself, to a degree that you never would for anyone else. It has been very helpful at times to ask "What would I say to a good friend who was in the same situation as me?". Almost always, it is a complete 180 from the aweful things I would tell myself. Knowing that I have the ability to be just as compassionate to myself as I strive to be towards others, has been huge.

Disjoint-Sets have a very cool implementation whose amortized time complexity is extremely slow growing. It is not quite constant, but even for a disjoint-set with as many elements as there are particles in the universe, the amortized cost of an operation will be less than or equal to 4.

https://en.wikipedia.org/wiki/Disjoint-set_data_structure

I was on the CDT this year and heard about these guys. It's a crazy accomplishment! I know I was not expecting them to finish all three.

I think it's interesting that we seem to equate CS Theory being hard with involving sophisticated math. Are there any examples of concepts in Theory that are considered hard, but not because of their dependence on math?

The article seems to focus on complexity theory, but I couldn't think of any from that sub-field. My first thought is the Paxos algorithm for distributed consensus [1], which definitely has a reputation of being difficult to understand, and fits under the Theory umbrella.

[1] https://en.m.wikipedia.org/wiki/Paxos_(computer_science)

I also found this to be one of these articles weak points.

The author (rightfully) argues that what bankers do is difficult, and so it makes sense that they are compensated for it. But they also use this as an excuse for the finance industries short-comings: pricing mortgage backed securities is hard, coordinating bailouts is hard, so are bankers really to blame if they don't get it perfectly right?

I don't think you can have it both ways.

The article answers this.

"I don’t know many poor, or working class, or female, or struggling-to-be-taken-seriously folk who would show up at the inauguration of our 46th president dressed like Bernie."

Given the importance of the event, there is a socially constructed "dress code". The privilege comes from Bernie being able to break this code without fear of negative repercussions.

> Not so sweet? The blindness I see, of so many (Bernie included), to the privileges Bernie represents.

What does not being blind to this privilege look like? I agree that there is an angle to read Bernie and his mittens as an example of privilege. But I would also say that the outcome of the mitten craze has been, overall, positive.

> Our aim is to rival peer-reviewed journals in terms of the rigor and thoughtfulness in how we review research before publication.

I can see how this might be frustrating for academics working within Google. The field already has systems in place for peer-review. While I admire the idea of Google holding their research to a certain standard, it also provides a mechanism for dismissing research that paints Google (the corporation) in a bad light. If a paper is good enough to pass an (external) review process, why should it not be published?

If her goal was to perform research that would positively impact AI that runs in production, then taking a position at Google doesn't seem like the worst idea. Especially with since their stated principles [1] seem to fit that agenda.

Unfortunately enacting change "from within" isn't always easy. It's easy to forget that Google AI still sits underneath the megacorp.

[1] https://ai.google/principles/

I really like that there is active research being done in this area.

It's interesting to see a constructivist lens applied to teaching concepts in computer science, and I would agree with the author that Dijkstra's insistence on a "blank mind" is the wrong approach. It seems like it would limit learning to those who "just get it", especially for introductory concepts that are typically taught to students who don't have the maturity to dive into abstract reasoning straight away.

I think that Berkley's Diversity Oath is not excluding people based on ideology, but rather based on their ability to do the job.

Berkley seems to have taken the stance that part of being employed at the university means making contributions to diversity, equity, and inclusion. The self-authored vow is the way they choose to evaluate candidates on their ability to perform these tasks.

You could argue that making contributions to diversity shouldn't be part of the job description, but this seems like a much harder angle to argue. Then again, maybe in the 1950's the same seemed true of being anti-communist...

I can't put my finger on it, but there must be a name for this kind of logic. I think pgs arguments have more sustenance than just this, but it still rubs me the wrong way. I'll give an (extreme) example below.

1. Make a statement, calling out some part of the population as "inferior".

2. Note that a trait of belonging to the inferior class would be to disagree with the above statement.

3. Dismiss any criticism of the statement as coming from someone in this inferior class, and therefore being unable to give meaningful arguments.

I would also argue that the intersection of people who become quants / found successful startups and did so despite having a real shot at becoming a professor is pretty small.

My only real data points are my own graduate school experience, but I haven't heard of anyone who was on a path to success in academia who didn't continue on down that path, or at least give it their absolute best shot before moving in. By success I mean maybe a post-doc or two followed by a reasonable shot at a tenure-track position at a decent school. This restriction is made in the same way that (I am assuming) pg is only referring to quants at decent firms, and startup founders who at least have an idea they can get off the ground. I seriously doubt that any kind of conformism at say, an ivy league institution, is because people who would have become profs there chose not to.

The comments, anecdotes, and historical context he gives the papers are by themselves a great read, especially if you're even somewhat familiar with the results. The comments on #12, which introduces the Bakery Algorithm [1] are a great example of this.

[1] https://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm

Funny, I'd say that writing proofs is a lot like building an airplane, and software engineering might be far away from both.

In writing a proof, you provide an argument that justifies some claim is true. Your argument has to be airtight, so that no matter what kind of counter example or ugly scenario is proposed, your argument still holds.

The same seems true for an airplane. It needs to do its job (fly) and do so on the face of a myriad of different external factors. If you build a plane, it should "never" fail.

Software on the other hand, can be built without thinking about ALL of these edge cases. Obvious it's better if it always works, but it's usually okay if there is some bizarre scenario that causes an error. For some pieces of software it might even be okay if these errors never get fixed (ie: a very small number of users ever experience them). Software can work, even when it (kinda) doesn't.

The Curry-Howard correspondence might be technically true, but we're just as bad at writing specifications for programs as we are at writing the programs themselves. It could be good to acknowledge that and just write the software that solves most, but maybe not all, of our problems.

Only somewhat related, but I recently found out that the dev who created Finite State Machine Designer [1] (which I used extensively in my undergrad) is Evan Wallace, the CTO of Figma.

[1] http://madebyevan.com/fsm/

I think I fall into the "don't get it" category. Could you explain what I should be taking away from this?

I understand that being at the leading edge has benefits, but it's not feasible to understand the state-of-the-art across an entire CS curriculum.