3 ms·
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 actu
by 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.
- AstralStorm 10y agoHa, don't even get me stated on infallibility of modern IDEs. Forgot to index? 90% functionality is off or broken. Want more than one project open? Better have 10 GB memory on the ready. Oh, did someone customizer their key bindings? Or window manager, and the binding now collides? Ah wait, the integrated debugger has crashed again, so I cannot figure things out. Hey, the thing cannot even open a text data file, because it is not part of the project, whatever that means. Etc. Most "industrial" IDEs male quote a few simple things way unnecessarily complex.