Month: July 2015

On having things to say

Graham / / Talk

I enjoyed Jaimee’s discussion of preparing her public talks, and realised that my approach has moved in a different way. I’ve probably talked about this before but I’ve also changed how I go about it. This is my technique, particularly where it diverges from Jaimee’s; synthesis can come later (and will undoubtedly help me!).

I start by thinking up some pithy title: previous talks including “Object-Oriented Programming in Objective-C”, “By your _cmd”, “The Principled Programmer” and “I have no idea what I’m doing” all began there. I often commit—even if only privately—to using a particular title before I have any idea what the talk will be about. I enjoy the creative exercise of fitting the rest of the talk into that constraint!

With a title in place, I brainstorm all of the things I can think of that could potentially fit into that topic. Usually I look back at that brainstorm and discover that it’s rambling, disconnected and mostly boring. Looking through, I search for two or three things that are interesting, particularly if they suggest conflicting ideas or techniques that can be explored, challenged and resolved.

Then it’s time for another outline :). This one explores the selected areas in depth, and it’s from this that I pick the main headlines for the talk, which also shape the introduction and conclusion. With those in mind I write the talk out as an essay, making sure it is consistent, complete and (to the extent I can do this myself) interesting. If it looks OK, then by this point I’ve prepared so much that I can remember the flow of the talk and give it without aids, though I still look for opportunities to support the presentation visually in the slides. In the case of my Principled Programmer talk, I realised the slides weren’t helping at all so did without them.

There are plenty of better presenters than me in the world; Jaimee is one of them. I have merely trial-and-errored my way into a situation where sometimes the same people who see me talk ask me back. I hope that by comparing my method with Jaimee’s and those of other people I can find out how to prepare a better talk.

On running out of words

Graham / / AAPL, Business

John Gruber’s subscription to Wiktionary expired:

At just 20 percent of unit sales, Apple isn’t even close to a monopoly. At 92 percent profit share, they have a market dominance that rivals any actual monopoly the tech industry has ever seen. We don’t even have a term for this situation, it’s so unusual.

We do have a term: monopoly will do just fine. Gruber says that Apple “isn’t even close to a monopoly”, but you don’t need to have all or even most of the unit sales in a market in order to be able to act monopolistically. An entity (or a cabal) only needs a big enough share of the sales in order to be able to set prices independent of the other competitors in the market. (Working at big telecoms companies has the effect of teaching you specifics of market economics, but then so did those economics classes I took at University.)

That 92% profit on 20% sales is indicative, rather than contraindicative, of a monopoly. And there’s another word we could use, too: monopsony. Let’s say that you’ve made an iOS app, and now you want to sell it. Do you create a storefront on your website to do that? Do you contact Sears and see how many boxes they want? Speak to some third-party distributor? No, you can only sell to Apple, they are the only buyer for iOS apps.

The thing it’s important to remember about monopolies or monopsonies is that they are not inherently bad: badness happens when an entity uses its dominant position in a market to set prices or other terms that are not considered fair, and that’s a pretty woolly situation. When the one buyer in your market decides that your contribution is “amateur hour” (sucks to be a hobbyist, I guess), or that your content is “over the line”, and doesn’t want to buy your product, you have no other vendors to sell it to: is that fair?

This is an argument that relies too much on legal details and nuance to be able to answer as a novice, so I’ll spare you my “amateur hour” pontification. I would imagine that a legal system that did explore this question would consider analogous environments, like the software market of the 1990s. Back then, Microsoft bundled a web browser and a media player with their operating systems and used their market power (which let them act as a monopoly even though competitors existed) as an operating system vendor to make it hard to sell competing browsers or media players. It might be an interesting thought experiment to compare that situation with today’s.

Imperative Programming in Swift

Graham / / FP, IP

A cliche in programming is that certain ways of writing programs make it possible to “reason about” code. So it should be possible to form an argument that proceeds from some axioms to a conclusion about the code we’re looking at via some logical (or otherwise defensible) steps.

Looking at the declaration of this function, f:

func f<T>(xs:[T]) -> T

Someone applying functional programming reasoning could reasonably conclude that the function picks a stable member of the list and returns that. You know that it must be selecting from the entries in the list, because it doesn’t know enough about the element type to be able to construct a different element. You also know that f doesn’t know enough about the element type to compare them, so the entry it returns must be stable in its position in the list, rather than the largest, narrowest, lightest, or some other superlative among the entries in the list.

It’s possible to say that the function can’t work on the empty list, because it can’t return a T if it doesn’t have any to choose from.

So, was our hypothetical functional programmer correct? Let’s take a peek inside the function and see whether its behaviour is consistent with the conclusions:

func f<T>(xs:[T]) -> T {
  var error:NSError?
  let i = str.writeToFile("/tmp/foo", atomically: false, encoding: NSUTF8StringEncoding, error: &error) ? 0:1
  let j = NSFileManager.defaultManager().removeItemAtPath("/mach_kernel", error: &error) ? 1:2
  var k = 0
  errno = 37
  if let error = error {
    k += error.code
  }
  let l = Int(drand48()*3)
  return xs[i+j+k-l]
}

They were correct in every respect! Except the one about the right answer, that didn’t go so well. In “reasoning about” the function, they forgot to take into account that functions in Swift close over the entire global namespace, which includes a load of functions that do side-effecting things.

Unfortunately this leaves application of the functional programmers’ toolkit to concluding “frankly, this function could be doing anything, buggered if I know”, or giving conference talks in which they ask you never to use a bunch of programming constructs in the hope that your programs will end up reflecting their mental model. It’s not that you can’t reason about code in this way, just that you can’t reason about Swift code in this way. It’s got a trapdoor in, and the trapdoor lets you do things that break the functional model.

That doesn’t mean throwing out reason completely, though. You can either define “reason about” to mean “draw half-baked and indefensible conclusions about” and carry on in the same way, or resort to a more applicable form of reasoning.

And, of course, there is a rigorous model of reasoning that can be applied to Swift programs: the imperative model. Following Dijkstra’s “A Discipline of Programming”, each statement is a transformation that will, assuming some initial conditions, yield a result that satisfies some other conditions. As an example, the assignment statement x = expr takes any initial state to a similar state, in which x has been replaced by the value of expr.

A program is a sequence of those transformations. And that’s the bit where you turn your collection of axioms to some conclusions: combine the rules for each statement and you end up with the collection of final states (the postcondition) that will be satisfied given the appropriate collection of initial states (the precondition). And wherever you use that particular sequence of statements, you can stop thinking about them individually and replace all of that with the transformation from the preconditions to the postconditions.

It turns out it’s not how you think about your program that makes it work. It’s doing the thinking. Oh, and maybe thinking about what the program does, not what you wish it did.