6 ms·

> when learning programming there's absolutely no reason to introduce the command line You don't start learning woodworking with pantarouter or a lathe. Comma

by dozzie 10y ago

> when learning programming there's absolutely no reason to introduce the command line You don't start learning woodworking with pantarouter or a lathe. Command line (compiler or interpreter) is something that works everywhere and always, and understanding how the environment works prevents the student from thinking magically through clicking buttons in IDE. > it's absolutely absurd to say, "Well before you can start learning to program, you have to learn these several other domain specific languages and you have to type them, and it has to look awful." Why do you think `gcc myprogram.c' + `./a.out' or `gcc -o myprogram myprogram.c' + `./myprogram' is "several other domain specific languages"? Because, you know, it's all that is really necessary to start learning C. I don't see learning even a small part of a DSL (shell, I presume) here.

coldtea 10y ago
>Command line (compiler or interpreter) is something that works everywhere and always, and understanding how the environment works prevents the student from thinking magically through clicking buttons in IDE. Clicking a button in the IDE is not any different than writing: "foo -x". They both end up as code being executed. And no, it's not always the case that an IDE's button click ends up in some cli command being executed in the background. There are such things as programmatic APIs to compilers, linters and such. So nothing more fundamental or magical about the CLI -- it's just another, text vs graphics, based representation. >Because, you know, it's all that is really necessary to start learning C. I don't see learning even a small part of a DSL (shell, I presume) here. And where you'd run that command? Wont you "cd" there? Maybe create some directories? Maybe delete some files you don't need? That's shell for you. And what about build scripts, including libs, etc? An IDE can create those for you automatically, with the plain cli you need to learn to write e.g. a makefile. And tons of other things besides. You want a debugger? gdb and then learn the flags to attach it, several commands to step around and inspect things, etc.
- traverseda 10y ago
  >Clicking a button in the IDE is not any different than writing: "foo -x". You can't automate clicking buttons nearly as easy as you can munging text streams.
  - coldtea 10y ago
    That's just an accident of neglect though, not something inherent in GUIs. Many GUI apps have some embedded scripting capability (for extensions, batch processing, etc). The same could be generalized to use and combine not just one through it's special language, but all of them from outside. That's e.g. what Apple's OSA dictionaries do enabling you to script GUI apps (if its developers bothered to expose its commands as programmatic APIs). And if Windows and OSX and Linux devs talked between them, the same commands could work in all platforms for the same app. You could also use something like a visual pipeline (as in Automator) to combine functions and move results between arbitrary apps (think "GUI pipes"), do the whole scripting from the CLI in some scripting language, send messages to the app (a la Rest), etc. This is also true for web apps of course -- they're GUI based (e.g. Gmail, Mailchip) but lots have programmatic interfaces, via REST and co.
    - dozzie 10y ago
      > That's just an accident of neglect though, not something inherent in GUIs. Of course it is inherent. You need to actively fight it if you want it gone (i.e., if you want GUI scriptability). For shell, you automatically have the scripting capability.
      - coldtea 10y ago
        Yeah, it's not a lowest common denominator scriptability option that's offered as default as is the case with CLI commands and flags -- it takes actual effort and thinking.
        dozzie 10y ago
        And there you have the reason why so little programs with GUI allow for scripting.
- 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.

by dozzie 10y ago

coldtea 10y ago

>Command line (compiler or interpreter) is something that works everywhere and always, and understanding how the environment works prevents the student from thinking magically through clicking buttons in IDE. Clicking a button in the IDE is not any different than writing: "foo -x". They both end up as code being executed. And no, it's not always the case that an IDE's button click ends up in some cli command being executed in the background. There are such things as programmatic APIs to compilers, linters and such. So nothing more fundamental or magical about the CLI -- it's just another, text vs graphics, based representation. >Because, you know, it's all that is really necessary to start learning C. I don't see learning even a small part of a DSL (shell, I presume) here. And where you'd run that command? Wont you "cd" there? Maybe create some directories? Maybe delete some files you don't need? That's shell for you. And what about build scripts, including libs, etc? An IDE can create those for you automatically, with the plain cli you need to learn to write e.g. a makefile. And tons of other things besides. You want a debugger? gdb and then learn the flags to attach it, several commands to step around and inspect things, etc.

traverseda 10y ago
>Clicking a button in the IDE is not any different than writing: "foo -x". You can't automate clicking buttons nearly as easy as you can munging text streams.
- coldtea 10y ago
  That's just an accident of neglect though, not something inherent in GUIs. Many GUI apps have some embedded scripting capability (for extensions, batch processing, etc). The same could be generalized to use and combine not just one through it's special language, but all of them from outside. That's e.g. what Apple's OSA dictionaries do enabling you to script GUI apps (if its developers bothered to expose its commands as programmatic APIs). And if Windows and OSX and Linux devs talked between them, the same commands could work in all platforms for the same app. You could also use something like a visual pipeline (as in Automator) to combine functions and move results between arbitrary apps (think "GUI pipes"), do the whole scripting from the CLI in some scripting language, send messages to the app (a la Rest), etc. This is also true for web apps of course -- they're GUI based (e.g. Gmail, Mailchip) but lots have programmatic interfaces, via REST and co.
  - dozzie 10y ago
    > That's just an accident of neglect though, not something inherent in GUIs. Of course it is inherent. You need to actively fight it if you want it gone (i.e., if you want GUI scriptability). For shell, you automatically have the scripting capability.
    - coldtea 10y ago
      Yeah, it's not a lowest common denominator scriptability option that's offered as default as is the case with CLI commands and flags -- it takes actual effort and thinking.
      - dozzie 10y ago
        And there you have the reason why so little programs with GUI allow for scripting.
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.