Voting for Donald Trump was a racist act. Assuming the Trump voter was well-informed, it’s a simple case analysis:
- Either they directly supported his racist rhetoric. It follows that their support for him was a racist act.
- Or they decided that Trump’s racist rhetoric didn’t matter. That decision is also a racist act as it validates his rhetoric as acceptable.
John Scalzi lays out the argument in more detail in his excellent piece, “The Cinemax Theory of Racism”.
I’ve raised this point with several of my Trump-supporting family members. The response has been, “I supported Ben Carson in the caucuses1, so I can’t be racist.”
Without re-litigating Carson’s fitness for the Presidency, I want to point out three flaws in this rationalization.
First, racist is both a noun and an adjective. I have no qualms about applying the noun to the President-elect. He has a long history of acting on his racial prejudices. However, here I’m applying the adjective. Nearly all of us harbor prejudices against others. It’s a natural consequence of growing up in our society. Failing to recognize and counteract our own implicit biases leads us to engage in aversive racism. Pearson, et al write:
Aversive racists, in contrast, sympathize with victims of past injustice, support principles of racial equality, and genuinely regard themselves as non-prejudiced, but at the same time possess conflicting, often non-conscious, negative feelings and beliefs about Blacks that are rooted in basic psychological processes that promote racial bias … The negative feelings that aversive racists have toward Blacks typically do not reflect open antipathy, but rather consist of more avoidant reactions of discomfort, anxiety, or fear. That is, they find Blacks ‘aversive’, while at the same time find any suggestion that they might be prejudiced ‘aversive’ as well.
We need to recognize our capacity for aversive racism and actively counteract it.
Second, using support for Carson to argue that support for Trump wasn’t racist is a straightforward application of the one black friend argument.
The underlying fallacy is that one single point of data, this one “friend,” completely overrides any other bits of evidence we have to assess someone’s views. This is simply not valid reasoning.
Prejudiced views exhibit as a priori judgments against a group. Having come to support Carson after learning about his history and beliefs has nothing to say about whether or not ones initial perceptions reflected a racist bias. Having a racist bias may make it harder to come to support Carson, but having come to support him does not imply the absence of racist bias. (Neither does it imply presence of racist bias. Having a racist bias and supporting Carson are simply unrelated.)
Overcoming a racist bias to support Carson puts us at risk of the third flaw in the Carson rationalization, Carson as magical Negro. Jamil Smith, writing in the New Republic, calls this out far better than I could:
Carson fits the bill because his is a blackness of poor circumstances and personal responsibility, minus the racial grievances. He doesn’t complain about the structural inequality that his drive and skills enabled him to escape, at least financially. … Given his political performance and his career legacy, he’s an ideal conservative magical Negro for the Fox News era: A man … who performs the conservative ideal of racial progress, denigrating himself while remaining content to enable continued injustices.
Supporting Ben Carson does not relieve one of responsibility for supporting Trump. Support for Trump was a racist act. That does not make all of his supporters racist. It does mean that their behavior was racist. That’s a vital difference. We all make mistakes. The important part is to recognize our mistakes, own them, and do better.
Post-script: Enlightened readers will certainly find things I’ve gotten wrong here. Writing on race, especially from my position of privilege, is probably ill-advised, but I write to understand and sharpen my own thinking. If I’ve screwed up, I ask for your forgiveness, and hope you’ll help educate me.
1 All of my immediate family apart from my wife and me are still in Iowa.
I’ve been a tech enthusiast and Apple customer for over 30 years. I don’t recall ever being as disappointed by a set of Apple product announcements as I was this week.
The TV app for Apple TV on your TV. Meh. Maybe this will actually deliver on the promise. Maybe it won’t. The lack of a partnership with Netflix doesn’t bode well. Ultimately, this is a product for someone else. I don’t watch television apart from following the Cubs and Sounders.
Tweet along with the NFL. Who green lighted this shit show? Watching the slowest games in sports and listening to the morons who call them now is painful enough. Adding a scrolling feed of tweets from randos isn’t going to elevate the experience.
The Touch Bar. Apple clearly thinks they’re on to something here. It is impressive tech. And the fact that it’s running something like watchOS on an independent processor means they’re in a good position to add it to external keyboards. I doubt the market would bear the price those would have to command, but it could happen.
The real issue is that the Touch Bar is impressive tech looking for a problem. Gruber writes:
The Touch Bar is the answer to “These keyboard F-keys are cryptic and inflexible — what can we replace them with that’s better?” That’s an actual problem.
That is not an actual problem. Actual problems are user problems. What job does the Touch Bar do? None of the demos of the Touch Bar were compelling to me. Everything the Touch Bar does can be done on-screen with trackpad input or on a tablet with pen input. “But now you don’t have to take your hands off the keyboard!” Instead I have to take my eyes off the screen. That’s a win? No. It’s a gimmick.
The one actual problem the Touch Bar might address is discoverability. By showing controls that are appropriate for the user’s current task, devs might help their users find more of the power their software provides. I see two counterpoints here. There’s nothing stopping developers from doing that now without the extra hardware, and there’s a very good chance that the extra real estate will be used to overwhelm rather than edify. Just think what the team that designed Microsoft Office’s ribbons UI could do with yet another row of buttons.
That brings me to the heart of why the event was so disappointing. Apple is targetting casual users and sacrificing support for power users. The Mac Pro (*cough*) is 1045 days old. It’s been 382 days since iMacs have seen even a speed bump. Even so, the new MacBook Pro is underpowered compared to this old tech. Still, Apple pitches the MacBook Pro and an LG monitor (not shipping until December at the earliest) as their desktop solution now.
I’m sure that combination will satisfy many users. In fact, I’m sure it will satisfy a majority of users. But like the folks with large music libraries left behind by iTunes and Apple Music, those of us who do work that is CPU constrained are being left behind as Apple focuses on the mainstream.
The iPhone-ification of the Mac is accelerating.
Despite being disappointed with the options available, I need to upgrade my development environment at home.
Omni provides a generous hardware budget, so we can stay up-to-date with the lastest tech. That helps us build support for Apple’s newest OS features. I’ve been limping along on a mid-2013 MacBook Air, but with a 5-year anniversary hardware bonus in hand it’s time to shop.
I have two main use cases for my development set up:
- I want a portable machine for Tuesday nights at NSCoders and weekend mornings in the coffee shop. In this environment, I’m generally working on side projects to research APIs, experiment with new approaches, or prepare talks. I can get by with less power. Portability is key since I often walk or bus.
- Conversely, I want as much power as possible for compiling Omni projects at home. Omni’s code base is large and framework rich. When working on bugs or features that require changes to our frameworks Xcode really likes to do full re-compilation of the entire app. On my maxed 2015 MacBook Pro at the office, a clean build of OmniFocus for Mac takes somewhere between 8 and 12 minutes. On my current Air at home I can easily get in a 3 mile run before the build finishes.
Apart from those use cases, my old eyes seem to want a bigger font size every year. I’d really like to get a big, wide-color retina display.
I’d been holding off on making any changes until Apple updated the product line. I figured there were two likely outcomes this fall:
- Apple would rev the iMac. In this scenario, I’d get a fully loaded 5k iMac for doing Omni work at home. I’d also pick up a MacBook Adorable for coffee shop coding.
- Apple would ship a significant upgrade to the 13″ MacBook Pro along with a 5k display. In this scenario, I’d use the new MacBook Pro for both coffee shop and home.
Apple chose to let the iMac stagnate. I really don’t want to drop four grand on an iMac with year-old specs.
Apple focused the improvements to the MacBook Pro on size, weight, and the Touch Bar gimmick, leaving performance largely unchanged, and far below a maxed iMac.
Despite that, I think I need to split the difference on my use cases for now. I’ll get a 13″ MacBook Pro plus $100+ worth of cables and dongles to keep my existing USB and Firewire (!) accessories working. Then I’ll wait and see if LG ships Apple’s new 5k monitor in December as promised. Or maybe I’ll decide that the MacBook Pro isn’t up to the task for my home use case. Then it’ll be back to waiting to see if Apple actually cares about Mac performance.
One thing I do know, I’ve never been less happy about ordering new kit. This is the most first-world of first-world problems, of course. On the other hand, a craftsperson relies on their tools. It’s frustrating to only have dull blades to choose from.
This week I re-wrote one class three times while battling buggy first-party API. I’d estimated the feature I was working on at 8 hours. I spent 4 days. Half of one of those days was simply trying to get test hardware working again.
I’m taking a much needed vacation day today, but I smelled a new personal record, so did a little work this morning.
What’s the record? Seven radars against a single API end point:
- rdar:///28066560 — CLKTextProvider should have a mechanism for generating formatted, localizable string pairs
- rdar:///28137645 — Can put entire Watch into reboot loop via complication’s text provider
- rdar:///28138051 — Localized text providers don’t work for actual complications
- rdar:///28138313 — CLKTextProvider.localizableTextProvider(withStringsFileFormatKey:, textProviders:) API doesn’t work
- rdar:///28138447 — Documentation for localized text providers should mention limitations
- rdar:///28138655 — Watch simulator produces empty complications gallery
- rdar:///28138766 — Watch simulator produces complications gallery for wrong app
And the documentation for all of this — the first link under Resources here — disappeared yesterday. It’s a 404 now.
Let’s Build a Reactive Programming Library
Functional reactive programming is a much promoted technique for building apps structured around data flow, asynchronous events, and value types.
There are several popular frameworks for reactive programming in the Apple ecosystem, including Reactive Cocoa, RxSwift, and Bond. These powerful tools can be intimidating when first trying to learn the concepts.
In this talk I’ll implement a simple reactive programming library “from scratch”, live coding the interesting bits, and using them in a small demonstration app. The talk is intended for people new to reactive programming and should help demystify the concepts so you can approach one of the more powerful frameworks with confidence.