Rob Rix’s “Postmodern Programming” talk transcript
The important parts of the job are done with our minds. It’s how we think about things, and what things we think up, and how we arrange these things. that is to say, you will very likely make you a better programmer, and I will be very glad indeed if I have helped in some small way. Before that, I spent eighteen months implementing sync, and so I know a thing or two about making mistakes. If it’s new to you, there’s nothing wrong with that, either—it just means it’s your lucky day, and for that matter, mine too. So please don’t take my word on anything: if there’s anything in here that strikes you as interesting or dull or likely or implausible, try it out for yourself. See where it takes you. More than anything else, I would love to see you make things. In truth, it isn’t easy selecting a name, but that’s not the hard part by half. The hard part is selecting something which is deserving of a name: abstracting. With -setUpNavigationItem, defining the what is a contradiction in terms: it’s not a noun, not a concept. It has no value (by which I mean that it declares its return type to be void, i.e. no type, no value). It was abstracted, but in a sense it is not an abstraction, but merely an extraction of specific instructions. In this sense, too, -setChild: and -setUpNavigationItem are not abstractions, despite having been abstracted: they have no meaning, only instructions. They are not nouns. They are not concepts. but I promise the segue makes sense if you’re me. instead the Grand Declarator, telling each abstraction what it is. Again: how vs. what. At the same time, abstracting imperatively, abstracting-without-abstractions, denies you the ability to deal with these extra concepts behind the veil of local complexity; that is, any code using an imperative abstraction necessarily incurs the complexity of any changes it performs in a total sense (as with any other abstraction), but also incurs it locally—because any other changes to the same state need to be carefully sequenced. The details leak from callee to caller, again and again, and can never be contained. part of what I think about when I think of “declarative programming” is the notion that you are constructing a system of objects at runtime out of which the desired behaviour falls naturally: a necessary consequence of the structure. Composition is abstraction’s dual; where abstraction is breaking a problem into simpler components, composition is reassembling those into the solution. Constructing an abstraction is generally itself composition of other abstractions; any time you use an abstraction, you are composing. It is therefore in our best interests to ensure that the abstractions we build are as simple as possible: simple abstractions are more flexible, meaning more easily composed together, because they do not introduce factors not necessary to their operation. And it is clearly the direction that the market and the industry is heading in: there is a lot of ongoing, exciting research being done in declarative languages and systems and how to survive in an imperative world. It’s necessarily different, of course; if control flow is abstracted, it becomes increasingly difficult for your the API’s client to simply use lldb to debug it. To abstract is to identify an idea, a concept, as a unique thing which can be reasoned and acted upon in isolation. It is to give it a name; to define that name with that concept. This is equally true in language and in code. or of the bittersweet experience of a trusted colleague and friend leaving to work on something important to them If abstraction is vocabulary, then composition is grammar