4 ms·

> 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. > [...]with "dictionaries

by dozzie 10y ago

> 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. > [...]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.

coldtea 10y ago
>There you go. The mechanics of how this works is non-trivial. I would say it seems quite complex at this point. 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.

by dozzie 10y ago

coldtea 10y ago

>There you go. The mechanics of how this works is non-trivial. I would say it seems quite complex at this point. 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.