David Owens:

Swift has it’s warts. It’s a baby that’s trying to grow up quickly in a world that is harsh. The question I’ve been asking myself, both through these posts and throughout the weeks is really this: are Swift’s warts and ugly places worse than those of Objective C’s? Will they be tomorrow?

For the last week I’ve worked bit by bit on rewriting my first iOS app in Swift. Several years ago I wrote this app for my wife because she could not find a grade scale app on the App Store that was easy to use or not ugly. A few weeks later I installed this app on her phone, and she’s been using it ever since.

When I first created the app it was for iOS 5. As the years have gone on I did a few things to keep it up to date, particularly for iOS 7, but I never moved to Auto Layout. With the launch of the iPhones 6 and 6 Plus, I decided it was time, and I figured I’d use Swift. Why not, right?

It’s been a good exercise for me, and I’m learning to really like the language. I am more comfortable in Swift with my little bit of knowledge than I ever was in Objective-C, which I know far better. I enjoy it, but it’s not perfect. That’s why I appreciated this post from David Owens so much. It’s not perfect, but it’s what we’ve got.

The 'This American Life' podcast might be the best showcase of storytelling on the internet, and it's definitely the best of public radio. I love their work and recommend the show to anyone interested in telling or consuming stories.

A few weeks ago, they upped their game. They launched a new podcast, 'Serial.' From the summary of the first episode:

It's Baltimore, 1999. Hae Min Lee, a popular high-school senior, disappears after school one day. Six weeks later detectives arrest her classmate and ex-boyfriend, Adnan Syed, for her murder. He says he's innocent - though he can't exactly remember what he was doing on that January afternoon. But someone can. A classmate at Woodlawn High School says she knows where Adnan was. The trouble is, she’s nowhere to be found.

The first three episodes have been released, and they are great. Truly great. Please subscribe, both for your benefit and in hopes that this projects success will lead to more efforts like it.

I work in a company that has been paperless for two decades. At home we have a ton of devices, more than one for every use case. I had a Palm Pilot in college. I haven’t sent a letter in the mail in over a decade. All of my to-dos and calendars are digital. And yet, I can’t escape the analog world of pen and paper.

Of course, the truth is that I don’t want to escape it. I love pens and paper. I love the feel of writing with a good pen. I love the physicality of a notebook. I carry a Field Notes book with me everywhere, every day.

I’m completely stuck in between analog and digital. If I take notes digitally they are easy to find, and easy to copy and send to others. If I take them with pen and paper I remember them more easily, and I am prompted to act every time I open my current notebook.

I don’t have a good solution to this problem. I don’t know how to get the best of both worlds. And yes, I’ve googled this many, many times. I’ve spent hours of blogs of the similarly afflicted. I’ve found solutions that come close, particularly archiving notebooks via photo in Evernote, but none of them have been practical for me.

So today I will go to work with my good pens and my notebook. I will sit down in my first meeting with my laptop open, and paper and pen beside it. I will continue living in between these worlds, because I don’t have another option.

Update: Jeff Atwood and company have updated the name to ‘CommonMark’ in consultation with John Gruber. My thoughts below the original post.

Today Jeff Atwood (I’m a fan) and a working group announced a new fork of Markdown (which I am writing in, on a keyboard Atwood designed), a text markup language created by John Gruber (also a fan, a big fan)¹. They created a new spec, intended to remove the ambiguity of Gruber’s original spec, and a standard set of test suites. They call it “Standard Markdown.”

They created this new project without Gruber’s involvement, and it looks like without his blessing—both of which are just fine in the open source world. I haven’t read the new spec in detail yet, and I think the standard tests are a great idea. This project was clearly conceived with a clear purpose because of a felt need. I think this is a good idea in many ways.

But the name is terrible. “Standard Markdown” is absolutely the wrong name for this project. And this isn’t nit-picking either, the name is so bad it casts a pall over the whole project.

First, reusing the name Markdown is a poor choice. I understand that we are all tired of “X flavored Markdown” as naming approach, but using the name Markdown on a fork of the syntax clearly marks this effort as trying to take the place of the original spec. It’s unnecessarily aggressive.

But beyond using that familiar moniker for the project, the team went a step further and claimed the mantle of “Standard.” This decision cannot be interpreted in any way other than an attempt to wrest ownership of the thing called Markdown from the guy who invented it. It’s an overly bold move, full of hubris.

I’m an open source proponent, but just not a Stallmanist². I affirm this team’s right to take the Markdown language and syntax and make it better. I affirm the right of others to take that and use it instead of Markdown. That would be a good thing, in fact that is how technology advances. So don’t misread me, I’m in favor of this project existing.

But don’t call it Markdown, and certainly don’t call it “Standard Markdown.” Claiming something new to be a “Standard” version of an existing open source project is poor form. Gruber created the Markdown syntax and its first parser, he claimed a copyright, and released it to the world. It is open source. It has been built on, modified and extended well beyond its original incarnation. That’s all well and good. In a real sense, Gruber has a form of ownership over both the Markdown default implementation and syntax, open source though it is.

The chosen name for this project seems to reveal the intentions of the team behind it: take over the intangible ownership of a successful idea, and it’s brand, without the permission or help of the creator. Building on top of Gruber’s work is a good thing, it’s a great example of the open source ethos. But trying to claim a “standard” that is divorced from the original spec is not.

The fix is simple. Keep the new spec. Keep the test suite. Keep all the good work that moves Markdown forward. But change the name. It’s not the “standard” Markdown, and calling it that is dishonest.

Updated

On the second try, the project formerly known as “Standard Markdown” was renamed to “CommonMark.” First the renamed it to Common Markdown, and that names holds many of the same issues as the first.

Ultimately, this is the right outcome. There was lots of back and forth on Twitter between Atwood and Gruber, and of course their respective teams, and it looks like the name contention was eventually resolved in private.

In the end, this is the right solution. Given the people and platforms involved, there was no chance this would be resolved completely behind the scenes, but this result is good for all involved. Certainly CommonMark is not the best name ever, and some time spent thinking about alternative could result in something better, but it works. I’m glad the team decided to change the name, and I’m glad the web has a strict Markdown implementation. In fact, I’ll be investigating the test suite myself.

An automated world is closer than most of us realize.

This is the not Jetson’s future I was promised, but that’s okay. There is a problem though, as the video points out, in the economics.

When I talk about automation leading to efficiencies, I often frame it terms of freeing resources to do more interesting work. I still think that’s true, but this video offers a great rebuttal. There will be people doing more interesting and innovative work than before, but not enough to head off potentially disastrous levels of unemployment.

I really appreciate the summary though, because the automated future is not necessarily bad, but it will be if we are not prepared. As someone who is pursuing automation right now, I must admit we need to spend more time thinking about how to better handle the challenges that will result.