Coyote Cartography

So I’ve been seeing arguments for why, no, you should really stay on Twitter, because of the problems with anything vying to replace it. Most circle around what tech people might dub failure modes in terms of both engineering and policy.

Make no mistake, many of these are solid arguments. Twitter has, as much as we like to pretend otherwise, gotten many things right. They’ve got fast onboarding. They provide a good experience on both mobile and desktop. (Please don’t @ me with your objections to ads and algorithms and whatever; I’m not saying the UX design on Twitter is perfect or free of dark patterns, I’m saying that it’s been developed by UX professionals over a 15-year period and it shows.) They understand the importance of making a service like theirs accessible. They understand the importance of well-designed terms of service that limit their legal liability without taking draconian stances toward users and their content. These are all failure modes that other, newer, smaller services have done little or nothing to address.

But for many people, the real issue isn’t what’s wrong with the other places. It’s that they love this place. Twitter, for all its faults, for all the love/hate relationship you have with it—it’s your favorite bar. This is what most indie creators are feeling, I think. None of the other services have the audience reach; it’s unrealistic to expect us to be on a half-dozen new sites when we could just stay put; and, hey, the likelihood of Twitter really exploding is pretty low. All of those are true, too.

The problem, though, is that just because Twitter’s failure mode isn’t likely to be “closing up shop” doesn’t mean it doesn’t have other failure modes. You might have noticed I didn’t mention harassment and toxic behavior as a failure mode—the things a Trust and Safety Team handles—but it is. As Nilay Patel observed, the product of a social network is content moderation.

To be clear, this is something all the Not-Twitters are going to have to come to grips with in ways they haven’t yet. Cohost, Hive, and OoobyBloobly (which I just made up, or did I, you’re not sure, are you) look good by comparison because they are a fraction of a fraction of Twitter’s scale. Your favorite Mastodon instance this week is even smaller. With Twitter’s two hundred million users, trying to regulate bad behavior is a 24/7 rearguard action.

Well, guess what? Twitter’s Trust and Safety Team is now gone. By deliberate design. It’s not coming back, at least not in any recognizable form, not any time soon.

You think I’m going to mention Musk restoring Trump’s Twitter account. I am. But the canary in the coal mine isn’t the who as much as it’s the how. Musk claimed in October that he’d set up a new “council” for moderation, and that “no major content decisions or account reinstatements will happen before the council convenes.” That was a blatant lie. He polled his followers—hardly a statistically unbiased group—about restoring Trump’s account, and has restored others just on his own. Tech journalist Casey Newton:

At the risk of stating the obvious, this sort of ad hoc approach to content moderation and community standards is completely unsustainable. It does not scale beyond a handful of the most prominent accounts on the service. And, most worryingly, it is not based on any clear principles: Musk is leading trust and safety at Twitter the same way he is leading product and hiring—by whim.

And this is Twitter’s failure mode. All those tweets you’ve seen bitching about how a big problem with Mastodon is that you might choose an “instance” that ends up being run by an anti-woke edgelord tinpot dictator? That’s Twitter now.

Oh, you say the need for advertisers will help rein in Musk’s worst impulses, because no sensible advertiser wants to have their “promoted tweets” running in line with alt-right propaganda? Good luck with that: a Twitter that’s only ten or fifteen percent of its original size requires a lot less money to run, and Musk’s been clear he aims to reduce the company’s dependency on advertising income.

And those remaining thousand employees or so aren’t going to push back the way we saw happen in some tech companies a year or two ago. The shakeout isn’t just in progress, it’s almost over. The ones left either can’t afford to leave or subscribe to Musk’s worldview. Anyone who joins Twitter under his leadership will have done so knowing what that worldview is.

The “liberal bias of big tech” has always been a phantasm. Silicon Valley has always had a strong libertarian bent to it, from the right-of-center Hoover think tank at Stanford University to the military/aerospace roots that long predate the 1990s dotcom boom. While many SV libertarians are socially liberal, not all are, and a few of the most prominent conservatives came out of the “PayPal Mafia”: Musk, the openly anti-democratic Peter Thiel, and VC David Sacks, who co-wrote a book called The Diversity Myth with Thiel a couple of decades ago. Along with professional idiot Jason Calacanis, Sacks now advises Musk on how to run Twitter, and the circumstantial evidence suggests they’ve encouraged the performative cruelty Musk’s exhibited in how he’s run things so far.

