> First, there was no guarantee you could get useful data out of the programs of the PC and Mac era if they didn't explicitly support getting data out.
I don't know why you keep lumping the Mac in with the PC; on the Mac -- not counting AppleScript, the myriad of data translation tools, etc -- there was rich copy+paste support that worked between applications.
> I've got tons of sheet music in a Windows 3.1-era notation program that I can't get out, because it's stored in a binary format and there's no built-in exporter.
So write a conversion tool that parses the file format; if it's sheet music, the format isn't going to be too hard to decipher. How is this any different, other than scale, than the "web APIs" you claim solve the author's complaints?
> Second, APIs for web services actually do support lots of this.
No, they don't. They require writing code, which requires that you actually be able to, you know, program.
In addition, even being able to use these "web service APIs" requires that you give all your data, control of your applications, and the ability to get work done to a 3rd-party service.
That's not a replacement for a desktop application.
> The fact that some '90s desktop apps were easily scriptable ...
Not some. Almost all. Even when they didn't explicitly support it, there was generally a way to get what you wanted done, done, thanks to scripting language integration with standard OS-level APIs upon which the applications relied.
> (Not to mention most '10s web services being scrapable. I don't remember any screen-scraping tools for Windows 3.1 or classic Mac UIs that were anywhere near as good as the web-scraping tools we have today.)
You mean the classic Mac OS where you could literally hit "Record" in AppleScript Editor and produce a surprisingly workable script based on your actual UI actions in the applications?
Or modern Mac OS and iOS, where things like VoiceOver give you semantic access to the entirety of the UI?
> So write a conversion tool that parses the file format; if it's sheet music, the format isn't going to be too hard to decipher.
I appreciate your optimism. NoteWorthy Composer was first released in 1994; last I looked was around 2011. It looks like that year, after I stopped looking because I was no longer singing with the group using binary .nwc files, MIT's Music21 project started scraping together beginnings of a parser. (Also, sometime around 2007, the software authors voluntarily added a text export format. That doesn't count, because it depends on the goodwill of the software authors, just like the web services being decried.)
If it took fifteen years for someone to decipher the format, and it only started being slightly parseable in the modern web API era where we've supposedly left scripting behind, I don't think you can claim either that it "isn't going to be too hard to decipher," nor that we're losing anything in our modern era.
(Also, like, my memory of software in the '90s is that in several cases the authors went out of their way to add obfuscation or anti-tampering features to their data formats.)
> How is this any different, other than scale, than the "web APIs" you claim solve the author's complaints?
I didn't claim that they solve the author's complaints. I claimed that it makes no difference whether the software is web-based or local.
Your Mac vs. PC distinction is much the same. Some web services are pretty good at this; some aren't. If this is a criticism of the PC platform, phrase it as a criticism of the PC platform, not the web.
> No, they don't. They require writing code, which requires that you actually be able to, you know, program.
I don't know why you keep lumping the Mac in with the PC; on the Mac -- not counting AppleScript, the myriad of data translation tools, etc -- there was rich copy+paste support that worked between applications.
> I've got tons of sheet music in a Windows 3.1-era notation program that I can't get out, because it's stored in a binary format and there's no built-in exporter.
So write a conversion tool that parses the file format; if it's sheet music, the format isn't going to be too hard to decipher. How is this any different, other than scale, than the "web APIs" you claim solve the author's complaints?
> Second, APIs for web services actually do support lots of this.
No, they don't. They require writing code, which requires that you actually be able to, you know, program.
In addition, even being able to use these "web service APIs" requires that you give all your data, control of your applications, and the ability to get work done to a 3rd-party service.
That's not a replacement for a desktop application.
> The fact that some '90s desktop apps were easily scriptable ...
Not some. Almost all. Even when they didn't explicitly support it, there was generally a way to get what you wanted done, done, thanks to scripting language integration with standard OS-level APIs upon which the applications relied.
> (Not to mention most '10s web services being scrapable. I don't remember any screen-scraping tools for Windows 3.1 or classic Mac UIs that were anywhere near as good as the web-scraping tools we have today.)
You mean the classic Mac OS where you could literally hit "Record" in AppleScript Editor and produce a surprisingly workable script based on your actual UI actions in the applications?
Or modern Mac OS and iOS, where things like VoiceOver give you semantic access to the entirety of the UI?