3 ms·
1. "can't handle" !== "can't handle when presented with for the first time with no prior programming experience". It's like saying someone shouldn't pursue a ma
by franga2000 5y ago
1. "can't handle" !== "can't handle when presented with for the first time with no prior programming experience". It's like saying someone shouldn't pursue a math degree because you gave them a differential equation to solve first day of high school and they didn't know what to do.
2. You're mixing "low-level tools" and "ancient user interfaces". An argument could be made that a student should understand low-level tools, just like a mechanical engineer should understand physics. But there is absolutely no argument to be made for using old-school UIs the same way there's no reason for an engineer to use compasses and rulers instead of CAD. Actually, even that makes more sense, because there might be situations where they won't hve anything else, like in the field. There is no situation where the average programmer would only have access to CLIs.
3. CompSci !== SWE. A CS student developing novel learning-based image processing methods has no need for knowledge of obscure gdb commands and C++'s pointer and dependency voodoo. A SWE student could benefit from that knowledge, but even then, will rarely need more than a surface understanding of it when not actually developing using those tools.
- yeputons 5y ago> There is no situation where the average programmer would only have access to CLIs. It was fairly typical for me to have SSH-only access to the production/staging server and no other tools than Vim/git to alter/store its configuration.
- franga2000 5y agoIf you have SSH, you probably have SFTP, so just mount it locally and work with your local tools. If you somehow don't have SFTP, FISH works on a bare SSH connection. Many modern tools also have native support for remote filesystems (vscode, anything from JetBrains...). Not to mention you probably shouldn't be doing that directly in the first place, especially as "just" a programmer. Sysadmins need to deal with CLI stuff, but programmers generally have no reason to. Of course many of us have both of these roles, but that's beside the point. As programmers, we should not even need to see the production server and as sysadmins, we shouldn't need to know things like gdb and proper development in CLI editors. We have the tools, we just don't use them. How many issues from bad edits in remote scripts could've been prevented if we used an IDE with linting via sftp instead of barebones vim?
- yeputons 5y ago> If you have SSH, you probably have SFTP Absolutely not always. The SSH may be provided through multiple proxies by a mess of convoluted Bash scripts. Because reasons or compliance or whatnot. > Not to mention you probably shouldn't be doing that directly in the first place, especially as "just" a programmer. Yeah, if you have a dedicated sysadmin to start with, and not just a team of five-ten-fifty enthusiasts who are fully comfortable with managing servers themselves. > How many issues from bad edits in remote scripts could've been prevented if we used an IDE with linting via sftp instead of barebones vim? Yeah, that would be wonderful.
- cerved 5y agoI like Vim. I like CLI. I like JetBrains IDEs. I use whichever tool I deem appropriate for the situation. Mastering vim/git/cli has been the most productive thing I've learnt as a software engineer. It's something I would recommend. Not to freshman student but at some point
- locuscoeruleus 5y ago> A CS student developing novel learning-based image processing methods has no need for knowledge of obscure gdb commands and C++'s pointer and dependency voodoo. I guess you could argue that AlexNet was the product of one very motivated CS student who was very proefficient with C++ and CUDA. This particular skill set had a very deep impact on the computer vision community. Today, how ever, you don't need it because all that has been abstracted away. But someone had to lead the way.
- franga2000 5y agoDefinitely! I'd say we need more people like that (although for obvious security reasons, I'd personally prefer the use a safer lang than C/C++). But we also different people who don't care about performance or integration, but have unique ideas that are worth exploring. Let them experiment and quickly iterate using the easiest most high-level tools we have, then let the GPU magicians rewrite and optimize their work for production. The best progress happens when you have both of these groups, not just one. As well as some application development plebs like myself (jk) to allow end users to benefit from all of that progress.