So here’s the thing. What conservative culture warriors always say they want is the absence of political bias, but time and time again what they mean is bias that explicitly favors them. Everything else, you see, has an innate liberal bias—it’s them against the world, fighting the good fight. They want fairness and balance the way Fox News does. They don’t want an unbiased social media site; what they want is a site with Gab and Parler’s slant, but Twitter’s reach. Now they have it. The product of a social network is content moderation, and Twitter’s new content moderators will be hand-picked by Musk. It’s going to be full of people who won’t object to racism, homophobia, and transphobia as much as object to fighting it, because “free speech”.

If you do believe in the Fox News kind of balance, that I’m wrong about Silicon Valley’s political biases and especially wrong about Twitter’s, this isn’t a failure mode. It’s what you want, or at least what you think you want. It’s clearly what Elon Musk thinks he wants. But for Twitter as we knew it, this is a catastrophic failure. It’s a terminal condition, an unrecoverable crash.

New Twitter will be hostile to anyone queer, or non-white, or slightly to the left of Ronald Reagan. You may be a creator who wants to stay on Twitter to reach your audience, but the audience there will inevitably tilt toward the anti-woke, All Lives Matter, gender critical, Just Asking Questions crowd. If they’re your audience, congratulations, I guess. If they’re not, you have a problem.

I get that, right now, it’s still easy to rationalize staying on Twitter. The alternatives are too confusing, or have questionable terms of service, or don’t have a registered DMCA agent, or have a crappy official app, or have a crappy web interface, or just seem like they’re run out of a college dorm room. We can go down the list and acknowledge most or all of those are great points.

But your favorite bar is under new management, and whether you want to admit it or not, you know damn well what kind of bar they’re making it into. You need to think long and hard about whether you’re okay with that.

When TextMate burst onto the scene in the mid-2000s, it didn’t take aim at Emacs and Vim as much as BBEdit, a Mac-only editor around more than a decade at that point. TextMate offered radically easy ways to create sophisticated new language modules and plugins compared to most editors of the day. Mostly, though, TextMate had Ruby on Rails: David Heinemeier Hansson developed the framework with early versions of the editor, making it almost custom-built for Rails. That gave TextMate a boost working with other server-side frameworks.

Since then, cross-platform editors and IDEs like Microsoft’s Visual Studio Code and JetBrains IDEs have come to dominate the coding world. This is an issue for those of us who want Mac-assed Mac apps. I hung onto TextMate and then the native-but-weird Sublime Text, shifting to Code somewhat reluctantly. Last year, I pounced onto Panic’s new Nova, reviewing it positively shortly after release.

BBEdit is obviously a Mac-assed Mac app, and for reasons I’ll return to, I came back to it years ago for technical writing—but not for coding. (It sometimes seems like BBEdit’s biggest fans are writers.) Some more code-focused users, though, haven’t looked at it in years. With the release of version 14, should they reconsider?

Musty, or battle-tested?

Few editors have been around longer than BBEdit—and few have been as rock-solid. I don’t think I’ve ever lost work. It can even “rescue” never-saved documents you mistakenly close without saving!

Yet, that venerable age has become a double-edged sword. “Looks old” is a dismissal I’ve heard a lot. I’ll be honest: to me, it looks like…a text editor.

It’s information dense, but neither overly busy nor packed with unnecessary bits. (Nearly everything shown here can be turned off, too.) One thing you don’t see? Tabs. Instead, there’s an open documents list in the sidebar. If you end up with a dozen or more files open at once, this approach starts really showing its advantage.

Leaping forward

Here’s something cool:

This editor understands PHP well enough to know that after you type $handler->, it should offer methods from the Handler class as autocomplete options, because it knows $handler is an instance of that class.

This level of introspection used to be the exclusive domain of IDEs, but a couple of years ago, Microsoft introduced the Language Server Protocol for Code, so plugins could offer this functionality. Nova supports LSP natively, and with version 14, so does BBEdit. In addition to smart autocompletion, BBEdit uses language servers for:

