Beware of Async/Await - <AUTHOR> https://www.brandons.me/blog/async-await <comment><USER2> Curious - did anyone look at the first example and not immediately see that the requests would occur in series? IMO the "await" actually makes this much _more_ explicit.

<comment><USER3> I did have this misunderstanding when relearning Promises and Async/Await in JS. The misunderstanding is actually not about await but about when a Promise is executed. The question you ask yourself when learning Promises is why calling await on a promise directly vs calling it on a variable containing a promise is different. Of course the root cause of the misunderstanding is not understanding Promises are executed immediately and await blocks on a promise. So creating a promise after an await causes the second promise to be executed after the awaited promise is resolved.

For me I still had my mental model from a lazy execution environment (Dask) and that's where my misconception came from.

<comment><USER4> It's a common problem with many languages - I've experienced it recently myself with Rust's futures. It requires you to be explicit about spawning tasks since that requires a heap allocation and it took me a while to figure out that I had to explicitly include an async runtime (of which there are several) and start up the async tasks myself.

That said, I agree with the GP. I immediately saw that it was going to execute sequentially and thought nothing of it. Most of the time I use async/await not for concurrency but for syntax sugar and to get proper exceptions from promise based APIs instead of the GOTO FAIL control flow breaking nonsense that is catch().

<comment><USER5> It doesn't _inherently_ require a heap allocation, but the common, non- embedded use case does.

<comment><USER4> Yeah I was glossing over the specifics for this context. The way futures/generators are implemented as syntax sugar over a closure/state machine that can live on the stack is one of my favorite features of Rust, but i.e. an executor that uses a smallvec task queue is a bit esoteric for a discussion that started around Javascript.

</comment></comment></comment></comment></comment><comment><USER6> While the idea is correct, the proposed solution is needlessly verbose. A better solution would be to

      async function getPeople() {
        const [members, nonMembers] = await Promise.all([
          fetch("/members"),
          fetch("/non-members"),
        ]);
        return members.concat(nonMembers);
      }

The gist of the article is very true though. This is something that comes up every now and then in code review, even with seasoned developers. I'm not entirely sure what the solution would be since depending on the context, both sequential and parallel execution can be correct. It might just be one of those rite of passage type of mistakes you have to make once or twice.

<comment><USER7> or

        async function getPeople() {
          const membersPromise=fetch("/members");
          const nonmembersPromise=fetch("/non-members");
          return [].concat(await membersPromise, await nonmembersPromise);
        }

edited to fix typo spotted by lhorie. thanks.

<comment><USER8> I expect that will execute sequentially though as opposed to the solution above it.

<comment><USER9> Judging from your comment history, are you perhaps used to writing asynchronous code in Rust? In most languages, `Futures` start executing from when they are spawned. This is opposed to Rust, where they execute when they are `.await`ed.

<comment><USER8> Ok, 3rd edit. The promises are awaited in sequence but since they are both started before the first await they are run in parallel.

Your question about Rust futures makes a ton more sense now. This only works because a promise is self-executing / not inert like a Rust Future. Thank you kind stranger! Your async-foo is strong ^_^

</comment></comment></comment></comment></comment><comment><USER10> I'm not a JS programmer so the intended "simultaneous" waits only vaguely registered as possibly problematic.

However, after reading the article it is, at worst, a performance problem.

...and performance should come after the code is correct and I don't think the code is even semantically correct in the first place.

I'm assuming that "members" and "non-members" are distinct subsets of all People. i.e. it's not possible to be in the "members" and "non-members" sets at the same time. Additionally, everyone is in one or the other.

Because the set membership is queried with 2 independent queries (designed in a reasonable and common RESTful manner) there is a race condition where an object (that changes in the time between the two calls) might appear in neither or both of the sets.

These results are then blindly concatenated together.

If the API wants to retain its RESTful design, it must include metadata about the consistency between calls. For example some kind of token that can be compared to check that the replies to the two queries represent a consistent view of the data.

If the tokens, differ, the "transaction" can be retried.

Alternatively, the API can be designed, possibly making it less RESTful in the process, so that the transaction is implemented on the server.

There are many other ways to guarantee a correct and consistent result.

Either change has big enough implications that optimising for performance at this stage would be premature because of the amount of refactoring necessary to implement `getPeople` in a way that provides consistent and correct semantics.

<comment><AUTHOR> You make a valid point, which I probably should have mentioned, that this doesn't apply for stateful calls. But in my experience it's a common use-case (at least on the front-end) to grab two or more independent datasets, from stateless endpoints, at the same time, for display purposes. And putting those into a sequence can have a dramatic impact on perceived performance. I don't think a performance factor of 2x or more is a micro-optimization that one should hold off on making until a later pass.

</comment></comment><comment><USER11> Sometimes (most of the time?) you want to run two async functions in series because the input of one function depends on the output of the other, or because you want the side effects of each to happen in the correct order. This is the whole point of promise chaining and the async/await sugar on top of it. Concurrency is hard, and I am glad that the default is something predictable but slow, rather than fast and racy.

<comment><USER12> Except the default is exactly fast and racy:

fetch(x); fetch(y);

vs

await fetch(x); await fetch(y);

</comment></comment><comment><USER13> Would this not also work?

        async function getPeople() {
          const members = fetch("/members");
          const nonMembers = fetch("/non-members");

          return (await members).concat(await nonMembers);
        }

<comment><AUTHOR> Interesting, it actually does. I agree that's cleaner than the Promise.all() pattern.

</comment></comment><comment><USER14> I hate that await has made it easy to turn JS in to a synchronous language. I see so much front end code that would be better for users without await, but lots of developers prefer to write code that's easier to think about rather than fast. It's hugely annoying.

<comment><USER15> But very little code has to be fast, right? Best to prioritize making code "easier to think about" and thus more likely _correct_ , then to profile and optimize the bottlenecks.

<comment><USER16> All the code in the UI should better be fast, else the UI drowns in annoying molasses real quick.

So no, performance does matter a lot here.

<comment><USER15> I don't dispute that UI code needs to be fast overall, but it's still the case that only a small proportion of the code needs to be fast in order for the whole thing to be fast.

FWIW I worked in the search/database space for a decade and it's the same thing there. There was one time I wrote a lock-free hash table implementation for a registry that needed to be optimized for concurrent access; that code was much harder to write and to understand than the rest of the codebase, but it was justified. Most of the codebase, though, was not performance-critical.

EDIT: I will grant that you still need to think about how to architect the project so that it is optimizable later, which can mean thinking about what needs to be async early on.

</comment></comment></comment></comment><comment><AUTHOR> Author here: lots of people are weighing in saying this is a micro- optimization and/or an uncommon case (making independent, stateless requests in parallel). My suspicion is that these people are not front-end programmers (a factor that I hadn't considered as making a difference, when writing this post).

On the server, maybe having a set of requests take two seconds instead of one second (without consuming extra CPU cycles) doesn't really matter. On the front-end, it matters a whole lot. People go to much greater lengths to shave off much smaller amounts of time. Otherwise people on orange websites complain about your site being slow ;)

On the server, maybe it's a really common case to be making requests that modify state, and/or to be stitching together several microservices that require IDs or other information to be passed between them. On the front-end, especially on first-load, you're often loading up several different datasets purely for display purposes. These are rarely written to depend on each other, because of the latency issue in my previous point.

It is interesting though to see that there's a difference in norms/use-cases between the two.

<comment><USER17> I don't think it's so much that a second is more significant on the front-end. An entire second is practically an eternity on the backend.

The main difference is how much latency a typical request is likely to have.

On the backend, this optimization would frequently only save you 50 ms, because you are making a low latency call to another service that you are running in the same datacenter.

<comment><AUTHOR> That's a good point. And I guess the payloads will often be smaller, because the large datasets often just stay in the DB until needed. Whereas if the front-end needs to load data for a huge table (from a location that's obviously not in the same datacenter), it's easy for this optimization to save you hundreds of milliseconds if not entire seconds.

</comment></comment></comment><comment><USER18> I think people miss the wait part of await and hence forget they can separate the creation and consumption of a promise. Should have been called waitFor!

<comment><USER19> As a non-JS person, I thought it was obvious what await does, but now I'm second guessing myself. What does it do that's not the "wait" part? Is it not simply causing a normally asynchronous function to block?

Edit: Sorry for the late edit, but: Is it because users are using it thinking it just "unwraps" a promise into its resulting value? I can begin to understand that, but it seems so incidental to the primary concept of "waiting" for something asynchronous to return.

</comment></comment><comment><USER20> I thought this was going to be able stale data and race conditions, which is a much more insidious problem, IMO. The trifecta of mutability, shared state, and async operations can cause some very hard to reason about bugs.

</comment><comment><USER21> Clickbait title. Beware of not reading the docs and making noob mistakes.

</comment><comment><USER22> The way I would write the code is never covered, and I can't tell it's because I don't understand async, or I'm secretly a genius.

The article says this is correct.

> const both = await Promise.all([ members, nonMembers ]); > return > both[0].concat(both[1]);

I would have written it this way without the third promise.

> return (await members).concat(await nonMembers);

Is this wrong somehow?

<comment><USER16> This is not wrong, it's just not parallel. That is, the second promise, inside `.concat()`, will only get created and scheduled _after_ the `await members` will have resolved.

The point of `Promise.all` is to have every promise passed to it to start computing concurrently, likely in parallel if they e.g. start independent I/O operations.

<comment><USER23> If I follow your statement, it doesn't appear correct. JS Promises are eager, and the work underlying the promise will begin executing prior to being awaited. Await is just blocking on that execution's resolution.

        // Given:
        const fooPromise = asyncFoo();
        const barPromise = asyncBar();

        // Then this...
        await fooPromise;
        await barPromise;

        // ...is equivalent to this:
        await Promise.all([fooPromise, barPromise]);

Now, Promise.all() is useful, but it is unrelated to when computation starts.

<comment><USER16> I can't get it, and from my experience, this is not true.

Consider:

      const x = await foo();
      await bar(x);

How can you schedule `foo()` and `bar()` in parallel, when they have an explicit data dependency?

