It seems that you insist that it can't be trivial, but you're not familiar with OSA and how e.g. Cocoa handles scriptable GUI apps.
OSA is Apple's scripting architecture for Cocoa, and with "dictionaries" (e.g. XML definition files) you can expose to a scriptability layer (accessible from AppleScript, Javascript, Python and all kinds of apps) any class or element in your app, quite simply. You don't have to change the internals of your Classes even.
This is not available in all GUI frameworks, but what I'm getting at is that this is not some inherent limitation of writing GUI apps, it's a limitation of current frameworks and the lack of thought it was given to this.
> But that stops when you need long-running session scriptability [...]
> Command line tools rarely are long-running things you need to interact with.
All kinds of deamons and servers are command line too, not just things like ls and grep. And these you want to interact with over their long-running lives. Same goes for tools with heavy initial startup time (e.g. a statistics tool that needs to load some data set, etc).
It's due to a lack of foresight/coordination (and "worse is better" mentality) that we don't have a unified scripting method for short term cli-tools, long-running cli apps, and GUI apps (and if we had ones, it could easily be extended to Cloud apps for the ultimate in automating and pipelining!).
>How so? Suddenly one doesn't need to understand what the current working directory is? How to work with files then? Of course it is necessary to know those concepts.
You can know those concepts at the GUI level (including abstractly). No need to know "cp", "rm", "ls -la" and other such text-based interactions with them. In fact there are computers that don't have these at all (most smartphones, the iPad, etc), and tons of Windows and OS X users never care for them anyway.
>But then they need to learn much about their IDE, which is as large area as basic proficiency with command line
Yes, but that knowledge is specific to their task (which is to learn programming).
"cp" and "ls -lah" and "rm" are not -- they already know another way to perform those tasks.
> [...]with "dictionaries" (e.g. XML definition files) you can expose to a scriptability layer (accessible from AppleScript, Javascript, Python and all kinds of apps) any class or element in your app, quite simply.
There you go. The mechanics of how this works is non-trivial. I would say it seems quite complex at this point.
Trivial would be if all it was to this scripting was "just this simple thing", like executing a program exactly the same way as always, but with provided command line parameters this time. Now you say "Python", so it must be first implemented by the author of GUI program, then exposed in "e.g. XML definition files", and then something (Cocoa, as you say) must transport some messages/calls from user's code to scripted program's code (how? through some kernel way? user-space bus? something different?). How this is trivial mechanics?
>> Command line tools rarely are long-running things you need to interact with.
> All kinds of deamons and servers are command line too, not just things like ls and grep. And these you want to interact with over their long-running lives.
But daemons are not command line tools. Command line is just a way to start them under unices. Under Windows it's a totally separate type of programs ("Windows services"). Even aside from that, daemons are not normally called for one-off tasks, but to provide services. This means you already need a communication channel for such a daemon.
> Same goes for tools with heavy initial startup time (e.g. a statistics tool that needs to load some data set, etc).
And what do you need/want to script in this statistics tool that loads plenty of data while it loads this data at its startup?
> You can know those concepts at the GUI level (including abstractly).
Current working directory? ROTFL. The whole point of GUI is to hide this concept, and you tell me one can learn it from GUI?
> In fact there are computers that don't have these at all (most smartphones, the iPad, etc),
Sorry to break your little utopia apart, but "most smartphones" run Linux or generally work with hierarchic filesystems, which is totally opposite of "no current working directory".
>> But then they need to learn much about their IDE, which is as large area as basic proficiency with command line
> Yes, but that knowledge is specific to their task (which is to learn programming).
It's not specific to programming, it's specific to their tool for learning programming.
> "cp" and "ls -lah" and "rm" are not -- they already know another way to perform those tasks.
And that's why I don't insist to use them or even learn them. What I insist is to learn how the compiler is called, what to feed it with (text/plain, with any editor, not just heavyweight IDE), and how to execute freshly produced binary.
Well, if by trivial you mean "totally effortless and thoughtless" then not. But I don't think that's the correct mental mode to create CLI interfaces either.
>But daemons are not command line tools. Command line is just a way to start them under unices. Under Windows it's a totally separate type of programs ("Windows services").
Command line is any headless program. And you can start Windows servers from the command line too.
>Even aside from that, daemons are not normally called for one-off tasks, but to provide services. This means you already need a communication channel for such a daemon.
That's narrow thinking.
First, e.g. "grep" also provides a service of returning matching results. Whether it does it once-of or as a deamon (one could easily imagine a grep deamon, not unlike Solr or Spotlight) is irrelevant with respect to its scriptability.
It's only because we don't plan for it, that we have this artificial restrictions -- "that's a deamon, you can't script it like that".
Besides, regarding "This means you already need a communication channel for such a daemon.", that's a different channel than the scriptable one, because the latter would include stats, configuration etc.
A web server has a channel to do "GET / HTTP/1.0", but that's not the same as a chanel allowing you to e.g. "print current connected IPs", "reload X configuration file", etc.
>Current working directory? ROTFL. The whole point of GUI is to hide this concept, and you tell me one can learn it from GUI?
No, the whole point of the GUI is to give a graphic representation of those concepts, not to hide them. It hides absolutely nothing (except things that don't make sense in a GUI, like the CLI hides stuff that don't make sense in a terminal, eg. the graphical representation of an jpg file, which a GUI can immediately show in its listing).
In fact one can trivially create a restricted "ls" style program that shows (on the cli) far less info than what the Finder or Windows Explorer does.
You seem to conflate the CLI with the "canonical representation" of what actually happens in the OS/FS etc. But it's just a textual representation of it, nothing more.
What actually happens is a series of process starts, method calls, and system calls.
Whether you say it by printing stuff out (like early computers), in a cli (like UNIX systems), in a GUI, or even in VR or "PC-to-brain interface" in the future, it's the same underlying thing.
>Sorry to break your little utopia apart, but "most smartphones" run Linux or generally work with hierarchic filesystems, which is totally opposite of "no current working directory".
That's totally irrelevant to what I wrote.
My point is about those platforms not having a CLI as a user accessible object -- but only providing a GUI representation -- and users getting by just fine with that. Including the vast majority of OS X and Windows users who don't venture into the terminal at all.
>And that's why I don't insist to use them or even learn them. What I insist is to learn how the compiler is called
Again, you conflate the cli interface to the compiler to some canonical way about how "the compiler is called".
The compiler is called in many ways.
The cli is one, it's programmatic interface is another.
In fact both the gui window "run compiler with X, Y, Z options" and the cli command command "gcc -X -Y -Z" in the end just end at the same function, that starts the actual process.
> It can be really trivial through, which is the point.
No, it will not be trivial. It can be easy to use, but not trivial. Whenever you hit GUI, all the mechanics (i.e. internals) suddenly becomes complex. What the heck are "OSA dictionaries", what data is inside them, what remembers them and how does changing them from outside of the original process work?
> That said, sure, CLI programs give scriptability for free.
> But that stops when you need long-running session scriptability [...]
Command line tools rarely are long-running things you need to interact with.
>> This is part of the operating system's concepts a student needs to learn anyway.
> No, it's not.
How so? Suddenly one doesn't need to understand what the current working directory is? How to work with files then? Of course it is necessary to know those concepts. It's just that GUI hides a lot of them, so dropping to more basic tools hurts so much because of all complexity that was hidden springs suddenly.
> But as long as you drop them to cli for compiling etc, they also need to learn shell and other such stuff. An IDE would have handled all that for them.
But then they need to learn much about their IDE, which is as large area as basic proficiency with command line, except that knowledge can't be easily composed with anything other, and once they leave the IDE, the knowledge becomes next to useless.
The only thing that could be seen as benefit is when the student learns what icon to click when, without understanding what is done behind the scenes, but then you easily can have the same effect in command line.