Documenting Specific F%&cking Syntax For The Examples On f%&

While I am enjoying Swift more and more, I still love Objective-C, and continue to work in it professionally. One of the biggest syntactic pain points in Objective-C is definitely blocks (closures for the non Objc).

When trying to write an Objective-C block from scratch, the majority of iOS developers turn immediately to (This is not a secret) Due to the slightly off-putting syntax that is different in different contexts.

But I often find myself slowed down for a couple minutes trying to turn the generalized syntax (below) into specific syntax:

As a local variable:

returnType (^blockName)(parameterTypes) = ^returnType(parameters) {...};

Read More »


Swift Sugar: Ternary Operators – Optional Extension

In my previous post, I wrote some custom operators to function like the Objective-C version of ? : when checking for nil. It worked great, but custom operators ˘\_(ツ)_/˘.

Another approach occurred to me that takes care of the visual clutter that bothered me about this line:

let dependentParameter = optionalParameter != nil ? valueIfNotNil : valueIfNil

I realized that I could simply write an extension to the Optional class:

Read More »

Swift Sugar For Optional Ternary Operators

It is a common situation that an optional parameter is being passed into a function and that some other parameter needs to be set based on whether or not the optional parameter is nil or contains a value.

A typical way of handling this in Swift might be to use the if-let syntax as so:

func aFunction(optionalParameter: String?) {

    var dependentParameter = ""

    if let _ = optionalParameter {
        dependentParameter = valueIfNotNil
    } else {
        dependentParameter = valueIfNil
    //do something with dependentParameter

Read More »

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 ↩︎

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?


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

Or this:1

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

Read More »