• Function parameter help
• Real-time code linting
• Navigating to function definitions and symbol declarations
• Reformatting documents

See the green dot in that screenshot? It’s a dropdown for showing errors and warnings in a file. Individual lines also get their line numbers highlighted and the issues shown by underlines. (The snippet above shows $response with a red underline in two occurrences: the first because that line isn’t complete and so has a syntax error on it; the second because, thanks to the first error, $response isn’t defined yet.)

BBEdit is preconfigured to use many language servers, like Intelephense, out of the box once they’re installed. This can be considerably more complicated in other editors, especially if their LSP support is itself provided by an extension.

A couple of caveats: first, a lot of language servers apparently haven’t been tested with anything but Code, and can get quirky with any other editor. Sometimes BBEdit can work around quirks, but not always. Second, BBEdit doesn’t support all LSP features. For instance, documentation won’t pop up when you hover your pointer over a function or symbol.¹

Other new features

BBEdit 14 now has a “Notebook.” This takes the already-existing “scratchpad” feature (itself unique to BBEdit) a step farther, storing multiple notes as individual sheets within an always-available Notebook window. By default, BBEdit creates notes as Markdown files, but you can change them to other languages. As with any text file, you can create new notes from the clipboard or from selected text, by dragging text, or even from the shell by piping text to bbedit --note.

I haven’t played with the Notebook much yet. It strikes me as the kind of feature you’re either going to rarely use or use all the time, and it’s not clear to me where I’ll fall. I use scratchpads a lot, though, and have a weakness for note-taking apps. I could imagine putting together a package that offered some basic to-do list functionality that might effectively replace TaskPaper, too. It’s not Emacs’s legendary Org mode, but then again, it doesn’t make you learn Emacs.

Beyond that, BBEdit now supports Emmet for HTML and CSS expansion if you install the Node Emmet module; if you make from-scratch HTML pages a lot, this is a big deal. If you’re a Python programmer, BBEdit is now aware of Anaconda/Conda virtual environments out of the box, and lets you switch between them with its shell menu.

Other old features

When I became a full-time technical writer in 2014, I tried a few different editors and settled on BBEdit, even though its Markdown syntax highlighting is…spartan. Why? Because BBEdit is a Swiss Army knife, a Leatherman multi-tool, for text processing. In no particular order, here’s some interesting things BBEdit does that I rarely see in other editors.

• What it lacks in Markdown highlighting, it makes up for in Markdown previewing. You can set custom HTML templates, CSS files, and even processing scripts. (You can do this for HTML files, too, and I suspect for other kinds of plain text markup languages.)
• Many editors have a “fuzzy file open” feature, but BBEdit can open multiple matching files simultaneously. I use this way more often than you might think.
• BBEdit keeps a history of find/replace searches, and lets you save complex grep patterns with names for easy recall. And you have to see its “Multi-File Find” feature to fully appreciate how great it is.
• You can build a “text factory” of multiple actions; it’s like having a simple version of Shortcuts or Automator built right into the editor. You can save them as text filters or use them for batch processing. I have a simple-minded Markdown to BBCode conversion “script” I created this way without writing a line of actual shell script.
• You can “process” lines in a file, searching for duplicates or lines that match specific patterns (including regular expressions), and delete those lines, copy them to the clipboard, or create a new document with them.
• BBEdit can operate on “columns” of tab-separated values, cutting, copying, pasting, and even rearranging them.
• While Git support is mostly (ahem) bare bones, it’s fantastic with file-specific commands like diffs and revision history.
• The “Pattern Playground” is outstanding for constructing complicated regular expressions that work with your documents.
• BBEdit uses Kapeli’s Dash documentation browser if it’s installed.

The Unix Worksheet in BBEdit deserves its own paragraph. Send any line in the worksheet to your shell by tapping Control-Enter, and the output from the shell appears under that line in the worksheet. You can’t run interactive shell programs this way, but for most commands you now have an editable, modifiable history. In my technical writing, I create lots of local branches; I usually use a worksheet to clean them up by running git branch to get a list of them, then adding git branch -d before each one I no longer need. The worksheet is inspired by the long-defunct MPW, but Emacs fans might consider it a cousin of shell mode.

Lastly, another feature of BBEdit worth checking out: the 400-page user manual. Yes, that is what a technical writer would say, but it’s a remarkable boon.