<comment><USER22> > How can you schedule `foo()` and `bar()` in parallel, when they have an > explicit data dependency?

You can't, but that's a fundamentally different scenario than what's being discussed.

</comment></comment></comment></comment></comment><comment><USER24> > Can you spot the problem with this piece of code?

Sure. There's no error handling :-)

(Also, if it's not some magic fetch, the return value needs to be json-ed.)

<comment><USER25> There doesn't need to be, if you expect the caller (or the top-level code) to handle errors.

Also, how should the function handle errors? It's not immediately obvious. An empty array is not the correct thing to return (an empty array could be a valid return value). Returning undefined/null would be another option, but that hides the error from the caller (which might be interested in the exact error message, to be able to properly deal with it).

<comment><USER2> Simple!

try { ... } catch (e) { throw "an unknown error occurred" }

;)

</comment></comment></comment><comment><USER26> Hack has a more readable "fix" now, which will hopefully make it to JS in due course:

      async function getPeople() {
        concurrent {
          const members = await fetch("/members");
          const nonMembers = await fetch("/non-members");
        }

        return members.concat(nonMembers);
      }

<comment><USER2> ...why? Please, please, don't add syntax to "fix" semantics that can already be elegantly expressed using existing constructs (Promise.all). Minimal-ish syntax is one of the few areas JS gets things right.

<comment><USER26> Your argument can be applied against await/async in general - it doesn't allow anything Promises didn't allow before.

The reason is that it's easy to make a mistake when destructuring the Promise.all call, and the Promise.all call doesn't scale well (here dummy example, spot the bug)

      const [foo, baz, bar] = Promise.all([getFoo(), getBar(), getBaz()])

This is much more readable and less error prone:

      concurrent {
        const foo = await getFoo();
        const bar = await getBar();
        const baz = await getBaz();
      }

<comment><USER2> There's always a line and it must be drawn somewhere. Async/await allow for chaining deferred execution blocks without introducing deep syntactic nesting, at the cost of 2 keywords. In my opinion the benefits of flattening the language outweigh the costs of adding the keywords.

The hack approach otoh introduces an entirely new syntax construct (tagged blocks), which declares variables that escape their initialization block (unexpected in the JS world post-let/const), and strongly leverages the existing hack execution model whereby all await's in a single statement are executed concurrently. This execution model is incompatible with the rest of JS (hack disallows many styles of having multiple awaits in an expression, such as `await a && await b`), and at the end of the day what are the benefits? It executes a series of statements in parallel, exactly the same as Promise.all.

If you're concerned about mixing and matching declarations, maybe try

let foo, bar, baz;

await Promise.all([

       foo = getFoo(),

       bar = getBar(),

       baz = getBaz()])

?

Edit: realized in the above example the variables remain of promise type, which isn't great. One could alternatively do "getFoo().then(result => foo = result)", but I agree this isn't great either.

</comment></comment></comment></comment><comment><USER27> Why is this article so highly upvoted? The problem clearly isn't with Async/Await itself.

<comment><USER19> This is what's confusing me - I have no problem with the complaint that a language feature is confusing or unfriendly to beginners, but in this particular case, why would somebody who doesn't know what await does even use it? What are they expecting it to do besides wait?

</comment></comment><comment><USER28> I'll admit that I don't know a lot about JavaScript, but it's a bit surreal coming from a Scala background and reading this blog. Like, I literally couldn't understand how someone could make this mistake, until I remembered that there're no types in JS. On that same note, Rust takes things even one step further and adds a "lifetime" axis, which if you're used to then a similar blog post about memory access issues would be met with equal confusion about the author's confusion. Hope that made sense.

</comment><comment><USER29> You are not supposed to await immediately on the async tasks. Let them get fired in parallel without the await. Apply await only when you need to see the resolve/reject results.

</comment><comment><USER30> The interesting point about this example is that an intelligent js compiler could easily rewrite this code into parallel execution. Its possible because the low-level await statement is declaring to wait on the execution but the calculated value is used much later first.

Maybe someone could built this for typescript, the strict typesystem should make this easily (?) solvable by some hidden wrapper type, like AwaitedButUnaccesedPromise.

<comment><USER6> The problem is it may be intentional to have the requests be sequential depending on what you're doing. It would be straightforward to identify this kind of code, but the compiler wouldn't be able to tell which was the correct business logic.

<comment><AUTHOR> Yes, as another commenter pointed out, this would get you into trouble if the endpoint you're calling is stateful at all. And that's definitely not something a compiler could ever reason about.

<comment><USER30> Oh thats true, didnt think about it. But this problem could be easily solved by adding a "defer" keyword which is basically await under the hood with the added compiler optimizations.

</comment></comment></comment></comment><comment><USER31> I thought it was about lack of error handling.

Running them in parallel is not a solution. I would create a new API call to fetch both.

</comment><comment><USER32> Of the potential footguns with async/await, I'd rate this as low to non- existent. This falls into the category of straightforward code which gets a task done and which hasn't been optimized to within an inch of its life.

</comment><comment><USER33> Another issue: you could end up with duplicate people in the set if they are moved 'member <-> !member' between each read.

What you would need is a single HTTP request that uses a DB read transaction to get the whole set of people.

</comment><comment><USER34> I wouldn't call it necessarily a "mistake" but certainly something you would want to avoid doing if you want your code to be performant.

</comment><comment><USER35> I actually like making this kinda mistake, because it means I can get some easy performance gains in a bugfix release!

</comment><comment><USER36> The clue is even in the name. What do you expect to do on the keyword "await" except stop and wait?

</comment><comment><USER37> I miss the defer keyword in coffeescript.

</comment><comment> rough-sea The mistake is not getting the body of the response. Is it even meaningful to concat two response objects.

It's amazing what gets upvoted on HN.</comment>


Why Is Hollywood So Scared of Climate Change? - <AUTHOR> https://www.nytimes.com/2019/08/14/movies/hollywood-climate-change.html <comment><USER2> What I'm getting tired of is Hollywood films, documentaries, awards, etc. preaching to me.

Specifically nature documentaries, when I watch recent productions I get the feeling that they aren't trying to show the results of studying nature, to educate about this or that: I get the feeling that they are packaged environmentalist manifestos (look at all these cute little animals that are going to _die_ because you don't recycle) either made to shame/enlighten people who don't do _the right thing_ or to boost the egos of people who _do good_.

It bothers me because it so often feels shoehorned in and off topic. I wouldn't mind at all if it were the topic, but injecting it into every topic is the problem.

Using art as a tool is complicated. When overdone it is unambiguously wrong, when done correctly it can be a powerful good force, and somewhere in the middle is a wide grey area which is difficult to navigate.

<comment><USER3> The feeling of everyone studying the natural world now is one of overwhelming loss, that everything they've devoted their lives to is disappearing before their eyes. There isn't any way to make an honest nature documentary and _not_ include that. To do otherwise would be to pretend that the careful selection they do to show a pristine wilderness and healthy animals is reflective of reality.

<comment><USER2> > The feeling of everyone studying the natural world now is one of > overwhelming loss

I am beginning to have my doubts about the reasoning behind these feelings.

It is not that I deny that there are problems which have happened, are happening, and certainly will happen.

I'm starting to think most people thinking, talking, and feeling about it are being driven and biased by a shared sort of doomsday cult not in major but only subtle ways. "Everyone" just "knows" _it_.

There is loss, there is reason for concern, there is _change_ in progress, and lots of reasons to feel about it. The feelings though don't seem like they are driven by fact, reason, analysis, and – well – science, but driven by shared feelings and ambiguous knowledge that things are _bad_.

<comment><USER3> You should read a bit more about it. The changes are so visceral as to be unignorable.

