How Markdown’s Typographic Choice Reflects John Gruber Perfectly

I love writing in Markdown.1 For a long time it has bugged me that a single ‘*’ surrounding text was the syntax for italics rather than for bolded text. I thought that this was a minor mistake by Gruber and I wondered if he ever regretted it.

I was further convinced about my feelings when I became aware that Microsoft Word allows users to create bold text by surrounding text with ‘*’s, and especially when I started using Slack a while ago and their very simple Markdown-like also creates bold text with single ‘*’s.

But finally, recently, something dawned on me. As I’ve been inconsistently blogging for the last couple of years, I’ve been watching my own habits and tics. I notice that I always want to emphasize words typographically to communicate the strength of my feeling. As with overusing adjectives and adverbs, I recognize this as laziness in my writing, and I often (try to) pull back, because it’s noisy and distracting to the reader.

John Gruber is a thoughtful, conservative2 writer and is famously restrained in his design choices. So what I finally realized is that, consciously or not, he designated the simplest syntax for his preferred form of typographic emphasis. And obviously , he would generally prefer the subtle emphasis to the “hey dummy I’m trying to get your attention” emphasis. Given this line of reasoning though, I wouldn’t have been shocked if he had not even supported combining the two forms, which allows for the “apparently my words aren’t good enough to make the strength of my feelings apparent to the reader” emphasis! This line of thinking is also perfectly consistent with Microsoft and Slack making bold emphasis the default for a single ‘*’.3

This realization, whether true of false, has changed my feelings about the ‘*’s entirely. I am glad he made it the way that it is, and I am quite doubtful that he has ever considered it a mistake.

I’ve heard and read multiple accounts from him discussing Markdown, but I’ve never heard him discuss this prioritization. If I’ve missed it somewhere, I’d gladly update this post to reflect that.


  1. I like it so much I even made a contribution to simpler syntax for tables though if you want to use this, I highly recommend Brett Terpstra’s reimplementation ↩︎
  2. In the best way sense of the word, writing out of strengths, not speculation ↩︎
  3. #NoOffense ↩︎
Advertisements

Here’s The Thing About Occam’s Razor

I saw two abuses of Occam’s razor recently, though I don’t have the links, so I am just going to rage-post this.

Occam’s razor

Plurality is not to be posited without necessity

Misuses of Occam’s razor

  1. “This explanation is simplest, so by Occcam’s razor, it’s the best.”

    Occam’s razor DOES NOT SAY THAT THE SIMPLER EXPLANATION IS ALWAYS BETTER. It says that the simpler explanation that also explains all the observations is preferred.

  2. “This explanation is simpler and fits all the observations, so Occam’s razor proves it is correct.”

    Occam’s razor does not ever prove any argument. It suggests that we should “prefer” the simpler explanation. But since we cannot every know all the facts, then we cannot be certain we are overlooking a complicating factor.

That is all.

Autolayout Constraints in Emoji — Maximum Readability

Programmatically creating Autolayout constraints is famously dense to read, although the strongly-typed visual format makes some easier to parse visually.

With that in mind, which is easier to read?

This:

let subView1 = UIView()
let subView2 = UIView
let constraint = NSLayoutConstraint(item: subView1, attribute: .left, relatedBy: NSLayoutRelation.equal, toItem: subView2, attribute: .right, multiplier: 1.0, constant: -10)
constraint.priority = 900.0
view.addConstraint(constraint)

Or this:1

view.📌(subView1 ⬇️=⬆️ subView2 + 10 ‼️ 900.0)

Read More »

The Minimal Swift for Reading `stdin`

I needed to do some simple text file manipulation the other day and since it the command line was the obvious place for this, I started to use it as an excuse to learn bash, but then I quit that. I decided to fall back to Swift. I had to go back to a previous script I had written at one point that used Swift for stdin manipulation.

So, here in all its glory, is a very simple method for reading stdin into a single string.

#!/usr/bin/swift
import Foundation
var string = ""
while let thing = readLine(strippingNewline: false) {
    string  = thing
}

In order to run it without prior compilation:

xcrun swift readStdin.swift < textfile

To compile it, and then run the executable:

swiftc readStdin.swift -o readStdin
./readStdin < textfile

Personal Unit Testing Road Blocks