A few missing features

BBEdit has a more “batteries included” approach than most editors, and so needs fewer third-party extensions. But, the integrated managers in Code and Nova make a strong argument for a centralized package index. Sublime Text’s Package Control started as a third-party system, so it’d be possible for someone else to take up the mantle here. The closest BBEdit has is BBEdit Extras, and while it has some good stuff, it’s also got a lot of outdated (and frustratingly undated!) stuff and an awful lot of link rot.

Sublime Text popularized multiple cursors in text editors. BBEdit’s processing commands can do nearly anything these can—honest—but if you’re a multi-cursor junkie, it’ll be an adjustment.

Codeless language modules only set colors for strings, comments, keywords and “predefined names,” along with delineating functions for navigation and folding. CLMs also can’t be used for templating systems like Jinja or EEx that exist as “embedded languages” in HTML. You can write a more powerful language definition in Objective-C—I presume including templating languages, since “PHP in HTML” and “Ruby in HTML” are standard—but that’s a hella big ask.

Back to the future

I’ve long believed that BBEdit’s balance of text processing power with discoverability and ease of use makes it the best tool for “documentation as code”-style technical writing on the market. But at least for me, it hadn’t kept up with the state of the art for coding. With BBEdit 14, this no longer feels true.

So, I’m moving back. I’ve created a new color scheme, SpaceBones, inspired by the default color scheme of Spacemacs. I’ve been working on an up-to-date package for Elixir that comes with an LSP, as well as creating a new set of clippings for PHP 8. My old Editor Actions package may get a reboot. Hopefully, there will be ways to publicize these; I’d love to see a BBEdit-focused project similar to Vim Awesome.²

If you’re already a BBEdit user, version 14 is an essential update. If you’re not—whether you used it years ago but drifted away, or never used it at all—it’s time to give it another look.

BBEdit 14 is $49 new from Bare Bones Software, with upgrade discounts for owners of earlier versions, or from the Mac App Store with a $39/yr annual subscription. You can use BBEdit for free with a more limited feature set. Disclosure: I beta-tested BBEdit 14, and received a free upgrade serial code.

TL;DR: I’m not using it much.

I’m sure my review of Nova made it clear that I wanted to like this editor a lot. In practice, though, it’s felt more like its predecessor Coda and a similar competitor of Coda’s era, Espresso, than like Visual Studio Code or BBEdit: targeted chiefly at web developers mucking about with static websites. (Which, to be fair, is a sizable audience; my website is static, and Nova’s pretty good with it.)

Nova’s built-in smart autocompletion hasn’t proved particularly smart when I’ve been using it, which in some ways makes it more frustrating than not having it at all. Backing it with a language server theoretically improves it, but Nova’s LSP support is fragile and weird. I don’t mind it being somewhat incomplete, but it’s entirely dependent on third parties writing extensions that talk to language servers—which would be fine if they worked. But at least in the languages I use, they don’t. For PHP, there are two wrappers for Intelephense; one just flat out doesn’t start, and the other one makes Nova crash on startup. For Elixir, the elixir-ls extension works in the sense of, you know, not crashing, but mostly what it seems to do is hover huge documentation pages over the screen if the mouse pointer rests over an Elixir keyword. (I have heard Nova’s TypeScript extension is solid, but I haven’t tried it.)

Beyond that, when it comes to the basics of just editing, Nova is…fine? It does the job. But—like Coda and Espresso—it doesn’t have the selection and manipulation chops of higher-power editors. I still have no idea what commands like “Select All in Any Scope” are supposed to do because they’ve never worked. Nova’s clips are useful, but limited compared to the equivalents in BBEdit or Code (or any editor, like Code, that basically adapted TextMate’s snippets).

So, am I going to renew for the $49 annual subscription? I haven’t entirely ruled it out, but, well, it’s not looking good. I’ve been spending much more time back with BBEdit recently…but that’s another article.

At the end of 2010, John Gruber of Daring Fireball wrote in a Macworld column,

The central conceit of the iPad is that it’s a portable computer that does less—and because it does less, what it does do, it does better, more simply, and more elegantly. Apple can only begin phasing out the Mac if and when iOS expands to allow us to do everything we can do on the Mac. It’s the heaviness of the Mac that allows iOS to remain light.