[https://www.motherjones.com/environment/2019/07/weight-of- th...](https://www.motherjones.com/environment/2019/07/weight-of-the-world- climate-change-scientist-grief/)

>She had been taking these sorts of research trips for two decades, and over recent years she had witnessed about 85 percent of the island's reef system perish due to rising ocean temperatures. "I was diving with tears in my eyes," she recalls.

[http://theconversation.com/sadness-disgust-anger-fear-for- th...](http://theconversation.com/sadness-disgust-anger-fear-for-the-great- barrier-reef-made-climate-change-feel-urgent-119232)

> We found a large proportion of respondents, including Australians and > overseas visitors, expressed forms of grief in response to loss and damage > to the iconic ecosystem. Negative emotions associated with words given in > short statements about "what the Great Barrier Reef means to you", included > sadness, disgust, anger and fear.

[https://www.theguardian.com/world/2019/aug/12/greenland- resi...](https://www.theguardian.com/world/2019/aug/12/greenland-residents- traumatised-by-climate-emergency)

> 76% claiming to have personally experienced global heating in their daily > lives, from coping with dangerous sea ice journeys to having sled dogs > euthanised for economic reasons tied to shorter winters.

</comment></comment></comment></comment><comment><USER4> Why is the working class responsible for fighting climate change? Why must Hollywood "challenge audiences to change their ways"? Especially when China is building 300-500 new coal plants?[0][1]

Actually, as individual consumers, the best way one can lower one's carbon footprint is to not spend money. Don't buy the brand new cars product placed in films. Don't drive to the theater, wait until the movie can be streamed. And don't buy candy or soda or beer in theaters. Use as little resources as possible.

[0] [https://unearthed.greenpeace.org/2019/03/28/china-new- coal-p...](https://unearthed.greenpeace.org/2019/03/28/china-new-coal- plants-2030-climate/) [1] [https://www.npr.org/2019/04/29/716347646/why-is- china-placin...](https://www.npr.org/2019/04/29/716347646/why-is-china- placing-a-global-bet-on-coal)

<comment><USER5> > Especially when China is building 300-500 new coal plants?

China is also building a ton of renewable energy. They're building a ton of _everything_ and "India and China are doing X" isn't a reason for others to do nothing.

> Actually, as individual consumers, the best way one can lower one's carbon > footprint is to not spend money.

I can't upvote this enough. This is the best way for individual consumers to make a difference.

<comment><USER6> > This is the best way for individual consumers to make a difference.

Disagree strongly. Individuals cannot solve this on their own, it can only be solved at the national and international level. This means voting and ensuring that politicians know that your vote rides on their action: letter writing, protests, et cetera. And of course politicians won't do anything until such intentions are widespread, so this means grass-roots movements.

<comment><USER5> I'm not advocating selective boycotts of things or companies that are bad actors - those are not effective. I'm also not saying it's the best way for individual citizens to make a difference. Obviously laws are better because of the tragedy of the commons/prisoner's dilemma nature of the problem. Whoever pollutes will outcompete whoever does not because (currently) it's cheaper to pollute than to not.

I was saying that the best way to make a difference as a consumer is to be less of a consumer. Most people in developed countries buy way too much shit. Changing that is a win for the individual (more money in your pocket) and the environment. And doing this does not preclude pressuring your elected representatives for broader change.

</comment></comment></comment></comment><comment><USER7> > "The past 25 years of the environmental narrative is about sacrifice and > doom and not doing what you want and not getting what you want," said Aaron > Matthews, head of industry sustainability at BAFTA. "We don't think that's > the right tone to get people over the line."

It's not Hollywood's job to _get_ people over the line.

BAFTA could always create an incentive to make the kind of film they want to see. Maybe an award for best film featuring environmental issues.

</comment><comment><USER8> Hollywood isn't scared of climate change. They are good at understanding what we're scared of and making entertainment out of it.

What you see in Hollywood is nothing but a reflection of our own fears.

Also note that Thanos cutting the population in half isn't going to solve environmental problems. Humans reproduce at an exponential rate so cutting the population in half is ultimately futile.

<comment><USER9> Most of the developed world is already reproducing below replacement rate.

<comment><USER10> Most of the world is not the developed world (population-wise), and is reproducing well above replacement rate.

So, what's your point?

<comment><USER9> Most of the world is already on sub-replacement. The only worth mentioning exception is Africa.

<comment><USER10> I really don't know where you're getting your information. Geographically, most of the world's nations still have a positive population growth rate, including some developed nations such as the US[1]. India may have a lower proportional growth rate than some African nations, but since its population is already very large, it contributes more to the overall world population growth than any country[2]--surely this is "worth mentioning"?

[1] [https://ourworldindata.org/grapher/population-growth- rates](https://ourworldindata.org/grapher/population-growth-rates)

[2] [https://en.wikipedia.org/wiki/Projections_of_population_grow...](https://en.wikipedia.org/wiki/Projections_of_population_growth#Growth_regions)

<comment><USER9> As always, I rely on OWID

[https://ourworldindata.org/grapher/children-per-woman- UN?tab...](https://ourworldindata.org/grapher/children-per-woman- UN?tab=chart&time=1950..2015&country=OWID_WRL+IND+USA+Africa)

Go to interactive mode. India and USA are already on sub-replacement. China is way under. Africa is the main reason world's population is still growing.

<comment><USER10> Did you even read my post? OWID was one of the links I cited.

I'm not sure how to go to interactive mode, but the chart you linked _does not_ say that India and the USA are on sub-replacement. That's a graph of TFR, not population change, and it shows 2.35 children being born per woman in India as of 2015, so by itself the chart proves that India is increasing the world population. The rates are 1.87 for the US, which is sub-replacement, but the US also has increasing population due to immigration. Obviously that isn't a change to the world's population, but if you're counting immigration out of other countries in population change, you have to count immigration into the US.

To quote Wikipedia:

> From 2017 to 2050, nine countries are expected to account for half of the > world's projected population increase: India, Nigeria, the Democratic > Republic of the Congo, Pakistan, Ethiopia, Tanzania, the United States, > Uganda, and Indonesia, listed according to the expected size of their > contribution to that projected population growth.

5 out of 9 of those countries are in Africa, but note that India is #1.

Note that if you look into where they are getting their data, both OWID and Wikipedia are citing the UN DESA.

Also note that a decline in population growth rate is not the same as a decline in population. Growth rates have been in decline worldwide since the 1950s, but are still positive, meaning population in those countries is still growing.

<comment><USER9> India's TFR is reported 2.2-2.3 for 2018. That is, for a developing country with high child mortality, the replacement rate.

<comment><USER10> How high is child mortality? 4.1% as of 2016[1]. Even using your low number (2.2) that you didn't cite, 2.2 * (1 - 0.041) = 2.109, still above replacement. Please at least try to look up the statistics and form your opinion based on them, rather than forming your opinion and making up claims about the statistics based on your opinion.

Why don't I just make this really simple for you: India's population will grow by 1.10% annually from 2015-2020 according to UN estimates from 2017.[1] If that's not recent enough for you, India is projected to grow 1.08% in 2019.[2] So however you want to argue this, India's population is growing. As I said and cited before, its absolute (not proportional) growth is greater than any other country in the world.[3]

[1] [https://en.wikipedia.org/wiki/List_of_countries_by_populatio...](https://en.wikipedia.org/wiki/List_of_countries_by_population_growth_rate)

[2] [https://www.worldometers.info/world-population/india- populat...](https://www.worldometers.info/world-population/india-population/)

[3] [https://en.wikipedia.org/wiki/Projections_of_population_grow...](https://en.wikipedia.org/wiki/Projections_of_population_growth#Growth_regions)

<comment><USER9> The fact that India's population is growing does not imply TFR is above replacement.

Now you can go back up to my original post, and see what it was about (I was replying to someone claiming that halving world population won't help as we are "reproducing exponentially"). I think you are trying to make some point I probably agree with (or correct something I've said but it's unclear what)

<comment><USER10> > The fact that India's population is growing does not imply TFR is above > replacement.

That's true: the UN measuring the TFR being above replacement is what implies that the TFR is above replacement.

You just ignored half the post you responded to, so I'll say it again: How high is the child mortality rate? 4.1% as of 2016[1]. Even using your low number (2.2) that you didn't cite, 2.2 * (1 - 0.041) = 2.109, still above replacement.

> Now you can go back up to my original post, and see what it was about

My original point was that the TFR for developed nations is fairly irrelevant given the overall world population is still growing. But we're well past the point where you can maintain any credibility based on your original post anyway, because you've made a bunch of erroneous claims since then. All the following are wrong statements quoted from you:

* Most of the world is already on sub-replacement. The only worth mentioning exception is Africa.

* India and USA are already on sub-replacement.

* India's TFR is reported 2.2-2.3 for 2018. That is, for a developing country with high child mortality, the replacement rate.

Since you are now selectively reading the facts, my posts, and even your own posts, to try to draw attention away from where you're wrong, I don't think you're engaging in good-faith debate any more, so I'm done.

<comment><USER9> This is not how replacement rate is calculated.

The common formula/approximation is inverse of product of probability of reaching mean fertility age and female ratio.

The female ratio in India is 0.482. The other factor I have no idea. If it's ~94% then 2.2 is the replacement rate. I think that's fairly high provided we start at 96.8% but who knows.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


The Double Crossed Life of David Karr - <AUTHOR> https://www.tabletmag.com/scroll/289876/the-double-crossed-life-of-david-karr <comment><USER2> I wonder if Karr was the unidentified journalist in the decoded Venona cable who took considerable money to write at least one article before he took on the Paris personality.</comment>


NIH's mental health chief on why he's leaving for Google - <AUTHOR> https://www.washingtonpost.com/news/to-your-health/wp/2015/10/08/nihs-mental-health-chief-on-why-hes-leaving-for-google-technology-may-hold-key-to-better-diagnosis/ <comment><USER2> I wonder if they are going to plan to mine people's search patterns? I don't know about you, but I've never lied to Google about my intentions. When I was feeling very depressed, I'd often search for sad things, or even "ways to kill myself". I imagine a lot of other people do so as well, and aren't even aware their search history is monitored by Google -- and if they are, they think it can be cleared by deleting their Internet history in their browser.

There is again a fine line between privacy and what will help the individual and society at large. The most pressing questions will not be what new analytical methods we can create to better identify mental illness from Google's data. I've seen the quality of the mental health system from a close friend's perspective (in the US at least) and all I can say is you don't want to get mixed up with it; it often has the same outcome and social stigma as a criminal record.

<comment><USER3> It's really a challenge to use search in this way. The searcher could be depressed, or be a worried friend of some who's depressed, or be a writer looking for story ideas, or be a family member of the last person who used the browser, etc.

<comment><USER4> Something like the individualized advertising model Google has for each person could probably be used in tandem to segment that more reliably.

</comment></comment></comment><comment><USER5> Is anyone but me conflicted about the idea of Google being involved in "identifying who is at highest risk and developing interventions that preempt psychosis", given that Google's primary product is detailed personal information about everyone?

<comment><USER6> Two opportunities to plug PSYCHO-PASS in one day? We're on a roll, HN!

But seriously, if Google co-opted people's smart phone data to do covert psychological evaluations on a constant basis we'd literally be one step removed from the dystopic future PSYCHO-PASS depicted. Albeit a big step (sending out armed teams to apprehend at-risk subjects before they have a chance to hurt themselves or others).

<comment><USER7> >Albeit a big step (sending out armed teams to apprehend at-risk subjects before they have a chance to hurt themselves or others).

Look at the story behind the police officer who was committed for trying to expose police quotas. Is that not the same as an armed team coming to commit you... just for an even less justifiable reason?

<comment><USER8> Do you have a link for this?

</comment></comment></comment></comment><comment><USER9> There are some interesting machine approaches to early diagnosis and prediction of psychosis.

Who will develop psychosis? Automated speech analysis may have the answer: [http://www.sciencedaily.com/releases/2015/08/150824110809.ht...](http://www.sciencedaily.com/releases/2015/08/150824110809.htm)

[http://www.theatlantic.com/technology/archive/2015/08/speech...](http://www.theatlantic.com/technology/archive/2015/08/speech- analysis-schizophrenia-algorithm/402265/)

[http://www.nature.com/articles/npjschz201530](http://www.nature.com/articles/npjschz201530)

I'm interested to see what Google can do. Early diagnosis and rapid start of an early intervention team dramatically improves outcomes.

</comment><comment><USER10> Maybe just replace the water supply Fluoride with a Paxil/Zoloft combination.</comment>


How to Keep Messages Secure - <AUTHOR> http://www.teenvogue.com/story/how-to-keep-messages-secure <comment><USER2> Teen Vogue has just been amazing recently.

Some other great pieces:

 _" What It's Like to Be a Teen Living in an Immigration Detention Center"_

[http://www.teenvogue.com/story/teens-living-in- immigration-d...](http://www.teenvogue.com/story/teens-living-in-immigration- detention-center)

 _" How to Run for Your Local School Board"_

[http://www.teenvogue.com/story/how-to-run-local-school- board](http://www.teenvogue.com/story/how-to-run-local-school-board)

 _" The TPP: What's Next for America and the Other 11 Countries"_

[http://www.teenvogue.com/story/the-tpp-whats-next-for- americ...](http://www.teenvogue.com/story/the-tpp-whats-next-for-america-and- the-other-11-countries)

And of course the classic, which put Teen Vogue on the radar for a lot of people who wouldn't read it otherwise:

 _" Donald Trump Is Gaslighting America"_

[http://www.teenvogue.com/story/donald-trump-is- gaslighting-a...](http://www.teenvogue.com/story/donald-trump-is-gaslighting- america)

Mad props to them; they've been putting a lot of other "grown up" news sources to shame. In an ideal society, school should be what ensures teenagers turn into educated, balanced citizens who can contribute healthily to society regardless of their socio economical upbringing; but the US's school system (and many others) seem to have given up on that. Glad that Teen Vogue is trying to do their part.

<comment><USER3> I subscribed to Teen Vogue for their investigative journalism.

...Never in a million years did I ever think I would be writing that.

<comment><USER4> I just checked out what their subscription actually means and I am a little dumbfounded.

\- "1 year of Teen Vogue in print and tablet for $5" \- nice, that's cheap. But can't I do digital only?

"For delivery to a non-US address, please click here."

\- Digital only "All non-US orders" \- One year for $9.99

WTF

<comment><USER5> Ads. The print ad rates are set based on the subscription count. They are a big chunk of the revenue for those subscribers.

<comment><USER4> Thanks for trying to explain it to me - but I still don't get why I shouldn't find a friend in the US to get the paper issues mailed to them (to throw them away, or read them) and still only pay half of the price.

Probably the same thing as every geo-location access (i.e. Steam prices often equalling 1 USD = 1 EUR) - but I've never seen _such_ a severe disconnect.

</comment></comment></comment></comment></comment><comment><AUTHOR> This is a really good example of how to write about security for a general audience, and how to source such an article. Teens need good advice about how to safeguard their online lives, and how to think realistically about the threats they face.

Kudos to Teen Vogue for a terrific piece of journalism.

</comment><comment><USER6> Wow, Teen Vogue can teach the Guardian a thing or two about how to listen to relevant people and how to get the facts right.

The whole Guardian incident shows the desire/need of media outlets to write sensationalist pieces even though the stories are completely misleading and could potentially cause at risk users to move to less secure communication platforms. Anything that triggers outrage always gets more eyeballs which translates to more ad revenue and this seems to be the driving force for media outlets these days.

It's obvious that the authors and editors over at Guardian are aware of how misleading their articles about WhatsApp's so called backdoor were, yet they have no incentive to acknowledge that they were wrong and retract those articles. Another case of media outlets' incentives not being in the best interest of the general public.

Also worth mentioning another case where media outlets chase sensationalism over facts, proper research and due diligence was the Wallstreetjournal's piece on Youtuber pewdewpie being anti-semitic. WSJ again ran misleading articles about pewdewpie and took a lot of videos completely out of context to make him look like a nazi. That piece led to many deals/contracts with media companies being canceled because of public outrage.

The point is, fake news has real consequences. Imagine the consequences of activists adopting email or telegram to exchange messages in oppressive regimes, becuase of Guardian's articles.

<comment><AUTHOR> Here's a timeline of the Guardian's coverage and subsequent response. They tried to stand by their misleading articles, then said their ombudsman was on holiday, and were never heard from again.

[https://docs.google.com/document/d/1nqlE6UQjbUmgoMeJCePVcY5f...](https://docs.google.com/document/d/1nqlE6UQjbUmgoMeJCePVcY5flqn8hAhmfIjeVE8PnEk/edit)

</comment></comment><comment><USER7> Someone told me last weekend that Teen Vogue was covering the political situation well and providing good technical stories. Of course, I had to ask them to repeat the name of the publication. Good for Teen Vogue.

</comment><comment><USER8> I now have more respect for Teen Vogue than I do for The Guardian.

What upside down world am I living in?

</comment><comment><USER9> It's incredible to see Teen Vogue be so frank about the necessity of obscuring one's political activities, even if they are peaceful in nature. Governmental vengeance aside, you simply do not know what could lead to your next denial of healthcare or your being blacklisted by the company you've been trying to join for years.

</comment><comment><USER10> All teenagers need to use secure messaging unless they want 60 year old NSA agents passing the photos they send to their boyfriend around the office.

</comment><comment><USER11> You know, I still don't get why people jumped on The Guardian and Tobias Boelter about the WhatsApp debacle. People keep trying to frame it as "they told everyone to give up on encryption", when it was blatantly clear to me that the message was "you can do better than Facebook for encryption".

I _do not_ like this kinda stuff:

> "If you're a whistleblower like Edward Snowden, or if you are a politician, > or if you are a journalist who regularly deals with people at risk of > deportation, or if you work regularly in countries with harsh, repressive > governments… you will have a different threat model to someone who just > wants privacy because they're talking about intimate or personally important > stuff," says Muffett. In such extreme cases, Tufekci suggests you use Signal > to get in touch with experts such as the Electronic Frontier Foundation, who > can teach you the finer points of digital security.

> For the rest of us, the end-to-end encryption in WhatsApp is enough to keep > our chats out of snoopers' hands. Indeed, privacy invasion may not come from > the NSA or security services, but the people in your life — if you want to > keep your parents or siblings from seeing your messages, you don't need a > secure app so much as a PIN to unlock your phone.

This is not okay. This basically says, "yeah, if you're a huge weirdo with a target on your back, you may want to use Signal". And yet I use Signal to casually talk with my friends about movies and food. I'd like to think that there's strength in numbers, I'd hate for Signal to be, rather than protective, a big bullseye for politically dangerous people.

The continued attack on Tobias Boelter and The Guardian about this, as if they had committed an unconscionable crime, is extremely jarring when people then praise this article that says to kids "privacy invasion may not come from the NSA".

I don't like being considered an "extreme case" for taking effortless, cost- free precautions that have a nice side-effect of not being part of Facebook's ecosystem. Look at this: "whether it's Facebook Messenger, WhatsApp, or a stronger tool such as Signal." It's basically an ad for Facebook properties.

<comment><AUTHOR> Nobody is attacking Boelter, or mentioning him. The fault here is the Guardian's alone, for not doing the basic kind of journalism that Teen Vogue demonstrates—asking multiple experts their opinion, and vetting their answers with other sources.

The problem with your advice to just use Signal is that Signal is not very usable. It routinely requires message resets, it sometimes initiates audio calls for no reason, it doesn't work in landscape mode.

And it is particularly unfriendly in scenarios where there is a key change (like someone reinstalling Signal in a group conversation). Some of these are bugs that will get fixed, some are tradeoffs required for a higher level of security.

I say this as someone who depends on the app, supports it wholeheartedly, and uses it to communicate with hundreds of people.

Normal users pressed to use Signal will fall back to SMS. This is not speculation, but documented behavior that we see happening among regular users. That's why the Guardian's hatchet job on WhatsApp was so harmful.

You can't give good security advice in a vacuum. Telling teens thinking of attending their first protest that the NSA is not their biggest threat is good security advice.

Telling them to use end-to-end encrypted messaging apps that have good UX is good security advice.

Reminding them that their biggest threat is the person they're sending the message to, or a nosy parent or sibling, is good security advice.

The article does a great job explaining this difficult topic in a way its audience can understand and act on.

</comment></comment><comment><USER12> You know something is wrong in America when Teen Vogue ends up on the front page of HN for a story on security nonetheless. Nothing about this presidency is normal.

<comment><USER8> I think accessible technology journalism in non-traditional venues is worthy of note, if only to see how our products are perceived in the wider world.

</comment></comment><comment><USER13> Is this my imagination, or are we seeing a lot of anti-Snapchat stories lately? It's like Facebook decided to run anti-PR on them lately.

<comment><AUTHOR> All this story does is correctly point out to people that Snapchat lacks end- to-end encryption.</comment></comment>


Using Docker to Run MySQL Server in Your Development Environment - <AUTHOR> https://harrisonbrock.dev/2019/02/03/using-docker-to-run-mysql-server-in-your-development-environment/ <comment><USER2> I work as a middleware support engineer. I work on tickets from people with all kinds of environments, so I frequently have to install different databases, message brokers, etc.

Using Docker for this is flat out brilliant. It makes setting up software much, much easier.

<comment><AUTHOR> Docker does make things easier. I have Oracle, MySQL, Postgresql all running in Docker.

<comment><USER2> Yup. Works great for LDAP servers, too!

</comment></comment></comment><comment><USER3> > Error establishing a database connection

Oh the irony...

<comment><USER4> I actually laughed out loud when I saw that.

<comment><AUTHOR> Fixed. But that was funny bad timing.</comment></comment></comment>


Bill Nye Debates Ken Ham - <AUTHOR> https://www.youtube.com/watch?v=z6kgvhG3AkI

<comment><USER2> I'm a scientist and I believe in the tooth fairy. Therefore the tooth fairy is real.</comment>


How to easily rename Git master branch to main - <AUTHOR> https://medium.com/@ggerritsen/rename-git-master-to-main-1af5669f041a <comment><USER2> In the context of Git, "master" is not used in the sense of a master/slave relationship but as a master copy. Are you hoping for a blanket ban of the word "master" regardless of the context?

<comment><AUTHOR> I'm mainly hoping to rid our technical vocabulary of non-inclusive terms, like master/slave, based on [https://tools.ietf.org/id/draft-knodel- terminology-00.html#r...](https://tools.ietf.org/id/draft-knodel- terminology-00.html#rfc.section.1.1.1)

<comment><USER2> Again, in the context of Git, "master" is not used as in master/slave. Words can have different meanings in different contexts. Should chess players stop using "master" for their titles? Should the music industry stop calling "master" the initial recording of an album that will get replicated?

<comment><AUTHOR> I don't think chess grandmasters should be necessarily named differently, though having a gender-neutral term would be better. Not sure about the master used in the music industry.

Do you know where 'master' originates from in the context of Git?

<comment><USER3> Yes, Petr Baudis decided on that name (and also "upstream"). [1]

He regrets it now because of his lack of English language knowledge at the time and that "main" makes more sense but he originally based it on the "master copy" concept.

I personally don't understand why people decided on this hill to die on. There are much better targets like database master-slave replication.

[1] [https://twitter.com/xpasky/status/1272280760280637441](https://twitter.com/xpasky/status/1272280760280637441)

<comment><AUTHOR> Ah interesting, thanks!

It seems then that master doesn't seem like a very loaded word in the context of git. Even so, changing it would then not be very impactful as well (not counting any CI/CD or other config that relies on the master branch name).

<comment><USER4> I think this discussion raises several interesting questions, two of which: "when is vocabulary non-inclusive?", and "should vocabulary be changed accordingly even if the word doesn't have an offensive origin?". I have played and replayed several debates on the latter in my head over the last 24 hours and it always comes down to someone arguing "why not?" with the counter argument being "where does it end?". To be honest I do not believe there to be a correct answer to these questions, and certainly not an answer that will last for more than a couple of years, maybe a decade. My personal belief is that inaction born from fear is always worse than action sprung from kindness (yes history has proven me wrong on multiple terrible occasions, I know) so I would say, change it, for a better world starts with the first step.

<comment><USER2> Not renaming the default branch of your version control system is not inaction. You should first ask: does it make sense and does it accomplish anything? While the cause is just, you still have the right to nuance your thoughts and actions, and not decide to ban words "just in case".

Let's be honest, the world isn't going to be better because the default branch of git is called main instead of master, but it will probably be slightly worse if you impoverish the language of hundreds of millions of people, which also happens to be the main international language.

As maushu said above there are much more meaningful targets.</comment></comment></comment></comment></comment></comment></comment></comment>


Limitations of protocols in Swift - <AUTHOR> http://inessential.com/2015/12/10/im_harping_on_this <comment><USER2> I'm not a Swift person, so I might be wrong, but this seems like a case where composition over inheritance is preferred. Protocols in Swift (and traits in Rust) are not supposed to be used to emulate classical inheritance; though they can be. Enums/ADTs/sum types/whatever you call them are what you're supposed to use in such cases.

<comment><USER3> I disagree. This is the classic case for protocols. Look what he says:

 _" I'm using a protocol for the Account type. There are classes that conform to the Account protocol: TwitterAccount, AppNetAccount, LinkedInAccount, etc."_

The important bit is the "etc." at the end. The types of accounts he wants to support is open ended. He also mentions a plug-in API. You can't have third parties come in and extend some algebraic data type.

If this is not a case for protocols then there is no such case at all and protocols should be removed from the language.

<comment><USER4> To me this looks like exactly the sort of situation where classical OO inheritance is the right answer. All of those things are kinds of Account and should have a common base class.

<comment><USER2> Classical OO inheritance is the right answer in a language that supports it, though. There may be equally ergonomic ways of doing it in languages with ADTs.

(Which may or may not be the case here, depending on extensibility)

</comment></comment></comment></comment><comment><USER5> This isn't a limitation of Swift, this is someone trying to write Objective-C in Swift.

Let's say he gets what he wants - a distinct collection of instances that fulfill the 'Account' contract, but are different types. The approach so far is that to fulfill 'Account' by providing an accountID. That accountID is what indicates if two 'Account's are equal. What if a Twitter account and Hacker News account have the same id? According to this protocol, they are equal.

The error message he is seeing about Self requirements is telling him this. That error message doesn't exist because Swift is having a hard time understanding the code, it exists because Swift understands that his code is wrong.

<comment><USER6> You're missing the point of what he's saying with a pretty dismissive statement. "Swift doesn't do that" is not a strong argument.

He specifically goes through why using protocols like that are a useful and powerful tool. He's making an argument about its usefulness and the ease of implementing it.

It is a really useful tool! It lets you show the commonalities and mask and private methods in classes. I would say that it would be a loss to not have this.

As for the "this might accidentally be seen as equal to something that is a different class" should not be a problem. In objective C isEqual implemented in a standard way is able to differentiate different classes from each other pretty much from the beginning of the method.

<comment><USER5> Not saying Swift doesn't do that, saying he's doing it wrong. Protocols can still be interfaces (what he and you are describing), there is no loss. Two types that simply implement a similar protocol are by definition not necessarily equatable. The 'standard' way that Objective-C implements isEqual: is _on a base class_ , which is a totally possible implementation in Swift as well.

<comment><USER6> That's the point he's making. He doesn't want a base class.

If you aren't lucky enough to have them be of the base class you have to create an empty template superclass just to satisfy the compiler. Objective-c has a better solution and things can dovetail without being in the same class.

"Doing it wrong" implies that Swift is just inherently better without making a real argument about why that would be the case. And the OP is actually making a pretty convincing argument that it isn't.

Swift is awesome at doing things better than obj-c and it really does reduce a lot of template code. But maybe not in this particular instance (right now).

<comment><USER5> He can't solve this problem without using a base class, so he wants to go back to Objective-C _where he will use a base class_? Objective-C does not have a better solution - it has the same solution here. The only difference is that ObjC will let you do what he is trying to do where the actual result is incorrect. That doesn't make Swift inherently better, it means he is wrong. OP is not making a convincing argument, and this isn't a point about Swift vs. ObjC. OP is just complaining because they don't understand what it is they are doing.

<comment><USER7> I don't think you understand what the parent is telling you at all.

It's clear from what they wrote that both the parent and the author of TFA know all that you described. The problem is not that they don't know these things or that they're "doing it wrong", it's that they disagree that the way Swift does is it's the better way, or in PL terms, the most expressive way.

> _Let 's say he gets what he wants - a distinct collection of instances that > fulfill the 'Account' contract, but are different types. The approach so far > is that to fulfill 'Account' by providing an accountID. That accountID is > what indicates if two 'Account's are equal. What if a Twitter account and > Hacker News account have the same id? According to this protocol, they are > equal._

So? There's nothing wrong with that. If that's how he defines equality and not at the class level, that's what he should get. He should still be able to use a set with his definition of "equal" (which he could trivially change anyway).

</comment></comment></comment></comment></comment></comment><comment><USER8> I don't know Swift, but the problem seems to be that you can't do

        extension ListItem: Hashable

where ListItem is a protocol. That's a little irksome, sure, but why not just do

        struct ListItemBox {
            var item: ListItem
        }

        func ==(lhs: ListItemBox, rhs: ListItemBox) -> Bool {
            return lhs.item.id == rhs.item.id
        }

        extension ListItemBox: Hashable {
            var hashValue: Int {
                return item.id
            }
        }

        var stuff: Set<ListItemBox>;

Of course, you should be very careful about cross-type equality here. But that's no easier with any other model either.

<comment><USER9> I think it can be reduced into simpler terms in fact. In swift you simply can't do

      var stuff:Set
      var stuff:Set<Hashable>
      var stuff:Set<MyProtocol>

Sets don't allow for mixed base types, and that's what a protocol would allow. All objects in a set must contain a similar base type. This is actually true in obj-c as well where everything in a set had to derive from NSObject.

</comment></comment><comment><USER9> One option available to him is to make Feeds conform to something he can guarantee will be hashable, specifically NSObjectProtocol. The would force all Feed objects to inherit from NSObject and hashability will come along for the ride, but I understand his desire to make things lighter.

</comment><comment><USER10> Two things which might be useful to him:

Rob napier's article on type erasure: [http://robnapier.net/erasure](http://robnapier.net/erasure)

Alexis Gallagher's talk on PATs and generic constraints: [https://youtu.be/XWoNjiSPqI8](https://youtu.be/XWoNjiSPqI8)</comment>


Robust Design Through Diversity (1999) [pdf] - <AUTHOR> http://worrydream.com/refs/Sussman%20-%20Robust%20Design%20through%20Diversity.pdf <comment><USER2> It reminded me of two unrelated things: Erlang and FFTW.

Erlang due to its error handling philosophy and FFTW due to the following:

 _Question 4.1. How does FFTW work?

The innovation (if it can be so called) in FFTW consists in having a variety of composable solvers, representing different FFT algorithms and implementation strategies, whose combination into a particular plan for a given size can be determined at runtime according to the characteristics of your machine/compiler. This peculiar software architecture allows FFTW to adapt itself to almost any machine.

For more details (albeit somewhat outdated), see the paper "FFTW: An Adaptive Software Architecture for the FFT", by M. Frigo and S. G. Johnson, Proc. ICASSP 3, 1381 (1998), also available at the FFTW web page._ [1]

[1] [http://www.fftw.org/faq/section4.html#howworks](http://www.fftw.org/faq/section4.html#howworks)

Edited for one more comment:

The last paragraph also reminds me of Alan Kay with its focus on the interaction between systems and not their specific logic.

<comment><USER3> FYI: FFTS [1] in many (most?) cases outperforms FFTW, _without_ runtime calibration. It gets there by using a smarter algorithm algorithm. It doesn't have the bells and whistles of more complete libraries—e.g., restricted to power-of-two transforms for now—but hopefully this will change.

[1] [http://anthonix.com/ffts/](http://anthonix.com/ffts/)

<comment><USER4> Is that outperforms on all architectures/"runtimes"?

</comment></comment></comment><comment><USER5> Good paper. This type of research lives on under the banner of safety/security through automatic diversification or diversity. Another phrase used in many papers is "moving target." I called it Security through Diversity in my own work. A quick Google shows most of us were similarly [not] creative. ;)

I used diversity extensively in my previous security work combined with obfuscation and strong, interface protection. Best protection against nation- state attacks on software. Simplest example was running requests a group at a time on three separate systems with different ISA's and toolchains while checking results. Another form of that I derived was having mutually suspicious parties do different implementations of same behavior. The approach I used most was just constantly changing implementation details of key services, from the app to the code serving the interface. Interface attempts to hide all details of implementation plus sanitize the input. Result is indeed a moving target that they rarely hit or expand on.

Modern IT is expected to be much more efficient in terms of labor and productivity. Unreasonably so I'll add. The best way to do diversification now is doing (a) portable software + interfaces, (b) containerizing implementations for easy swapping, and (c) using automated methods being developed in academia to diversify code without human intervention. Two of these can piggy-back on existing work in OSS and cloud tech. Below is a paper studying some approaches to the third:

[http://www.ieee- security.org/TC/SP2014/papers/SoK_c_Automate...](http://www.ieee- security.org/TC/SP2014/papers/SoK_c_AutomatedSoftwareDiversity.pdf)

</comment><comment><USER6> In a discussion I had recently we started talking about metaprogramming, which in practice is only the tiniest and most minimal execution of the implied idea: writing programs that operate on programs. Modern convention is to treat programs as black boxes that only the developers _of that specific program_ can hope to reason about. And so metaprogramming is when a programmer writes or very carefully uses a component that operates on the program, but the result is just the program – you can't run the program without the applied metaprogramming nor can you apply metaprogramming to a program and expect it to work. Except debugging.

Underneath the suggestion in the paper I see something similar. "Programming" might be an overly specific term. But a call to apply reasoning to systems and computation. Not applying reasoning to _specific_ systems, as a programmer might analyze or test a specific program (what we're already doing), but to systems as a whole. I can see this in other computing developments. Operating systems are the result of reasoning about hardware. The result looks very different from coding directly to the hardware, especially in our mature state. But programs still are binaries with machine code. Before the OS of course was the program itself. And so what would it look like if we applied this kind of reasoning to programs?

But oh, we already apply so much reasoning to programming! But in a certain way. We apply reasoning to compilers, which programmers use as they will. We build libraries and hope they are used well. And then we pull these together to some actual purpose in the program. And we assemble programs into systems. Each step empowers the next layer, but we don't apply (much) software to explore, verify, or extend these layers. Our tests are typically written as binary pass/fail systems, with no generalized attention to WHY something fails – and we can't apply generalized attention because the program is too opaque.

<comment><USER5> I agree and have proposed the same thing. I was trying to build on my old toolkit which aimed at RAD w/ C/C++ compatibility, BASIC safety, and LISP flexibility. I essentially implemented a basic-like language that was compatible with C/C++ functions in LISP. Let me have LISP macros and interactive development with result auto-generating C/C++ code that reused their compilers. Worked great while I had it. I know the BASIC angle is funny to many. However, it's how I started & iterated fast with _readable, no blue- screen_ code. I'd have used a Wirth language if I knew of them then.

So, next question was "How to make an environment to allow easier development of high assurance, portable systems?" My platform was a 4GL w/out 4GL's problems. I want a 4GL for highly-secure or reliable software. Noticed portable by itself usually requires a bunch of variations on same basic thing. LISP macro's handled that for me prior. So, my concept was to use something like Racket Scheme for meta while building a mockup of constructs of imperative language (Wirth's, Go, or C). Transformations for specific systems are encoded as meta transforms that operate on base program.

Initially, the thing just generates code it feeds through existing compilers. From there, you model the basic constructs (eg control flow, stacks) in both a generic form and one optimized for certain situations (or ISA's). Language abstractions are modeled as compile-time transforms on these. Constraints, pre/post conditions, invariants, and so on are added as needed for next phase: type/interface checking + automatic production of verification conditions, tests, static/dynamic checks, covert channel analysis, and so on based on annotated code. Each refinement uses data in step before it for correspondence check (eg trace-based). Ends at typed assembly (or LLVM maybe) modeled in same system subject to same correspondence checks and extra analysis at that level. Any run reuses what's already done and not changed while supporting multicore to reduce run time. Critical checks run in background as developer modifies the software.

Written and specified to high level with metaprogramming transforming, analyzing, and optimizing it to lowest levels. Highest, assurance levels using tools such as Coq or HOL would be able to leverage HLL code for easier, spec- to-module/code mapping while trusting certified transforms to do the rest. Your thoughts aside from how much work this might be? ;)

</comment></comment><comment><USER7> > The ARPAnet is one of the few engineered systems in use that is robust in > the way we desire.

What are others?

</comment><comment><USER8> Is designing several independent systems (at least three, for voting to work) more or less expensive than formally verifying a single system?

<comment><USER9> There's an important difference between a formally verified system and redundant systems however. At least, I think so!

A formally verified system is verified "software". Different parts of a redundant system may rely on different parts of the hardware. If some hardware fails, a redundant system can still succeed, while a formally verified system is likely to fail.

<comment><USER8> Given some model of the way circuits work, it's possible to formally verify hardware as well. Maybe your model doesn't quite match reality and your system will still fail. But redundant systems can also experience simultaneous failures of their components. It would be interesting to know which approach is more effective.

</comment></comment></comment><comment><USER10> Sounds like he is describing Erlang and Smalltalk.</comment>


Physicists searching for dark matter using lead from the bottom of the sea - <AUTHOR> https://www.theatlantic.com/science/archive/2019/10/search-dark-matter-depends-ancient-shipwrecks/600718/ <comment><USER2> > its unstable lead-210 isotope would have largely decayed away over the > centuries into stable lead-206

I know very little about radiation or metallurgy. Why are the few centuries the lead was underwater relevant compared to the thousands or millions of years it existed in the ground prior to being mined? Compared to the timescale that the lead exists on, 100 years either way seems like it should be irrelevant.

<comment><USER3> What is special is that it was chemically refined as lead in ancient times.

Lead-210 is in the natural Uranium decay chain: [https://en.wikipedia.org/wiki/Decay_chain#Uranium_series](https://en.wikipedia.org/wiki/Decay_chain#Uranium_series)

The uranium that feeds the chain has a half-life of ~4.5 billion years, so a handful of good 'ol dirt generally has the entire chain's worth of isotopes present. Refining the lead out of ore concentrates almost-pure lead (with all of its isotopes). Lead-210 has a 22-year half-life, so the lead-210 in Roman lead has almost entirely decayed away at the present day.

Being underwater is _also_ special. Cosmic rays strike nuclei on Earth's surface all the time, sometimes transmuting them into other, potentially- radioactive isotopes. They aren't of safety concern, but they are readily observed in low-background physics experiments. "Cosmogenic activation" is a serious problem -- the best facilities these days re-refine copper, from which the experiments are built, deep underground in order to remove cosmogenics. Similarly, detectors are transported by boat in order to prevent the activation that happens via air travel.

Ancient Roman lead avoids _both_ problems. It is old, removing the 210Pb, and has low cosmogenic activation.

<comment><USER4> Also, nuclear bombs. Iron from old (pre-1945) sunken ships is valued for its lack of trace radioactive isotopes in making sensitive detection equipment.

<comment><USER5> [https://en.wikipedia.org/wiki/Low- background_steel?wprov=sfl...](https://en.wikipedia.org/wiki/Low- background_steel?wprov=sfla1)

</comment></comment></comment></comment><comment><USER6> The majorana experiment spent years electroforming copper on site (bottom of a mineshaft) to remove traces of uranium and other contaminants. If it were brought to the surface it would get activated by cosmic rays so all the machining also happens underground. I think they finished growing it this year.

</comment><comment><USER7> This makes me wonder if anyone's stockpiling lead in underground vaults to let it "mature" for scientific use in the coming centuries. Or are there better way potential ways to make low (or non) radioactive shielding that might be viable in the coming decades or centuries?

</comment><comment><USER8> Lay person question: in the same way that we use centrifuges to purify nuclear fuel, could we not similarly use them to refine the stable isotopes from lead (or other metals)? If not, is there an interesting reason?

<comment><AUTHOR> You could in theory: but you would have to turn the metals into a gas first as the process for purifying uranium depends on gas diffusion [1]

[1] [https://en.wikipedia.org/wiki/Gas_centrifuge](https://en.wikipedia.org/wiki/Gas_centrifuge)

</comment></comment><comment><USER9> Could the black matter effects be explained by thinking of light as having mass? (my understanding is that light/electromagnetic radiation is considered as not having mass)

<comment><USER10> Light does have relativistic mass but it is insufficient to account for dark matter.

<comment><USER11> Light does not have relativistic mass, but it does carry energy. The full version of Einstein's famous equation is E^2 = m^2c^4 + p^2c^2; a photon has m=0, so E=pc.

</comment></comment></comment><comment><USER12> that was a cool read.</comment>


GitHub Puts Open Code of Conduct on Pause - <AUTHOR> https://github.com/todogroup/opencodeofconduct/issues/84 <comment><USER2> This is probably a parallel, but I still think Apple came up with the best, most self-disciplining code of conduct of all times:

> _We will reject Apps for any content or behavior that we believe is over the > line. What line, you ask? Well, as a Supreme Court Justice once said, "I'll > know it when I see it". And we think that you will also know it when you > cross it._

Yes, they do publish more direct rejection reasons too. But those reasons were enumerated by experience and were repeated over and over -- like religious hate. What I like is they did not start with a committee of people saying, "Let's brainstorm what could go wrong."

To be able to deal with a large fraternity of people, the better approach is to not imagine a nominal case. You have to start openly, then establish a nominal case with experience.

Mark Stehlik once said, "But, you don't make policies around edge cases; you make policies for the nominal case and deal with the edge cases as the exceptions they are." I like this because this enforces a clear intention of _being able to deal with edge cases._ This is just like Apple's review guidelines. Firstly, they call it _guidelines_ and not _code of conduct._ That enforces that they are human and flexible.

The problem with having a code of conduct with a large fraternity of people is that you immediately give the community an intent of what you like and what you don't like. That discourages you to find things _that you may have liked but now will never get to see._ That also gives idiots in a community a chance to police potential talent based on now written code of conduct. That's a grammar-nazi behavior. You may get great English teachers in that community, but I doubt a Hemingway would want anything to do with you.

Also, it has to be unique to each project. Having a blanket open source code of conduct is bad. It follows what you know, and discourages what you don't. So it's essentially an inbreeding system. And if an open source project accepts and celebrates an inbreeding system, then it is just a proprietary company with no money and wget-able code, essentially failing on both ends.

<comment><USER3> The problem with blank statements such as this is that "the line" is a moving goalpost. I'd (reluctantly) support even completely arbitrary enforcement, as long as it's not retroactive. But if they first accept apps with Confederate flag, and then ban them later, that's IMO a very bad precedent.

<comment><USER4> The set of things that are acceptable, is always in flux. Such is life. Such is the App Store.

You can choose to think about your content carefully before you put it out in the world, or you can choose not to :)

</comment></comment></comment><comment><USER5> That's the smartest thing they've done all week. Now it's time to bury it dead. This is a solution looking for a problem (tm).

The only thing this code of conduct does beside state the obvious (behave like adults) is the implied distrust expressed by introducing it in the first place: that without being nannied into proper behaviour, we would all act like vile animals.

Generally I find such nannying deeply offensive.

<comment><USER6> I agree. I have yet to encounter a truly bad interaction on Github.

And what if I did? Learning to ignore things that could unreasonably sour your mood is a valuable skill in life anyway. Life itself doesn't really have a code like proposed.

<comment><USER7> > And what if I did? Learning to ignore things that could unreasonably sour > your mood is a valuable skill in life anyway. Life itself doesn't really > have a code like proposed.

De-escalated depending on the context of the situation.

Code of Conduct defines problems and could turn anything funny, innocent, etc. into an excuse to ruin someone's life.

9/10 times it's someone who doesn't program (an Adria Richards, Shanley Kane) who will be attacking someone who actually contributes.

<comment><USER4> -1. Implies lines of code is the only possible contribution one can make.

<comment><USER7> Do you expect everyone to water down thoughts with a bullet-point list of qualifiers to have a point?

The people causing the social outrage debacles, often _can 't_ program. They're complete outsiders who think they can use social ideas and useful idiots as a vehicle for _their own benefit_.

Many QAers and PM's can or have programmed some, at one point, or else they wouldn't understand the domain of the problem.

Most of the trouble crowd tend to be social marketers and so-called "evangelists" on twitter.

They're not programmers.

These people leading the vanguard of your code of conduct movements - they're not even really tech. They're happy when you invent these new job positions to give them a paycheck.

<comment><USER4> You seem to be continuing to operate under the assumption that only people who can code, are capable of contributing to a project.

There are so many things that can be done to contribute to a project, that don't involve writing a single line of code. Testing, evangelism, documentation, support, etc, etc.

Why should attempting to improve the culture of a project, be any different?

</comment></comment></comment></comment></comment></comment><comment><USER8> >Physical contact and simulated physical contact (eg, textual descriptions like " _hug_ " or " _backrub_ ") without consent or after a request to stop. [violates the code of conduct]

I can't tell if this is a joke or not.

<comment><USER9> In an employment environment, that is clearcut sexual harassment. The OCC is bringing some of that professionalism to open source communities.

Why would it be a joke to ban annoying personally-targeted behaviors that are unrelated to the work product?

I can't think of a case where discussing cuddling someone is appropriate for a Pull Request, mailing list, or IRC chat

<comment> vezzy-fnord _In an employment environment, that is clearcut sexual harassment._

Wait, really? I've never posted it myself, but textual descriptions like "[hug]" as a way of expressing gratitude or solidarity are common and mundane in plenty of communities.

Now, sure, cluttering technical discussions with stuff like this isn't preferable. To call it "clearcut sexual harassment" is ludicrous and completely devalues the term in question.

<comment><USER10> > Wait, really? I've never posted it myself, but textual descriptions like > "[hug]" as a way of expressing gratitude or solidarity are common and > mundane in plenty of communities.

I'd bet none of the communities you've seen it is a workplace.

<comment><USER11> No, actual workplace interactions that have all the involved humans in the same physical location don't use textual descriptions.

Instead you get the actual actions. Because people who spend that much time interacting tend to not _stay_ in a Platonic Ideal "strictly professional" relationship, but become acquaintances or even friends. In which case it's _that_ set of rules that apply, rather than the ivory tower set of rules based on said Platonic Ideal.

<comment><USER10> So your workplace doesn't use email, source control, instant message, group chat, or any other kind of electronic text communication?

But in a way that just emphasizes why "[hug]" would be awkward and borderline inappropriate in a work setting. How often do coworkers physically hug at work?

I'm not saying it would always be wrong to use "[hug]" (or even physically hug somebody at work), but I'd expect it to be far less common than in some other settings.

<comment><USER12> Nothing wrong with spontaneously hugging at work to relieve stress, assuming that all parties understand the purely Platonic meaning of the act (after all, we're grown-ups).

I also tend to close my (less serious) working emails with stuff like "Love, kisses, [Name]" — and no one ever got offended by that, albeit the majority of my team would probably dislike some random bearded guy actually kissing them.

Awkwardness is in the eye of the beholder. Working with adults (with no serious mental health issues) alleviates the need for a prohibitive, mildly disgusting CoC, like the one discussed in this thread.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I feel like an open code of conduct is unnecessary.

Really - the only thing you need to remember is - be nice to each other and be patient with those supplying advice and those who are asking for advice. (I have screenshots of discussions that violate this simple fundamental rule). I have flagged 40+ comments (that were accepted and acted upon) on stackoverflow alone of people just being stupid jerks.

The SVN people did a great presentation about how to protect your project from poisonous people [1]. Their story goes is that someone came on the SVN mailing list ranting about how SVN sucks and doesn't have the features he wanted - according to the talk the SVN community was polite and the guy just went away.

[1] [https://www.youtube.com/watch?v=Q52kFL8zVoM](https://www.youtube.com/watch?v=Q52kFL8zVoM)

<comment><USER14> It _shouldn 't_ be necessary, but it is.

We live in an age where if an action is not explicitly called out as unacceptable, a significant number of people will perform said action, because if it's not explicitly unacceptable, it's obviously acceptable. In short, if you don't say I can't abuse people, it's ok for me to abuse people.

Oh, and these people will also happily throw around the "First Amendment" as justification, which makes me incredibly sad for the future of our nation.

Solving _that_ behavior though is incredibly difficult.

<comment><USER15> The reason they're unnecessary is that codes of conduct aren't legally enforceable and the resulting actions from violating them can be taken by the community regardless of whether they have a code of conduct. I agree with Bo Burnham when he said, "Who needs a thousand metaphors to realize you shouldn't be a dick?" [1] (or, in this case, a thousand prohibited behaviors)

If someone does act in a way that is unacceptable, the community should, politely, explain to them that that sort of behavior isn't allowed _and_ why it's not allowed, since often times people are communicating in a foreign language or are coming from a culture that has different norms. If the behavior persists, you take whatever action you would have taken had you had a code of conduct.

Basically, there's no practical need for legal-level detail in a code of conduct, just use, "don't be a jerk."

[1] [https://www.youtube.com/watch?v=Zxc20saM8DA](https://www.youtube.com/watch?v=Zxc20saM8DA) (audio NSFW)

</comment></comment></comment><comment><USER16> This section of the "code of conduct" is extremely odd without some context:

> Our open source community prioritizes marginalized people's safety over > privileged people's comfort. We will not act on complaints regarding:

> 'Reverse' -isms, including 'reverse racism,' 'reverse sexism,' and > 'cisphobia'

> Reasonable communication of boundaries, such as "leave me alone," "go away," > or "I'm not discussing this with you"

> Refusal to explain or debate social justice concepts

> Communicating in a 'tone' you don't find congenial

> Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or > assumptions

I'd put this in the context of:

* normal people are political and can not understand a technological meritocracy

* the percentage of the github community that is black is much smaller than the percentage of the worldwide or even US population that is black

* the github community is a technological meritocracy and the problem of underrepresentation is external

* not understanding this, normal people would like to impose a political solution, and the form this solution takes is grotesque and offensive to people who do understand meritocracy

<comment><USER5> You may have missed the memo, but according to new wave feminism, the word "meritocracy" represents discrimination because you _don 't_ give special treatment to people based on sex, ethnicity etc.

I'm not kidding, and Github had adopted this view as well. [1]

Among many, this CoC is seen as a continuation of this largely feminist agenda. And we don't think it belong here. Open source I'd apolitical, meaning you can avoid political issues entirely in a good and neutral environment.

Why work so hard to make it political? For what gains?

[1] [http://readwrite.com/2014/01/24/github-meritocracy- rug](http://readwrite.com/2014/01/24/github-meritocracy-rug)

<comment><USER17> Meritocracy is sexist because it's bullshit. We know it's bullshit from the resumé experiments or the blinded orchestra auditions etc.

<comment><USER5> So your argument is that because it's hard (impossible?) to achieve a true meritocracy the term and goal itself is "bullshit" and should be dismissed?

Should we apply the same standards to other common things? Equality? Democracy? Justice?

See how that works? Yeah, it doesn't. Your argument is a non-argument.

<comment><USER17> No, my argument is that people who claim to be operating a meritocracy need to be aware of a bunch of biases or they risk being sexist[1] whilst also dismissing any accusations of sexism.

[1] etc

</comment></comment></comment></comment></comment><comment><USER18> Looking through some of the issues on that repo, the amount of bad faith people have in the very idea of a code of conduct is astonishing. Not to mention the sheer ignorance of issues affecting minorities within the tech community (seriously, Jon Stewart could have had a weeks worth of material).

Sure, the wording of the code of conduct wasn't perfect, but it'd be much nicer if people wanted to see it improved in good faith. There's a lot of ugly things that happen in open source projects, which aren't rosy as some may assume, and the idea that making more people feel welcomed and safe in communities like GitHub can't take precedent over the possibility that a few current contributors will find themselves outside the rules on a regular basis is very worrying.

<comment><USER19> It seems like the loudest voices are brand new accounts with some sort of anti-diversity agenda.

<comment><USER18> There's what looks like an obviously fake account (lots of 0-star repos with nonsense names) who just started arguing in an issue that privelige doesn't exist and that people are only lazy. That really doesn't help at all, and I'm kinda surprised that it seems as though people are trying to reason with people like that.

</comment></comment></comment><comment><USER20> GitHub ? Looks like TODO group are more companies than just GitHub [1].

[1] [http://todogroup.org/members/](http://todogroup.org/members/)

<comment><USER21> Yeah, I was just gonna ask - what does this have to do with GitHub beyond being hosted there?

But now I guess my question shifts to - what does it mean to be a "member" of this group? Is using any of the services provided by member companies binding me to that CoC somehow?

EDIT: Ah, looks like there's answers in this thread: [https://news.ycombinator.com/item?id=10027561](https://news.ycombinator.com/item?id=10027561)

</comment></comment><comment><USER22> This is a gem: "Harassing photography or recording, including logging online activity for harassment purposes"

</comment><comment><USER23> Github really has jumped the shark.

<comment><USER24> Not yet. They will when they'll impose that silly CoC on all hosted projects.

</comment></comment><comment><USER25> It is terribly worded and quite off-putting. It also has a lot of stuff in it which could be summed up as "be a decent person". Saved space could be used to express specific ideas about desired behavior. Some comments:

 _Offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, neuro(a)typicality, physical appearance, body size, race, age, regional discrimination, political or religious affiliation_

Both too general and too specific. If the goal is to say offensive comments are not permitted then leave it at: "offensive comments". If comments regarding things on the list should be avoided say it. I mean, what about "comments about sexual orientation, mental illnesses etc. of other project members are not permitted". Why is political affiliation on the list I don't really know either. Political affiliation or religion might be completely off- topic for open source projects but putting them in the same list as race/age/body size/physical appearance/gender etc. makes very little sense. Just don't talk about politics or religion if they are unrelated to the project. Don't talk about diet ideas either when we are at that.

 _Unwelcome comments regarding a person's lifestyle choices and practices, including those related to food, health, parenting, drugs, and employment_

"Don't make personal attacks and avoid personal remarks in general".

 _Deliberate misgendering_

Already covered in "comments about gender/sexual orientation/mental ilnesses/etc. of other members".

 _Physical contact and simulated physical contact (eg, textual descriptions like "hug" or "backrub") without consent or after a request to stop_

It really doesn't seem to be necessary and makes the whole thing sound not very serious.

 _Threats of violence, both physical and psychological Incitement of violence towards any individual, including encouraging a person to commit suicide or to engage in self-harm Deliberate intimidation_

Yeah but make it shorter: "Threats of violence, intimidation or encouraging them".

 _Deliberate "outing" of any aspect of a person's identity without their consent except as necessary to protect others from intentional abuse_

Actual problem and specific behavior hidden among 20 or so points which could be shortened to 3. More points like that please.

 _Publication of non-harassing private communication_

Another good point: specific behavior which isn't universally understood as undesired and should be specifically included in CoC.

 _'Reverse' -isms, including 'reverse racism,' 'reverse sexism,' and 'cisphobia'_

Reverse sexism is sexism. Remove all "reverse" non-sense. The whole text reads like mumbling on Tumblr.

 _Refusal to explain or debate social justice concepts_

Yeah, refusal to explain or debate recent fruit diet should be included as well.

 _Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or assumptions_

All this is covered in point about sexism and discrimination. Cissexist or cisgender aren't actual words in a dictionary and should be avoided in an international CoC.

 _If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong._

This is nonsense. Someone being harmed is a serious issue. Someone being offended - not so much. Mixing the two takes away from serious issues and dilute them in ocean of meaningless words without any specific behaviors attached to them.

 _Although this list cannot be exhaustive, we explicitly honor diversity in age, gender, gender identity or expression, culture, ethnicity, language, national origin, political beliefs, profession, race, religion, sexual orientation, socioeconomic status, and technical ability._

Blablablabla, 3rd time in the same text. Just remove the whole section. It doesn't contribute anything.

 _If you experience or witness unacceptable behavior—or have any other concerns—please report it by contacting us via firstname.lastname@example.com. All reports will be handled with discretion. In your report please include:_

"If you experience unacceptable behavior or have any questions, contact us at email@example.com. All reports will be handled with discretion." The rest of the paragraph is pointless.

Overall it's a terribly written text which is thin on specifics and repeats itself several times. Maybe ask an actual technical writer to put things together. Make it shorter as well.

</comment><comment><USER26> The reason so many people are against "Code of Conducts" is because they are not used as a baseline for professional behavior (against which there would also be arguments in Open Source), but as a political cudgel to score points and enact things like: [https://blog.mozilla.org/blog/2014/04/05/faq-on-ceo- resignat...](https://blog.mozilla.org/blog/2014/04/05/faq-on-ceo-resignation/)

See also: [http://dancerscode.com/blog/why-the-open-code-of-conduct- isn...](http://dancerscode.com/blog/why-the-open-code-of-conduct-isnt-for-me/)

But look at some instances for people who have tried to win political arguments by invoking CoC or are lobbying to instate them on Open Source projects.

Here is a case, someone from Italy was openly against reassignment surgery for kids on Twitter: [https://twitter.com/krainboltgreene/status/61156951531550720...](https://twitter.com/krainboltgreene/status/611569515315507200)

Uh-oh my wrong-think senses are tingling, he had a different opinion on a social issue on his private Twitter account. How could this possibly be handled? Ignore him, discuss this issue with him or agree to disagree? No, clearly he must be somehow punished for this. Luckily he is apparently contributor to an Open Source project called Opal, so let's bring it up there and insist: [https://github.com/opal/opal/issues/941](https://github.com/opal/opal/issues/941)

This is fortunately brought up by someone who has already developed their own "Code of Conduct" that would require that it be followed on "public spaces" (like Twitter, Facebook or forums) and if not be removed from the project: [http://contributor-covenant.org/](http://contributor-covenant.org/) [http://where.coraline.codes/coraline_ehmke.pdf](http://where.coraline.codes/coraline_ehmke.pdf)

" _By adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.

This code of conduct applies both within project spaces and in public spaces when an individual is representing the project or its community._"

It's basically a shakedown game for ideological control of a space and seems to work this way:

1) Someone gets offended by something someone in the Open Source community said (usually on Twitter or at an official event), they demand they be removed or otherwise punished for the offending thing.

2) They flood GitHub or similar with demands to remove said individual and/or at least adopt a "Code of Conduct" to prevent such "despicable" behavior like disagreeing in the future, which includes all Social media and official events

3) Once project creators have been socially shamed as some sort of bigots for not wanting to do anything against this sufficiently and the activists got a foot in the door they push a self-formulated "Code of Conduct" on the project like above

4) Then they demand it be upheld and anyone that says anything they deem offensive be removed from the project, if it happens another time they can point to said "Code of Conduct" and ask the project creators to abide. A "safe space" has been created. After this they don't particularly give a shit if great software engineers get pushed out for disagreeing or the project even fails beyond this point, because said people don't want to abide by their ideology.

Meritocracy is also generally a trigger-word for these people, they absolutely hate it. Just bring it up in conversation and they reveal themselves and their intentions rather quickly: [http://readwrite.com/2014/01/24/github- meritocracy-rug](http://readwrite.com/2014/01/24/github-meritocracy-rug)

[https://modelviewculture.com/pieces/the-dehumanizing-myth- of...](https://modelviewculture.com/pieces/the-dehumanizing-myth-of-the- meritocracy)

Another recent issue was GitHub removing a WebM Converter repo because it used the word "retards", you can see the same individual involved in the first Twitter conflict pop up throughout the comments yelling at other people to leave: [https://github.com/nixxquality/WebMConverter/commit/c1ac0baa...](https://github.com/nixxquality/WebMConverter/commit/c1ac0baac06fa7175677a4a1bf65860a84708d67)

</comment><comment><USER27> For those confused, here is the actual code of conduct [1]

[1] [http://todogroup.org/opencodeofconduct/](http://todogroup.org/opencodeofconduct/)

</comment><comment><USER24> > to protect people who are typically the target of harassment in open source

So if you are subjected to an unusual type of harassment, you're on your own?

<comment><USER3> I guess the idea is, to prevent (or at least discourage) the usual types of harassment up-front, and deal with the more unusual, rare forms on-the-fly as they appear.

<comment><USER25> Yet, there is specific point about "reverse-sexism" and "reverse -ism" not being considered a problem. The concerns are valid, the text is written with an agenda in mind and the agenda makes people weary.

</comment></comment></comment><comment><USER3> I fail to see how this has anything to do with GitHub, except using GitHub as a hosting platform. Can somebody please change the title?

<comment><USER28> Github recently adopted this Code of Conduct for all of their own-brand projects, and they were encouraging other open source projects to adopt it as well: [https://github.com/blog/2039-adopting-the-open-code-of- condu...](https://github.com/blog/2039-adopting-the-open-code-of-conduct)

<comment><USER3> But the question is, are they also supporting/adopting this change/suspension? That's not clear from the linked post.

<comment><USER29> At least the GitHub's Atom and Electron projects are evaluating alternatives. See: [https://github.com/atom/atom/issues/8206#issuecomment-128858...](https://github.com/atom/atom/issues/8206#issuecomment-128858335)

</comment></comment></comment></comment><comment><USER7> I group "Code of Conduct" with Political Correctness.

For anyone interested in a good read on the subject, check out _End of Discussion: How the Left 's Outrage Industry Shuts Down Debate, Manipulates Voters, and Makes America Less Free (and Fun)_ by Mary Ham and Guy Benson.

It's an excellent read, and shouldn't be too much of a sting to the social outrage panderers out there.</comment>