Back in the day, when programmers knew that they couldn’t possibly think of everything somebody might want to do with a computer, there were scripts. If somebody could find enough of the pieces of the thing that they wanted to do, they might be able to put them together themselves in furtherance of their task.
Many times, constructing these scripts was a lot like programming the software being glued together. On the Amiga there was ARexx, on the PC there were batch files, on Mac there was AppleScript: all programming in its own right, making new applications out of the ones you’d bought.
Applications. Here’s the dichotomy. Think of two axes on a chart: one axis records the things you want to do with a computer; the tasks you want to complete. The other records the things you can do with the computer: the applications to which it can be put.
These axes are not perpendicular, as if there is no projection into your tasks by your applications. But they are not parallel either. And where the directions taken by the applications are not progressing your tasks, in comes scripting to provide bridges between those applications and take you on your way.
Not all of these bridges are esoteric programming languages on top of other programming languages. NeXT had services, in which applications could publish menu items that became available in other applications where the two were using the same data. Apple took a bit from each column to make Automator, a UI in which you could snap together bits of applications to make your task.
All of this represented a helpfulness and humility on the part of the applications makers: we do not know everything you want to do. We do know some things you might want to do: we’ll let you combine them and mash them up – “rip, mix and burn” as they used to say – making you more satisfied and our stuff more useful.
Sadly all of this utility plays merry hell with branding. Applications aren’t just utilities, they’re icons in the launcher, splash screens, names in menu bars, reminders that I also make other applications and by the way have you rated this one five stars yet? Scripts stop people seeing that, they’re too busy using their computers productively to see the marketing.
And so it’s sad to see scripting die out as the popular platforms for application development fail to support it. Instead of the personal control of the script – I will take this information from that app, and put this part of it in that app – we have the corporate control of the API. This app maker and that app maker are BFFs, sign in here to let them share everything. After all, they know best.
Ultimately the death of scripting is hubristic. We know how you want to use a computer. If you’re trying to do something that we didn’t sell to you, you must be holding it wrong.
Android still has something like that with the notion of intents and content URLs. In iOS (just like in MacOSX), IIRC applications can also define URL schemas they can process.
But indeed, like services and scriptability of GUI applications in general, this depends on explicit work on the part of the developers to add modularisation and scriptability to their applications.
But foremost, also on the part of the platform developer, to provide the tools and user interface to let users write or design scripts. Which is far from the case on Android and iOS.
mmm… pretty brutal, but probably true. I’ll give up AppleScript when they pry it from my cold, dead keyboard…
I beg to differ. Scripting is not only alive, but growing and expanding. In the sysadmin field we’re writing more and more tools, python, perl, ruby, go, $language-of-choice scripts to automate everything we can do. With it comes consistency and reliability, along with labour multiplying. My environment has so many thousands of servers in it, there’s no way I could operate it without scripting to a high degree, but even when I was responsible for under a hundred servers I still focused heavily on automating as much as I could and writing utility code.
On that front, although I deal with purely Linux environments, I’m aware of the major changes that Microsoft has brung to Windows work with the introduction of Powershell. Suddenly everything in the OS has become an object, with properties, and all of them can be manipulated through powershell scripts. My understanding is that even their management GUIs have become little more than a graphical front end to Powershell. In some regards, Microsoft sysadmins now have more power and flexibility than those of us in the Linux world have. This transition has been key in allowing them to finally release non-GUI versions of Windows, which are particularly key for cloud environments.
I was wondering whether to do a follow-up on how, on platforms where scripting/automation is available, it’s designed for fellow IT professionals, and what that means for the majority of users. After reading this comment, I think I’ll get on to writing that.
Pingback: Michael Tsai - Blog - The Death of Scripting
Apple has been adding JavaScriptCore to iOS from OS X. An iPad Pro with new iWork will probably bring app scripting to iOS (and Macs and maybe even iWork in iCloud) in a big way. Why else would they spend so much effort on this?
I frequently see the sentiment that Apple will ride in on their white horse and save us from whatever our problems are, even where our problems are Apple as in the current discussion. However, I see no evidence of an iPad Pro, new iWork (apart from the recent one that removed a load of scripting capability), nor effort that they’re spending “so much effort” on those things. Your faith is, I think, misplaced.
Scripting is dying not because of companies or marketers. Its dying because of the choices people make. People prefer consumption to production. The easy to the difficult. The quick to the slow. And businesses have been catering to them. Apple is a business. It gives people what they want.
It won’t save us because its not the problem. We are. The better question is who is going to save Apple from us.