In Sam's case, it sounds like all of his social discomfort is happening entirely within free speech principles?
From what I can gather, Sam sometimes freely-speaks an idea that other people find harmful. Others then freely-speak back to him that he should stop, because it's harmful.
But it sounds like Sam's arguing not just for the right to free speech, but the right to have everyone listen to you. That right is limited by others' rights to live peacefully, and not be regularly subjected to words that harm them.
I think we're in a weird situation where nobody is really worried about Sam's ability to remain free, but at the same time nobody is all that interested in listening to the weaker voices that might actually end up silenced. In fact, that's almost a given: if a million people are going to read your blog post then, no, social mechanisms aren't going to shut you up.
What's in the back of my mind is an unremarkable person who has an opinion that their boss doesn't agree with. We never read their blog posts, because by definition I'm talking about when the power dynamic is backwards.
> But it sounds like Sam's arguing not just for the right to free speech, but the right to have everyone listen to you.
EXACTLY. It's amazing to me how many people take it upon themselves to conflate Right To A Platform and Right To Speak Unrebutted with the Right To Free Speech
Sam's argument seems to be that one of our major social problems is that we socially disallow controversial ideas, which makes him feel uncomfortable expressing himself and stifles social progress. Therefore, we should start allowing controversial ideas.
The parent comment asserts that Sam's premise is wrong: ideas aren't being rejected for their controversy, but rather for their harmfulness. Saying that "it’s possible we have to allow people to say disparaging things about gay people" (see his previous post) implicitly draws a false equivalence between civil rights advocacy and bigotry as fair-game "controversial" ideas.
They're demonstrating Guacamole's ability to handle simple animations smoothly. Music visualizers are a solid, familiar example, despite not being a super-common use case for remote desktop.
It's important to distinguish between what the memo's author says, and what effect his words actually have. It is an anti-diversity memo, even if it isn't intended as one.
The author makes shaky statements about gender, reinforcing sexist stereotypes. The author applies rationalist disclaimers, which enables already-sexist readers to feel that their sexism is rational. And, most distressingly, the author asserts that Google made a mistake hiring many of the women who work there. Actively making your minority coworkers feel unwelcome is an anti-diversity behavior, and it was an obvious and predictable consequence of how he chose to communicate.
I don't claim to know the author's intent, or how he truly feels about the women he works with. But, regardless of whether he's actually opposed to diversity, we judge words by their consequences. These words are thoroughly anti-diversity in consequence, and judging them in a vacuum is dangerously naive.
What so many comments about this memo don't seem to understand is that it it isn't possible to derive the author's intent from the text of their work. The intent of the author isn't included when the reader interprets their work, because the author isn't there[1] to explain their intent. The reader only sees the work.
As you said, intent doesn't matter. When authoring a work, it's important to consider how the work might be interpreted.
You're assuming that each piece of text has only a single possible interpretation when "research and critical thinking" are applied to its interpretation.
This is so far from the truth I'm not really sure what to say.
Beyond the current topic, your opinion becomes so obviously false I really don't know what to even say. As a base-line example, let's take any pair of 5-4 SCOTUS opinions on a constitutional matter. I suppose it's possible that half of the supreme court justices (and often slightly different halves) are routinely incapable of critical thinking of research to the text of laws and of the consitution. But that seems like an exceptionally arrogant explanation.
Believing "only my reading of the text is possible if you're remotely capable of research and critical thinking" is, for an author, an extraordinarily enormous mistake.
No, it can't. This is a fundamental limit of language, because language itself - which you're using to accomplish your research - requires using imperfect symbols.
If you don't mind 100% spoilers for Davey Wreden's game "The Beginner's Guide", I highly recommend watching "The Artist is Absent"[1]. It's a surprisingly good introduction to semiotics, death of the author, and enunciation theory, which together explain why you can interpret the narrator of a work, which should never be confused with the author.
Is believing men and women on average have different hormone levels and generally speaking, this leads to different behaviors and proclivities, sexist?
Is admitting there is any difference between the two sexes, sexist?
Is using different pronouns for men and women sexist?
I honestly don't know where someone draws the line who finds this memo "sexist."
I haven't decided yet whether I think the memo is sexist. But I'm confident that, because of how it's written, sexist people who read it will feel validated in their sexism.
It uses the same core argument as sexism: women are less suited to certain tasks, perhaps biologically. And it reaches the same conclusion: we should roll back our pro-diversity and pro-empathy programs. A sexist person who reads this will therefore feel that it supports their views, and, because the argument seems rationalist, they'll conclude that their poor treatment of women is rationalist. That might not be the intent of the document, but it is a predictable outcome.
Words that validate sexist behavior, intentionally or unintentionally, contribute to the problem. Regardless of the merit of the underlying idea, or the valuable conversations it inspired, it's important to remember that the memo itself did harm. It's appropriate that some people are focusing on that.
This idea of avoiding saying something because of how horrible people might choose to interpret it is something I find, frankly, terrifying. This is going beyond just censorship and going into the realm of trying to censor reality.
Where do you draw the line on something like this? Are we allowed to publish statistics that show black people are proportionally more involved in crimes, or is this taboo because a white supremacist might use it to claim blacks are inherently criminal? What if you write something apparently neutral but some terrible person somehow finds a way to twist it to their ends? Do we get to condemn you ex-post-facto over this?
I'm not saying don't have these conversations. Rather, have them carefully, and choose your words with the consequences in mind. There are many good and thoughtful ways to talk about potential issues with Google's gender diversity programs, but instead this memo made some especially bad choices.
For one thing, the memo focuses on needlessly contentious issues, instead of sticking to actionable arguments. It's valid to say that decreasing stress in engineering and leadership positions might attract more women, because modern women tend that value that more. But framing it as a biological issue is hard to prove, and doesn't help support his logistical point. It only has the consequence of hurting people.
The memo also presumes that Google's full-time diversity experts haven't even thought of his concerns. He asserts that seeking out women necessarily lowers the hiring bar for them, instead of asking "How are we mitigating the risk that our pro-diversity push might itself introduce bias into our ideally gender-agnostic perf evaluations?" That's a valid question, and I'm sure Google's diversity team has answers, and I'm sure that some people wouldn't be satisfied with those answers. But jumping to the conclusion that Google's women must be less qualified than the men, just because he can't think of a way to mitigate bias in the hiring pipeline, is self-centered and disrespectful.
I'm very much in favor of a world where it's equally okay to express all ideas! But that doesn't mean we should be equally okay with all modes of expression. No matter which side we're on, we need to think first, then speak. Given the meta-thesis of the memo (especially the "prioritize intent" section), I'm not convinced that the author took much time to consider needs beyond his own.
> It's valid to say that decreasing stress in engineering and leadership positions might attract more women, because modern women tend that value that more. But framing it as a biological issue is hard to prove, and doesn't help support his logistical point. It only has the consequence of hurting people.
What it sounds like you're saying is that saying women are on average more sensitive to stress based on extensive scientific research which implies a strong biological basis, is contentious and hurtful. But then for some reason saying modern women tend to put more value on a stress-free environment, based on nothing but an unsupported assertion, is somehow better?
I don't have a crystal ball, but I suspect you're being naive and that the outrage would have been much the same no matter how he'd chosen to frame this statement. The very assertion that men and women have some innate differences that might be worth exploring seems to be tantamount to blasphemy -- particularly when coming from a man!
> The memo also presumes that Google's full-time diversity experts haven't even thought of his concerns. He asserts that seeking out women necessarily lowers the hiring bar for them, instead of asking "How are we mitigating the risk that our pro-diversity push might itself introduce bias into our ideally gender-agnostic perf evaluations?" That's a valid question, and I'm sure Google's diversity team has answers, and I'm sure that some people wouldn't be satisfied with those answers. But jumping to the conclusion that Google's women must be less qualified than the men, just because he can't think of a way to mitigate bias in the hiring pipeline, is self-centered and disrespectful.
This is just you projecting your presumed intentions on the author. At no point in the memo did he claim or imply that Google's women are less qualified than the men. The only paragraph that can really be taken to say that is the part about "lowering the bar" for diversity candidates; Which is, admittedly, an unfortunate choice of words in retrospect. However the same sentence clarifies that the bar is "lowered" by decreasing the false-negative rate for diversity candidates, meaning those that are accepted are still qualified at the same standards. The sentence also includes a reference for this claim, but this is unfortunately to an internal Google group so we don't know its contents.
On the other hand, right at the start of the document the author takes pains (including a big colorful picture to illustrate the point) to point out that "you can’t say anything about an individual given these population level distributions," which should make it pretty clear that he's NOT claiming Google's female engineers are less qualified.
> I'm very much in favor of a world where it's equally okay to express all ideas! But that doesn't mean we should be equally okay with all modes of expression. No matter which side we're on, we need to think first, then speak. Given the meta-thesis of the memo (especially the "prioritize intent" section), I'm not convinced that the author took much time to consider needs beyond his own.
This is saying that one must choose his words like a politician and consider the reaction of the world at large when distributing a personal opinion document not intended for wide publication to a select group of individuals. The idea that one's career might hinge on using the proper newspeak in such a document is, frankly, terrifying to me. Do people have a right to be upset about his choice of wording or angry at his opinions? Sure, absolutely! But losing your career for this, over an opinion that is, arguably, not really harmful or hateful and expressed in a relatively considerate tone, is something else entirely.
Mm, thanks for calling out the false-negative thing! I think I misparsed that the first time around and got confused between decreasing false negatives and increasing false positives. That's embarrassing, sorry ^_^`
In any case, I think I made a mistake suggesting specific improvements to the memo; lemme pop off the stack a bit:
It's not okay to publish a document to your coworkers that will predictably make them feel unsafe. Full stop.
When you want to express an idea at work, you need to engage in empathy, and try to express yourself in such a way that your coworkers will still feel safe with you. If you can't figure out how to express an idea without hurting your coworkers, then, yeah, you don't get to express it unless you figure something out :/ That's an appropriate workplace policy, and I'm comfortable with the general idea that freedom of expression is subject to some conditions. I know not everybody agrees with that prioritization, though!
More importantly, I'm just tired of articles like this one dismissing the social consequences lens outright. There's more than one valid issue being raised in our community right now, and the importance of one doesn't invalidate the others. Let's have both conversations: how to enable expression of less common ideas, and how to ensure that we express them empathetically. If we approach the problem thoughtfully, I think we can optimize for both :)
(BTW I edited this comment a lot during the first 30 minutes, and pretty significantly changed its contents. Sorry if that ends up being an issue!)
I actually tend to mostly agree with you on this. I think the safest and most rational policy is just to avoid discussing sensitive topics at work so as not to risk creating a hostile atmosphere, and I don't consider this an unreasonable restriction on freedom of expression. Talk politics and immigration with your friends and family, not your teammates at the office.
My problem is that Google as a company, at least as far as the Mountain View campus goes, apparently disagrees. My understanding -- and it's possible I'm wrong -- is that Google supports and encourages openly discussing a variety of topics at work, and the internal tool he used to publish his memo was designed and used exactly for this purpose. (What Googlers apparently describe as "an internal-only Reddit.") If this is true then he was fired not for discussing inappropriate topics, but for holding opinions the hive-mind finds disagreeable.
Either you as a company support discussing sensitive topics in the office, or you don't. If you don't that should be made clear and enforced equally for everyone. If you do then you can't pick and choose which opinions you approve of based on what's popular, and expressing a dissenting opinion should not, at the very least, be a fireable offense!
People of the different races are definitely different. Otherwise, why do people evolve to so different races? The white people may be better fit for higher latitudes, while the black people may tolerate more heat and sunshine.
In mentality, there may also be differences due to tens of thousands of years of different ways of gather food, even though those differences may be converged by education.
Denying existing differences is not leading to equality. Admit the reality and see if there's anything we can do to improve the situation.
Yeah, that's a good point! It's important to consider the truth of the underlying idea, as well as the consequences of how it was expressed—though I don't like that the blog post seems to give up on the latter problem just because it's less objective. Discussions about social values and social consequences are worth having, despite not being subject to pure rationalism.
Still, while both lenses are valid, I'm focusing on the consequences lens, because we're discussing an Atlantic article that tries to invalidate it. It's not misleading to call the memo "anti-diversity", if you're focusing on the memo's role as a social artifact rather than as a dissertation, and that's a valid perspective. Words often serve both roles, and it's important to consider both.
(Incidentally, I don't find the memo's argument to be especially sound, either, so it's not just that it was expressed carelessly—but that's sorta beyond the scope of this thread.)
>>It's not misleading to call the memo "anti-diversity"
if I had to summarize the memo with an "anti-..." prefix then I would say it's against artificially skewing the gender makeup of the workforce via preferential treatment of female applicants/employees over the discriminated male applicants/employees.
if that's what "diversity" means then I don't know on what logical basis you would be defending the "let's make sure we have a 50/50 gender makeup of the workforce even though the proportion in the applicant's pool is nowhere near that" position.
I myself (and from what I've read in that "manifesto" I believe this is author's position as well) welcome diversity - the 'IT sausage fest' is totally a downside - but not at the expense of ppl getting gender-discriminated.
(Though, actually, it's only a response in spirit; Bakaus's article was posted about a week earlier than Miessler's.)
I think the problem with the AMP cache model is that, because you need to link directly to the cached URL, you commit to exactly one cache provider. If Bing were to also implement their own validated AMP cache for Bing search results, you can't have one link point to both; you're either AMPed in Google results or in Bing results, and, by being marginally bigger, Google wins all of the pie. That's no good.
How might we change the AMP standard, or the trust model around AMP caches, to get the same performance wins while still enabling competition?
When I'm just sitting around saying "am I happy yet?", I never am. It just reinforces the depression by reminding me of the challenges. Happiness, in my experience, is the sort of thing that I can't usually produce on demand.
But I can set yourself up for success. I ask myself what tends to make me happy, and then I make the hard decision to legitimately engage with it: I challenge myself to be swept up in the moment, even though it really seems like I won't be.
For example, I generally find happiness by making progress on the things I'm invested in. But, even though I am invested in being happy, I can't just dive into coding and expect it to work, because coding isn't actually what makes me happy: coding helps me accomplish things I care about, and that makes me happy.
So, first, I find a self-contained goal, like "I'm gonna work on this really cool project because it's really cool", or "I'm going to make progress in this video game because it challenges me to think in new ways". Fulfilling this goal for its own sake, because I'm legitimately invested in it, is what makes me happy. In order to succeed at happiness, I carefully choose a different target, and focus on it instead.
That's what's been working for me recently, anyway.
The file size problem is about unused code, right? If we tree-shook the runtime and shipped the minimal version that our app needs, wouldn't that be even better for most apps than inlining the framework? I'd expect that, the moment you use a feature even twice, the runtime approach yields a smaller bundle.
Or is Svelte accepting a file size penalty to avoid the performance overhead of function calls? If so, it'd be nice to see that tradeoff discussed more explicitly: in every app, there are probably features worth inlining and features worth keeping as function calls.
Really, it sounds like Svelte is trying to solve a very general compilers problem with a very specific sledgehammer solution. Sure, tree-shaking and thoughtful inlining are difficult to do well, especially in Javascript, so this makes sense as a first draft for certain use cases. I just wish it were touted as a first draft, rather than a new beautiful finished paradigm.
> If we tree-shook the runtime and shipped the minimal version that our app needs
I've heard this sentiment a lot. The reality is that UI libraries are inherently difficult to tree-shake. You can't run a library that can be used to produce an infinite range of outcomes and expect a tool like Rollup to whittle it down to just the bits you need (source: I'm the creator of Rollup).
Code is reused. While the compiler will output 'standalone' modules by default, it can also generate modules that share code between components — the zero-runtime part is about generating abstraction-free DOM manipulation code rather than having a complex virtual DOM reconciliation or data-binding process.
> rather than a new beautiful finished paradigm
Nowhere does it claim to be finished. If anything, it's the start of a new approach to building UIs.
Oh! I think I'm fundamentally misunderstanding the pitch here. Here's my new guess: Svelte analyzes my component tree to discover the graph of data dependencies… and then throws out the component tree entirely, instead outputting code that directly implements my data flow graph.
Is that correct? If so, it's a very cool idea! (I'd been tossing this idea around for a few months last year, but had trouble designing a non-awful API xP)
I wish there were a way to make the messaging around this idea clearer. I know that audiences are different, and this wouldn't work for everyone. But if the introductory blog post had illustrated the transformation from component tree to data graph, I would've immediately understood the performance implications and how this represents a huge paradigm shift in application compilation.
Instead, though, I thought the pitch was "ew, separate runtime library? let's inline it and then it'll be smaller", which seemed misguided. I had to reverse-engineer Svelte's motivation from your comment—and even now I'm still not sure I got it right. (Maybe this entire comment is wrong? Could be wrong. No idea :/)
Are y'all planning a blog post about how Svelte works under the hood? That would go a long way toward clarifying the pitch, I think.
Sort of, yeah. The previous wave of declarative UI libraries essentially followed one of two models — there's the 're-render the entire app then apply a diffing algorithm' approach (React and its many imitators), and there's the data-binding approach (Knockout, Rivets, Ractive and later Vue) whereby different nodes in your model/state/data graph (whatever you want to call it) are linked to the DOM, usually via various levels of indirection.
Both are solid ideas. (As the creator of Ractive I'm biased towards data-binding, but React's success speaks for itself.) But either way, the library has to do a lot of work to essentially just translate state changes into `element.setAttribute('foo', 'whatever')` and so on. Svelte was born out of a realisation that if you can understand the shape of your component graph at build time, you can eliminate those runtime abstractions — and with it, both the bytes and the computational cost associated with them.
> Are y'all planning a blog post about how Svelte works under the hood?
Yes, we have a lot of blog posts we need to write! Hopefully soon.
Please correct me if I'm off base here, but isn't a big part of the whole virtual-dom abstraction performance?
Direct DOM updates are slow (rerender), diffing and smart patching much faster. There must be a reason for virtual doms becoming so popular, even for frameworks that don't have a 'functional' approach like React.
Great question! It's a very common misconception that an app that uses virtual DOM diffing somehow manages to be faster than an app that manipulates the DOM directly.
Re-rendering your entire app (i.e. creating all the nodes from scratch with innerHTML or document.createElement) is too slow for a lot of apps, and is a bad idea for lots of other reasons (losing state in form elements, etc). Virtual DOM just gives you a way to write your app as though you were re-rendering it from scratch, while still being fast enough that you can get away with it.
Svelte is significantly faster than React according to https://github.com/krausest/js-framework-benchmark, because it's taking a more direct approach to the same goal — updating existing elements or only creating/destroying them as necessary. It's also faster than Ember, Angular, Vue, etc. It's not yet quite as fast as Inferno, but it uses less memory.
Virtual DOMs are used to make the rerender-everything-all-the-time approach acceptably fast, which is desirable since that approach tends to lead to nice UI code with few state related bugs. Still, this is a pretty costly way to update the UI, as the virtual DOM causes a lot of memory churn.
Agreed with Rich, it's a misconception that virtual-dom is faster, web browsers have made significant improvement to DOM. There must be a reason why vanilla Javascript is fastest than most virtual-dom.
Inferno-1.1.0 have an error at runtime, could not test JS Framework right now. Sveltejs works.
Hmm, okay. I'm starting to poke at the TodoMVC's compiled code in the debugger, and it's not quite the super-duper-aggressive graph conversion that I was imagining—but it's interesting to look at :)
The tricky part is rendering the correct number of equals signs. Markdown.css fakes it by rendering a constant large number of equals signs, then setting the width so that only some are visible.
It seems to work by printing lots of `=` beneath, and then hiding the overflow. Inspecting and changing the title's width reveals more `=` and makes it possible to display half of one.
Some immutable data structures implementations perform optimizations under the hood.
For example, if you have a large game state object with mostly stable fields, but the position value changes frequently, you don't need to perform a full copy of the object when position changes. Instead, you could create a new object that only keeps track of the position field, and delegates all requests for other fields to a more stable underlying game state object.
You could also imagine an environment that, if you're going to throw away the reference to the old game state anyway, then it's safe to mutate the object directly instead of bothering with copies or proxies.
…that said, most implementations—especially if you're not careful—will probably incur performance costs, and, at 60 FPS, those matter. They're just not necessarily as bad as you're imagining :)
Yeah, media queries and pseudo selectors (such as :hover) are supported. These tend to be really important for critical CSS. Descendent combinators are possible but to a greater degree involve tradeoffs. I posted my thoughts on this on this issue: https://github.com/rtsao/styletron/issues/27#issuecomment-26...
In Sam's case, it sounds like all of his social discomfort is happening entirely within free speech principles?
From what I can gather, Sam sometimes freely-speaks an idea that other people find harmful. Others then freely-speak back to him that he should stop, because it's harmful.
But it sounds like Sam's arguing not just for the right to free speech, but the right to have everyone listen to you. That right is limited by others' rights to live peacefully, and not be regularly subjected to words that harm them.