2 ms·

>> Oh, far from it. You said yourself later down the thread that IDE needs to anticipate an interaction beside the mouse-click (by exposing some programming int

by dozzie 10y ago

>> Oh, far from it. You said yourself later down the thread that IDE needs to anticipate an interaction beside the mouse-click (by exposing some programming interface). It needs work to have that, and that is far from being trivial mechanics. > 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.

coldtea 10y ago
>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? 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.
- 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.

by dozzie 10y ago

coldtea 10y ago

>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? 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.

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.