8 ms·

Not to mention, when learning programming there's absolutely no reason to introduce the command line. Set them up with an IDE and GUI for source control. You ca

by initram 10y ago

Not to mention, when learning programming there's absolutely no reason to introduce the command line. Set them up with an IDE and GUI for source control. You can still use llvm or gcc and git or svn behind the scenes, but 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." I think Apple's new playgrounds and the stuff they showed for kids at WWDC is the future, personally.

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
wfo 10y ago
Except that IDEs and GUIs are buggy. They are finicky and they fail often and usually their failure can only be debugged by someone who understands what is actually going on, i.e. the command line and build process. Consider teaching a CS class. Everyone has a different machine, of a different age, with a different operating system. Getting all of them on some posix type CLI where you can type 'make' or 'python' is fairly easy and once it's working, foolproof. Want to teach two languages? Great! Install two entirely different IDEs, teach each one all over again and their differences, or spend hours debugging weird compiler plugin errors every single one of your students will have. Or in 3 seconds tell them to type 'python' instead of 'gcc' once they already understand what programming actually is. In general I always think it's important to understand what's actually going on before you use fancy tools that automate it for you. Because when your fancy tools break because of some tiny misconfiguration or change you didn't notice, and they will, throwing your hands up and saying "welp, I guess I'm helpless" isn't good enough and you'll never be half decent, or have any kind of real confidence in your ability until you have at least some knowledge of what's going on under the hood. If someone wants to be a programmer, we are teaching them to be car mechanics, not car drivers. So why not start with the real stuff? And if someone can't get over their fear of communicating with the computer using words and symbols (i.e. text) instead of point-and-click then they aren't ever going to be a programmer -- better to know and pass that hurdle early rather than later.
- coldtea 10y ago
  >Except that IDEs and GUIs are buggy. They are finicky and they fail often and usually their failure can only be debugged by someone who understands what is actually going on, i.e. the command line and build process. People having been coding years on end on modern IDEs like IntelliJ and Eclipse and VS without them "failing" for basic stuff. And it's not like setting up e.g. Vim or whatever with just some of the niceties an IDE has not challenging. >Consider teaching a CS class. Everyone has a different machine, of a different age, with a different operating system. Getting all of them on some posix type CLI where you can type 'make' or 'python' is fairly easy and once it's working, foolproof. You'd be surprised. Try getting them to run Python on Windows and discover all the subtle changes, libs that only play on Linux etc, use the same Unix userland with slight OS X/Linux changes, run that terminal stuff on Windows etc. Besides, tons of programming teaches classes, seminars, etc use or recommend an IDE.
ontouchstart 10y ago
Playground is just another form of REPL. For example, here are two forms of of the same exercise, the firt one running on iPad, the second in Docker/Linux: 1. https://github.com/ontouchstart/swift3-playground/blob/39331a9e2ef115bc248daf1eba1db22bcd1896d0/playground2book/001/README.md https://github.com/ontouchstart/swift3-playground/blob/39331... 2. https://github.com/thinkswift/TS/blob/296775627b19c4d98eb7fdc19211a90d8e56ee95/001.md https://github.com/thinkswift/TS/blob/296775627b19c4d98eb7fd... My point is that there is a difference between mastering the toolchains and understanding the deep concepts. I totally agree that we have to start from somewhere concrete, quote Seymour Papart: "you cannot think about thinking without thinking about thinking about something". However, we should also "focus on the big picture and zero in on the powerful ideas ..." - http://news.mit.edu/2016/seymour-papert-pioneer-of-constructionist-learning-dies-0801 http://news.mit.edu/2016/seymour-papert-pioneer-of-construct...

by initram 10y ago

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

wfo 10y ago

Except that IDEs and GUIs are buggy. They are finicky and they fail often and usually their failure can only be debugged by someone who understands what is actually going on, i.e. the command line and build process. Consider teaching a CS class. Everyone has a different machine, of a different age, with a different operating system. Getting all of them on some posix type CLI where you can type 'make' or 'python' is fairly easy and once it's working, foolproof. Want to teach two languages? Great! Install two entirely different IDEs, teach each one all over again and their differences, or spend hours debugging weird compiler plugin errors every single one of your students will have. Or in 3 seconds tell them to type 'python' instead of 'gcc' once they already understand what programming actually is. In general I always think it's important to understand what's actually going on before you use fancy tools that automate it for you. Because when your fancy tools break because of some tiny misconfiguration or change you didn't notice, and they will, throwing your hands up and saying "welp, I guess I'm helpless" isn't good enough and you'll never be half decent, or have any kind of real confidence in your ability until you have at least some knowledge of what's going on under the hood. If someone wants to be a programmer, we are teaching them to be car mechanics, not car drivers. So why not start with the real stuff? And if someone can't get over their fear of communicating with the computer using words and symbols (i.e. text) instead of point-and-click then they aren't ever going to be a programmer -- better to know and pass that hurdle early rather than later.

coldtea 10y ago
>Except that IDEs and GUIs are buggy. They are finicky and they fail often and usually their failure can only be debugged by someone who understands what is actually going on, i.e. the command line and build process. People having been coding years on end on modern IDEs like IntelliJ and Eclipse and VS without them "failing" for basic stuff. And it's not like setting up e.g. Vim or whatever with just some of the niceties an IDE has not challenging. >Consider teaching a CS class. Everyone has a different machine, of a different age, with a different operating system. Getting all of them on some posix type CLI where you can type 'make' or 'python' is fairly easy and once it's working, foolproof. You'd be surprised. Try getting them to run Python on Windows and discover all the subtle changes, libs that only play on Linux etc, use the same Unix userland with slight OS X/Linux changes, run that terminal stuff on Windows etc. Besides, tons of programming teaches classes, seminars, etc use or recommend an IDE.

ontouchstart 10y ago

Playground is just another form of REPL. For example, here are two forms of of the same exercise, the firt one running on iPad, the second in Docker/Linux: 1. https://github.com/ontouchstart/swift3-playground/blob/39331a9e2ef115bc248daf1eba1db22bcd1896d0/playground2book/001/README.md https://github.com/ontouchstart/swift3-playground/blob/39331... 2. https://github.com/thinkswift/TS/blob/296775627b19c4d98eb7fdc19211a90d8e56ee95/001.md https://github.com/thinkswift/TS/blob/296775627b19c4d98eb7fd... My point is that there is a difference between mastering the toolchains and understanding the deep concepts. I totally agree that we have to start from somewhere concrete, quote Seymour Papart: "you cannot think about thinking without thinking about thinking about something". However, we should also "focus on the big picture and zero in on the powerful ideas ..." - http://news.mit.edu/2016/seymour-papert-pioneer-of-constructionist-learning-dies-0801 http://news.mit.edu/2016/seymour-papert-pioneer-of-construct...