41–50 of 51 posts
Utter garbage click-bait and FUD. "Scripting" in the form of writing code in high-level programming languages is not going away anytime in the foreseeable future.
That's not the definition of scripting that the article was refering to. The article was refering to automating tasks, which is usually, but not necessarily, accomplished with "scripting languages".
This is just historically and non-historically inaccurate. 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'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. Second, APIs for web services actually do support…
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?
Earlier quoted context omitted.
Do you run a free software focused system like GNU/Linux? They're much more scriptable than OS X and Windows because (1) a lot of programs embrace the Unix interoperability conventions and (2) free software means that if someone felt that a program's scripting facilities are lacking they can submit a patch. Even if you don't, I assume that you are a programmer based on context and your comment, which means that the a…
OS X. Even Spotify is scriptable.
But if this is the optimal UI for highly competitive environments, why isn't it also the optimal UI for uncompetitive competitive environments like retail?
Two reasons:
1. Self selection. The highly competitive environments attract extremely intelligent people. Abstractionists can assemble a breadth of solutions that systematize solutions, while workers such as retailers are generally less adept.
2. A constriction on UI is similar to a schema constriction. Aside from the occasional "General Notes" field on a intake form, the interaction can be structured more reliably than a person with a terminal shell. This is important partially because lesser skilled people can't be trusted to make higher level decisions like data structure.
I don't think #2 is a hard limit, I think UIs can be designed around the limitations of human intelligence and I think that systemic educational changes could make CLIs more friendly to the general public; but I think there is a local maxima that is more easily solved with software like Tulip* and so that is what we have now.
Earlier quoted context omitted.
OS X. Even Spotify is scriptable.
Is Spotify on iOS scriptable?
A smartphone is for checking the weather, reading, looking up places to eat, movies, requesting an Uber or figuring out what bus is coming next, and so on. If you're not using your smartphone for that stuff and instead are scripting your music collection, why even leave your house? Just stay at home and use a computer.
Earlier quoted context omitted.
Do you use scripting on your smartphone or tablet?
If you're looking at your smartphone or tablet and wanting to script it, put it down and find yourself a desktop or laptop. Edit: Smartphones and tablets are simply not general purpose computers. I don't want a desktop type OS on either my phone or tablet. I certainly don't want a tablet OS on my desktop. That defeats the purpose. Smartphones and tablets are good at certain things the require _direct user input_. If…
What you're missing is, for many of us, scripting is fundamentally how we interact with computing devices in a convenient way. I don't know if I want "a desktop type OS" on my phone or tablet, but I definitely (!!!) want an OS that allows me to easily and flexibly compose disparate pieces of functionality across contexts.
Earlier quoted context omitted.
I've definitely looked into it. I bought, with enthusiasm, a tablet with the first version of Android that supported Python. Installing the necessary pieces, and editing programs both seem to be super awkward, and my beloved Tkinter has not been ported. I know there are ways, but if it's not more convenient than just walking back to my desk and doing it on a PC, then it won't happen. Also, truth be told, since I got…
You should check out QPython or QPython3 from the Play Store. It includes the Python binary, an editor, and a terminal emulator. It is all bundled up. So easy to setup a child could do it. Unfortunately installing Python manually has not gotten much easier, though it's certainly doable. You can even use Tkinter, but that is beyond the scope of this comment.
This is just historically and non-historically inaccurate. 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'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. Second, APIs for web services actually do support…
> 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 notat…
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.
2. How is "program" different from "script"?
Earlier quoted context omitted.
Is Spotify on iOS scriptable?
Why do people keep bringing up mobile devices like it is some kind of trump card? If you really want to script a mobile device, install whatever Linux distro you want on an Android phone and go to town. Congratulation, you just created a tiny under powered laptop with a shitty screen and an even shittier keyboard. A smartphone is for checking the weather, reading, looking up places to eat, movies, requesting an Uber…
I'd like to be able to use it for more. It is, after all, a computer.
Earlier quoted context omitted.
You should check out QPython or QPython3 from the Play Store. It includes the Python binary, an editor, and a terminal emulator. It is all bundled up. So easy to setup a child could do it. Unfortunately installing Python manually has not gotten much easier, though it's certainly doable. You can even use Tkinter, but that is beyond the scope of this comment.
I'll definitely check it out. My dream is to be platform independent, i.e., to be able to write / edit / run the same program on any device. So far so good with Windows and Linux, including Raspberry Pi, but my phone feels left out.
As far as cross-platform across desktop and mobile, that's a difficult challenge. Java used to be the go-to if you want to be platform agnostic but that obviously won't cut it if you want to support mobile. You can check out Qt. I only use it on Linux but it apparently supports Windows, Mac OSX, Android, IOS, and Windows Phone (maybe even more).