Last Week on my Mac: Ethel & Ernest and change

I’m eagerly looking forward to watching the animated movie Ethel & Ernest, based on Raymond Briggs’ superb graphic novel. In preparation, I have read the book, and been surprised at the number of one-liners about progress and change.

They remind me of many of the comments which we have made of Apple over the years. My earliest recollection of this was in 1988, when Apple introduced its first optical drive, then the AppleCD SC. Because it started delivering developer tools and documentation on CD-ROM, this became a mandatory purchase for Apple developers, who moaned and whined for months, asking why Apple couldn’t stick to floppy disks.

Those first CD-ROM drives were of course read-only, and had SCSI interfaces. The first model came with a cooling fan, which conveniently blew dust onto the optical reader, so we learned how to clean them out fairly quickly too. We rapidly progressed through faster readers, then drives which could write too, and onto DVD media, before Apple stopped fitting optical drives into iMacs in 2013, to result in more cries of dissent. Yet I cannot now remember when I last used the external optical drive on my iMac, and even then I suspect it was to play a DVD.

I appreciate that I too have been accused of whining about Apple’s changes, or perhaps lack of progress at times. There is a curious phenomenon where those who are most involved in change – developers in particular – are often those who appear least happy with change, at least when it is thrust upon them by others. We also tend not to celebrate successful change as loudly as we could.

An interesting illustration is with the current standard macOS file system, Mac OS Extended or HFS+. I and many others have been moaning for several years that it is long due replacement with a proper modern file system, and we got quite excited when it looked as if Apple was going to adopt Sun’s ZFS a few years ago. But that was not to be, and HFS+ pottered on into another decade, with no signs of a likely replacement.

Now that Apple is finally beta-testing its Apple File System, APFS, with the intent of releasing it as the universal file system for all its computers and devices next year, we’ve started to complain about it already. The argument seems to be that APFS will bring greater integration of security protection, locking out system administrators and advanced users from working directly with any part of macOS. Although that might eventually come, it’s perhaps unfair to blame changes in security on a much-needed modern file system.

I may myself have engaged a little in my speculation over the future of AppleScript and automation services on macOS and iOS. I had hoped that my eulogy for the achievements of Sal Soghoian during his long tenure at Apple expressed appropriate sadness at his departure and its likely consequences, but also enthusiasm for what will succeed AppleScript.

What I hadn’t realised at the time that I wrote that article is that Apple has been anticipated in its likely move to make Swift the first-class scripting and automation language for macOS. When I was compiling my list of Swift learning resources, I stumbled across Scriptarian, by Matt Rajca.

It claims to be able to replace AppleScript completely, by bridging to the same AppleEvents used to make AppleScript work. That is under debate: Apple’s own alternatives, such as JavaScript for Automation, have been pretty disastrous, but some who have used Scriptarian think that its bridge is not yet ready for any serious traffic.

Rajca has several other Swift-based scripting projects under way, and I am sure that he is not the only one exploring this area. I doubt very much whether Apple would ever place AppleScript’s source code in the public domain, and it is not clear whether that would help anyone build a solid AppleEvent bridge for Swift or anything else. But these are signs that, if Apple is not prepared to come up with a successor to AppleScript, there are some experienced developers who are going to do it anyway.

The best response to change is often not to waste time and effort complaining about it. It is to see how you can exploit that change. I will be looking more closely at Scriptarian and Swift playgrounds for macOS in the coming weeks. Let’s see if we can get ahead of the field for once, rather than getting all Ethel & Ernest about it.