3 ms·

> Clicking a button in the IDE is not any different than writing: "foo -x". Oh, far from it. You said yourself later down the thread that IDE needs to anticipa

by dozzie 10y ago

> Clicking a button in the IDE is not any different than writing: "foo -x". 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. `foo -x' only needs to have this `-x' provided somehow, and it doesn't care where it came from and how it was derived. Command line does much, much simpler job of exposing underlying concepts of an operating system. The two hard parts about the command line are learning those concepts and learning that most of the time, most of the options are optional and can be omitted. For GUI, many of the OS concepts are hidden, intentionally or incidentally, but they are still going to bite if one doesn't know them. > And where you'd run that command? Wont you "cd" there? This is part of the operating system's concepts a student needs to learn anyway. A working directory is still a necessary thing, except with GUI you have no fsckin' idea where your program is executed, so good luck opening any file (unless you use absolute path, of course). > Maybe create some directories? Maybe delete some files you don't need? That's shell for you. Oh, so you have just vanished file managers so many people use? Those suddenly stopped working for somebody who happened to started learning programming? Why do you think a student needs to manage his files with shell once he starts writing programs, instead of doing things as he always did, in GUI?

coldtea 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. Defining OSA dictionaries, for example, was never something that took major effort. The fact that people don't care about those enough to make it a standard feature in GUI frameworks is a cultural thing, not a technological limitation inherent in the API. That said, sure, CLI programs give scriptability for free. But that stops when you need long-running session scriptability -- there you essentially have to pass messages to an already running cli program, and that's done the same way as you would have handled passing messages to a GUI program. That's true whether you do it with a "telnet to the program" like interface, a "client" interactive style like e.g. psql, or even low level POSIX signals (which require a handler out of the program flow). >This is part of the operating system's concepts a student needs to learn anyway. No, it's not. First, not all people studying a programming language are or care to be CS majors. A student could just use the GUI file manager for an eternity... 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.
- 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.

by dozzie 10y ago

coldtea 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. Defining OSA dictionaries, for example, was never something that took major effort. The fact that people don't care about those enough to make it a standard feature in GUI frameworks is a cultural thing, not a technological limitation inherent in the API. That said, sure, CLI programs give scriptability for free. But that stops when you need long-running session scriptability -- there you essentially have to pass messages to an already running cli program, and that's done the same way as you would have handled passing messages to a GUI program. That's true whether you do it with a "telnet to the program" like interface, a "client" interactive style like e.g. psql, or even low level POSIX signals (which require a handler out of the program flow). >This is part of the operating system's concepts a student needs to learn anyway. No, it's not. First, not all people studying a programming language are or care to be CS majors. A student could just use the GUI file manager for an eternity... 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.

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.