Ok, gonna make this quick, or else I’ll never publish it.

I just listened to a great episode of Fatal Error podcast on testing.1 Chris is clearly a consistent unit test writer and did a great job laying out the whys of testing and some basic approaches. Soroush did a great job as the less consistent test writer and laid out some great reasons why testing would be helpful. Together I appreciated a few of their strategies for getting started.

I know that Chris in particular felt like the episode was a mess, but honestly, it was really, really good. More to come will be welcome, but this episode struck a great balance of nitty gritty without getting bogged down by nailing down every. single. term. and. concept. which in the testing conversation is a serious risk.

That was just throat clearing. The point of my post is to describe how I get bogged down in trying to add tests to my current codebase:

  1. Our codebase is a mix of Objective-C and Swift.
  2. I fixed a bug today. The fix involved UINotificationCenter. So there were a few places that I was just not going to even try to test, i.e. “did the class get the notification?”, “Did the class call the right method when it got the notification?”… But the class called a protocol method that behaved differently depending on whether I passed an object or if I passed nil. That seemed testable.
  3. So, then I started to think about writing a test. And I started down this mental path:
    1. I need to create an object that conforms to the protocol.
    2. The method in question does not actually return a value, it just calls a method on our analytics singelton if the object is present.
    3. So, I guess that I could rewrite this method in the class that conforms to the protocol, so that it calls a returning method that indicates whether it should call the analytics method. OK.
    4. Then, we are writing all of our Unit tests in swift, no problem, creating an object that conforms to an protocol is no problem, right? No, I don’t think so. But how do I know if the other method is called? Well, I’ll figure that out in a minute.
    5. Oh, and I’ll need to figure out how to call a private Obj-C method from swift. If the test were objective-C, I would just write an inline (testable) category in the Unit Test File, but how to do this in Swift? 2
    6. AAAaannddd… I’m done. This method is simple and obvious enough… No need to test it…

Some of these things are definitely only problems because I don’t write tests often enough. I’m sure they would strike many as trivial problems that are just a part of writing inter-operating Swift and things that are just learned with practice. I agree. It’s just as raw (and vaguely embarrassing) a description of my mental process as I can write.


  1. Soroush Khanlou & Chris Dzombak host it, and it is great! ↩︎
  2. now that I’m writing this blog post out this way, I remember that I can add that category to to an Objective-C header file, which I can add to the Bridging-Header.h file in my Testing workspace. ↩︎

iOS-ification of Mac Hardware

For a long time there was concern that Mac OS X was going to get iOS-ified

But it seems a lot more like the tea leaves are indicating instead that the hardware has been iOS-ified right underneath our noses:

  1. No official Mac monitor.
  2. No new Mac mini in many years.
  3. No new Mac pro in years.
  4. In other words, all mac hardware designed in the last 3 years is a form of screen cpu in a single housing.
  5. No Keyboard with touch bar.1
  6. No more Wifi products.
  7. Many now-necessary peripheral cords were handed off to Belkin.
  8. The ability to officially modify the HD or Ram has been steadily diminished, and has now reached iOS levels of non-interchangeability.
  9. All Mac laptop designs from last two years now only have two (kinds) of ports – usb-c headphones.

At this point, there seems to be a very clear pattern regarding hardware designed in the last year or so:

An iOS device == screen cpu/hard + drive/memory + touch input + single charging/data port headphone jack. The desired interface between an iOS device and the rest of the world is bluetooth or Wifi

A Mac == screen cpu/hard + drive/memory + keyboard input mouse input + a unified type of charging/data port+  headphone jack. The desired interface between a mac device and the rest of the world is bluetooth, Wifi or possibly USB-C

The only significant difference is the kind of input that each type of device relies on.

Read More »

Discovery Of The Day/ Variables View

In my quest to rediscover the most basic of functionality in Xcode that has been sitting in front of my face for the last couple years, I have discovered the value of the Variables view.

What is that you ask? Oh, that’s the white panel that I am always in a hurry to shove out of my way so that I can get to the lldb command line in the console view in order to po object.value. Let me show you what the Variables view does:

oh-thats-pretty-helpful

Yes, you are correct, it shows the value of every variable that is currently within scope.

Too bad Apple hid it so well. Maybe they should do something about that in their documentation. 😉

variables-view-apple