4 ms·

Well, I was too young to really explore classic Mac OS at that time. But from my feeling, the unixoidity of Mac OS X was really a blessing for the hacking commu

by ktpsns 8y ago

Well, I was too young to really explore classic Mac OS at that time. But from my feeling, the unixoidity of Mac OS X was really a blessing for the hacking community. So there definetly was a need.

chongli 8y ago
Oh don't get me wrong, I live in the terminal these days. It's immensely satisfying to whip up a quick bash or Perl script to solve a problem. That being said, I believe the reliance Unix command line tools has made this computing power inaccessible to ordinary users. In some sense, I think it has deepened the digital divide.
- laumars 8y ago
  You could still do scripting akin to Bash scripts on OS 7 and above via AppleScript[1]; which worked a little bit like WSH did on Windows. [1] https://en.wikipedia.org/wiki/AppleScript https://en.wikipedia.org/wiki/AppleScript
  - chongli 8y ago
    Yes, and I'm an old fan of AppleScript as well. The difference, as far as I know, is that you couldn't hide core application functionality behind that API, could you? If you could, I think most developers didn't, since AppleScript isn't a default means of using the computer the way Unix shells are.
- ergothus 8y ago
  I like your viewpoint, but my experience with GUIs was largely that THEY hid power...from me. Any setting that could only be managed from within a GUI meant automation was pretty much off the table (and by "automation" I mean any basic connection of two tasks, things joe average user would want, not necessarily heavy industrial automation). Remember when Windows NT had only a binary event log, and their graphical client was the only way to view it? I think the issue is not so much "command line hides power and treats GUI like a second-class citizen", though that is true, but rather that preferring one over the other creates problems. This issue is again rearing its head in website design - many "web applications" have states that are not reachable via linking.
  - pseudalopex 8y ago
    Most applications focus on either the GUI or the CLI because building two complete interfaces takes a lot of work. You're right that a lot of GUIs aren't designed for automation, but CLIs aren't the only answer. Classic MacOS had a powerful scripting architecture. (It still exists, but it's been neglected.)
  - derefr 8y ago
    Back before the Unix-ization of macOS, there was a large focus on programs providing accessibility/automation APIs. The GUI parts of macOS were actually far more scriptable back in the OS7-9 days (and early OSX days) than they are today. It used to be that any effect you wanted to trigger in the OS, you could do by sending an https://en.wikipedia.org/wiki/Apple_event https://en.wikipedia.org/wiki/Apple_event through the OSA scripting component to the relevant system service. Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more. (Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)

by ktpsns 8y ago

Well, I was too young to really explore classic Mac OS at that time. But from my feeling, the unixoidity of Mac OS X was really a blessing for the hacking community. So there definetly was a need.

chongli 8y ago

Oh don't get me wrong, I live in the terminal these days. It's immensely satisfying to whip up a quick bash or Perl script to solve a problem. That being said, I believe the reliance Unix command line tools has made this computing power inaccessible to ordinary users. In some sense, I think it has deepened the digital divide.

laumars 8y ago
You could still do scripting akin to Bash scripts on OS 7 and above via AppleScript[1]; which worked a little bit like WSH did on Windows. [1] https://en.wikipedia.org/wiki/AppleScript https://en.wikipedia.org/wiki/AppleScript
- chongli 8y ago
  Yes, and I'm an old fan of AppleScript as well. The difference, as far as I know, is that you couldn't hide core application functionality behind that API, could you? If you could, I think most developers didn't, since AppleScript isn't a default means of using the computer the way Unix shells are.
ergothus 8y ago
I like your viewpoint, but my experience with GUIs was largely that THEY hid power...from me. Any setting that could only be managed from within a GUI meant automation was pretty much off the table (and by "automation" I mean any basic connection of two tasks, things joe average user would want, not necessarily heavy industrial automation). Remember when Windows NT had only a binary event log, and their graphical client was the only way to view it? I think the issue is not so much "command line hides power and treats GUI like a second-class citizen", though that is true, but rather that preferring one over the other creates problems. This issue is again rearing its head in website design - many "web applications" have states that are not reachable via linking.
- pseudalopex 8y ago
  Most applications focus on either the GUI or the CLI because building two complete interfaces takes a lot of work. You're right that a lot of GUIs aren't designed for automation, but CLIs aren't the only answer. Classic MacOS had a powerful scripting architecture. (It still exists, but it's been neglected.)
- derefr 8y ago
  Back before the Unix-ization of macOS, there was a large focus on programs providing accessibility/automation APIs. The GUI parts of macOS were actually far more scriptable back in the OS7-9 days (and early OSX days) than they are today. It used to be that any effect you wanted to trigger in the OS, you could do by sending an https://en.wikipedia.org/wiki/Apple_event https://en.wikipedia.org/wiki/Apple_event through the OSA scripting component to the relevant system service. Nowadays on macOS, with the availability of the CLI, Apple engineers have decided to expose those same effects through CLI utilities that call directly into private system APIs (which are themselves usually client libraries for private Mach client-server ABIs.) If there's a switch exposed in the GUI but not the CLI, it's unlikely there's an event to reach it any more. (Though, in macOS or Windows or Linux, it's always a possibility to write a script that has GUI effects directly in terms of "click the first button on the right"-style accessibility directions. But that's extremely brittle to system version updates, and precisely the thing that exposing an automation API is meant to avoid.)