Back then he wrote that long-term (“say, ten years out”), iOS might replace macOS. But in 2020, Apple recommitted to the Mac: the Mac Pro, the return of good keyboards, and—the biggest move yet—a new CPU architecture designed in-house.

Since then, I’ve seen a chorus of pundits, both professional and armchair (hi), push two theories that are either at odds or entwined, depending on how you look at them:

• Surely, a dystopian iOS-like future of only sanctioned App Store purchases lies ahead for the Mac. (Let’s call this the “Hacker News bait” narrative.)
• Surely, the iPad is going to catch up or even surpass the Mac—it already does so many things so well, and it’s only held back from its potential by an OS with artificial limitations.

The Hacker News bait narrative is bullshit. But I’m not sure about that second, sunnier one, either. Apple has been demonstrating a consistent philosophy for over a decade:

• Macs are general purpose computers.
• iPads and iPhones are application consoles, analogous to game consoles.

These have been true from the beginning of each platform. Macs have always been general purpose computers, and iPhones and iPads have never been such.

There’s no intrinsic reason iOS devices had to be consoles; other smartphones like Windows Mobile and PalmOS phones weren’t. We all know that, but we forget that there’s also no intrinsic reason Macs had to be open. Not only was its direct antecedent the Xerox Star considerably more console-like, so was Jef Raskin’s original concept for the Macintosh, which evolved into the Canon Cat. Yes, if the Mac had been positioned as an appliance the way the Star and the Cat were, it would likely have joined them in obscurity—but we say that now with nearly four decades more “common wisdom” about computers. The Cat wasn’t the only early attempt at an application console; the 1990s saw the Sony eVilla and other “Internet appliances.” Those products didn’t fail because the concept was bad; they failed because the technology to support the concept just wasn’t there yet. A decade later, we had small, lightweight touch screens and widespread high-speed wireless data—and internet appliances became possible.

As long as this philosophy on Apple’s part holds—and there’s no evidence that it’s changing—macOS will never be locked down to the degree iOS is, i.e., unable to install non-App Store apps without jailbreaking. But the Venn diagram of “users likely to walk over such a drastic change to the Mac” and “users likely to spend boggling amounts of money on Apple hardware” is close to a perfect circle. Apple would have to not only make up the lost hardware revenue in App Store revenue but beat it. You need 30% of a hell of a lot of apps to make up for a single lost 16-inch MacBook Pro sale, let alone a Mac Pro. Even if it was just four or five percent of users—and I think that’s extremely optimistic—that’s millions of lost unit sales, and likely forgoing entire markets the Mac currently has a meaningful presence in. There’s just no business case for such a move. Beyond that, given all the radical changes Apple made to the Mac in 2020, it feels like that was the “now or never” moment. If M1 Macs and macOS Big Sur didn’t lock us into an App Store-only world, it’s pretty unlikely macOS Pismo Beach or whatever is going to.

But that brings us to the second point. Is this the year when the iPad does get to do everything, not just most things, the Mac does? Will we be able to run macOS apps on M1 iPad Pros the way we can run iOS apps on M1 Macs?

I do think Final Cut and Logic will come to the iPad eventually in some form. But so far, macOS has remained a general purpose OS, and iOS has remained a console OS—and I don’t think that’s changing soon. I just don’t. I’m doubtful that Apple has any interest in getting an Xcode-like iPadOS development going, and doubtful they plan to “open up” iOS any more than they must for technical, market, or regulatory reasons.

Yet on an infinite timescale, this dichotomy can’t hold. It may be a minority of people who truly can’t do their work on the iPad, as opposed to just kvetching that they can’t do it the same way as they do on a Mac or a PC. But that minority is there, and they matter.¹ So the question is what happens to break it and when. I’m expecting iPadOS 15 to have some major UI changes, possibly even the first tiling window manager designed for humans. My pie-in-the-sky guess is that a new operating system replacing both macOS and iPadOS is already underway. Its foundations are Swift and SwiftUI, and macOS Big Sur and iPadOS 15 are early bits of scaffolding. The Mac gets lighter; iOS gets heavier. But they’re not meeting in the middle yet.