This is a false dichotomy because communication is a technical skill. The ability to articulate complex ideas is a hallmark of deep understanding. ​ In other words, they are commended for having to deal with the debris of leftover chaos they usually didn’t create, nor had very much control over. ​ Communication skills allow an individual to understand and be understood. They combine self-awareness, empathy, active listening, speaking, and observing into a cocktail of abilities that grease the wheels of every interaction, but often go undetected. Dissociating communication and technical skills, while seemingly innocuous and even pragmatic, can create a harmful dichotomy, one that stunts corners of the industry. ​ Lexical double-booking ​ let us concentrate rather on explaining to human beings what we want a computer to do. ​ but it also allows incompetence to hide behind unnecessarily intellectualized terminology. ​ Those with strong communication skills are capable of using domain-specific language appropriately while also being capable of context-switching to adapt their message to their audience. ​ Being clear is not about being dumb, but, as Eugenia Cheng said, about identifying a problem with the precision and clarity that is appropriate for the context. ​ The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

(See PDF in reMarkable for annotations and notes).

In July 2019, ICMS hosted a workshop on Category Theory.  During the workshop, Eugenia Cheng (School of the Art Institute of Chicago) gave a public lecture entitled Inclusion-Exclusion in mathematics and beyond: who stays in, who falls out, why it happens and what we could do about it. This is a recording of that talkThis talk has captions.  To turn the captions off, press CC on the bottom toolbar.

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