Starting next week: [objc retain]; in which Steven Baker and I live-code Objective-C on a modern free software platform. Wednesday, February 10th, 1900UTC. More info at objc-retain.com.
Another day, another post telling me to do something, or not do something, or adopt some technology, or not adopt some technology, or whatever it is that they want me to do, because it makes it easier to “reason about the code”.
It’s a scam.
More precisely, it’s a thought-terminating cliche. Ironic, as the phrase “reason about” is used as a highfalutin synonym for “think about”. The idea is that there’s nowhere to go from here. I want to do things one way, some random on medium dot com wants me to do things another way, their way makes it easier to reason about the code, therefore that’s the better approach.
It’s a scam.
Let’s start with the fact that people don’t think—sorry, reason—about things the same way. If we did, then there’d be little point to things like film review sites, code style guides, or democracy. We don’t know precisely what influences different people to think in different ways about different things, but we have some ideas. Some of the ideas just raise other questions: like if you say “it’s a cultural difference” then we have to ask “well, why is it normal for all of the people in that culture to think this way, and all of the people in this culture to think that way?”
This difference between modes of thought arises in computing. We know, for example, that you can basically use any programming language for basically any purpose, because back in the days when there were intellectual giants in computering they demonstrated that all of these languages are interchangeable. They did so before we’d designed the languages. So choice of programming language is arbitrary, unless motivated by external circumstances like which vendor your CTO plays squash with or whether you are by nature populist or contrarian.
Such differences arise elsewhere than in choice of language. Comprehension of paradigms, for example: the Smalltalk folks noticed it was easier to teach object-oriented programming to children than to professional programmers, because the professional programmers already had mental toolkits for comprehending programming that didn’t integrate with the object model. It’s easier for them to “reason about” imperative code than objects.
OK, so when someone says that something makes it easier to “reason about” the code, what they mean is that that person find it easier to think about code in the presence of this property. I mean, assuming they do, and are not disingenuously proposing a suggestion that you do something when they’ve run out of reasons you should do it but still think it’d be a good idea. But wait.
It’s a scam.
Code is a particular representation of, at best, yesterday’s understanding of the problem you’re trying to solve. “Reasoning about code” is by necessity accidental complexity: it’s reflecting on and trying to understand a historical solution of the problem as you once thought it was. That’s effort that could better be focussed on checking whether your understanding of the problem is indeed correct, or needs updating. Or on capturing a solution to an up-to-the-minute model of the problem in executable form.
This points to a need for code to be deletable way faster than it needs to be thought about.
Reasoning about code is a scam.
I, along with many others, have written about the influence of Xerox PARC on Apple. The NeXT workstation was a great example of getting an approximation to the Smalltalk concept out using off-the-shelf parts, and Jobs often presaged iCloud with his discussion of NetInfo, NFS, and even the magneto-optical drive. He’d clearly been paying attention to PARC’s Ubiquitous Computing model. And of course the iPad with Siri is what you get if you marry the concept of the DynaBook with a desire to control the entire widget, not ceding that control to some sap who’s only claim to fame is that they bought the thing.
Sorry, they licensed the thing.
There are some good signs that Apple are still following the ubicomp playbook, and that’s encouraging because it will make a lot of their products better integrated, and more useful. Particularly, the Apple Watch is clearly the most “me” of any of my things (it’s strapped to my arm, while everything else is potentially on a desk in a different room, stuck to my wall, or in my pocket or bag) so it makes sense that that’s the thing I identify with to everything else. Unlocking a Mac with my watch is great, and using my watch to tell my TV that I’m the one plugging away at a fitness workout is similarly helpful.
To continue along this route, the bigger screen devices (the “boards”, “pads”, and “tabs” of ubicomp; the TVs, Macs, iPads, and iPhones of Apple’s parlance) need to give up their identities as “mine”. This is tricky for the iPhone, because it’s got an attachment to a phone number and billing account that is certainly someone’s, but in general the idea should be that my watch tells a nearby screen that it’s me using it, and that it should have access to my documents and storage. And, by extension, not to somebody else’s.
A scene. A company is giving a presentation, with a small number of people in the room and more dialled in over FaceTime (work with me, here). It’s time for the CTO to present the architecture, so she uses the Keynote app on her watch to request control of the Apple TV on the wall. It offers a list of her presentations in iCloud, she picks the relevant one by scrolling the digital crown, and now has a slide remote on her wrist, and her slides on the screen.
This works well if the Apple TV isn’t “logged in” to an iCloud account or Apple ID, but instead “borrows” access from the watch. Because the watch is on my wrist, so it’s the thing that is most definably “mine”, unlike the Apple TV and the FaceTime call which are “my employer’s”.
LIVEstep is a GNUstep desktop on a FreeBSD live CD, and it comes with the GNUstep developer tools including ProjectCenter. This video is a “Hello, World” walkthrough using ProjectCenter on LIVEstep. PC is much more influenced by the NeXT Project Builder than by Xcode, so it might look a little weird to younger eyes.
Here’s what I’ve been working on (with others, of course) since February.
In fact, while this is about a theory of software engineering, that doesn’t enter until the end of the show. Most of it is an attempt to incorrectly summarise the history of software engineering through analogy to the history of punk music.
You may remember in July I updated the open source Bean word processor to work with then-latest Xcode and macOS. Over the last couple of days I’ve added iCloud Drive support (obviously only if the app is associated with an App Store ID, but everyone gets the autosave changes), and made sure it works on Big Sur and Apple Silicon.
Alongside this, a few little internal housekeeping changes: there’s now a unit test target, the app uses base localisation, and for each file I had to edit, I cleaned up some warnings.
Developers can try this new version out from source. I haven’t created a new build yet, because I’m still in the process of removing James Hoover’s update-checking code which would replace Bean with the proprietary version from his website. I’ll create and host a Sparkle appcast for automatic updates before doing a binary release, which will support macOS 10.6-11.1.
A discussion on whether Swift was inevitable and whether it has achieved its goals, motivated by @tolmasky’s discussion with @lorenb on the Thoughts on Flash letter.
Along the way I talk about Apple’s strategic investment into Java: I’ve discussed that in greater detail on this blog so largely lean on this article in the podcast.
In which I discuss the thorny issue of whether software engineering should be a licensed profession, mostly from the perspective of the ACM’s argument against it. Also considered is how, or even if, the whole Software Engineering Body of Knowledge (SWEBoK) could be examined in a single sitting, and whether an incremental approach like the Software Engineering Institute’s CMMI would work, or even be adopted.
As if you couldn’t guess, the topic is that software engineers should attend more meetings. I talk about the Maker’s Schedule, Manager’s Schedule idea, why it’s a false dichotomy, and why programmers can actually get to more meetings than they think without doing worse work. In fact, it’ll make their work better.
The book about all the things software writers do that aren't writing software.
