> First, in a Java-focused curriculum, it insulates the student from the javac command line program, and the command line environment itself.
I take exception to this line of thinking. Students should not be using the command line for programming. I believe that forcing students to learn to use command line tools is the reason why so much software has such horrible user experience. They learn that users don't matter unless they've steeped themselves in the arcana of each particular program and have practically become programmers themselves.
> Second, it catches some basic mistakes and allows the student to defer learning about the finnicky language requirements that aren’t deemed core to the curriculum, like imports and file naming requirements.
I had the exact opposite experience. At university, they sat us down at a Unix shell with almost no instruction on the shell or the compiler. We spent so much time learning the finicky shell requirements (and which we had no clear understanding were part of the shell and not the compiler itself or something else), that we were sidelined from understanding what the compiler was telling us or how it worked. You'd run your program and if it gave you an error 11, well, you just read and re-read it until you noticed something off.
Nowadays with an IDE and a static analyzer, it can show my code and show the exact path of execution that will lead to an invalid memory access before I've even run it. Students can learn to find problems themselves because it's laid out right in front of their eyes in relatively-understandable java or C or whatever language they're programming in. They don't need to worry about, "Oh when I compile on this machine, I have to specify the -I argument to the compiler for includes, but on machines I actually use in real life, I don't have to specify anything because it finds all the files I'm actually using because I put them into the IDE myself and can see their relationships."
> it’s crucial to introduce these inconvenient details eventually.
Why? If I'm going to be downloading my IDE from the Internet or an App Store why the heck should I ever learn fiddly Unix commands? I'm writing GUI-based applications. I don't need to understand any of that crap if I don't want to. It's like saying you can't be a taxi driver if you don't understand how the carburetor works. Really? My job is to drive the car around, not to fix it. I know a good mechanic who can do that if the need arises. If they want to learn it, then all the better, but it shouldn't be a requirement.
> What they can’t do, unless they’ve figured it out on their own, is operate a computer outside of the confines of the IDE they’ve been taught.
On the contrary, I had no problem operating the GUI-based computers of my day. It was the bizarre, often contradictory commands in the Unix shell that baffled me. Their names were often stupid puns, their "help" pages did no such thing, and I wasted years learning a bunch of stuff that ended up not being very helpful in the real world.
> When students have only ever programmed in Java using some bespoke learning library provided by their professor, it will take them much longer than necessary to figure out other languages, other libraries, and other approaches.
That has nothing to do with IDEs. That has to do with a deficient teaching environment, and is the exact same problem I described above, which sounds like what the author is advocating.
> Teaching someone to use git is very difficult if they’ve never been taught that a file is an logical unit composed of bytes and metadata.
No, teaching someone to use git is very difficult because it was designed to be difficult because the self-absorbed creator thinks that people should have to suffer to become good programmers. It's just sadistic.
> Students need to know how to use computers before they can program them in a serious way.
I agree, and what the author is proposing sounds like the opposite of that to me.
> After the first foray into programming, take time to teach students about the UNIX command line.
Ugh. I disagree strongly with this sentiment. CS students need to get away from the mentality that Unix is the be-all-end-all of operating systems and programming environments and the quicker that happens the better in my opinion.
I take exception to this line of thinking. Students should not be using the command line for programming. I believe that forcing students to learn to use command line tools is the reason why so much software has such horrible user experience. They learn that users don't matter unless they've steeped themselves in the arcana of each particular program and have practically become programmers themselves.
> Second, it catches some basic mistakes and allows the student to defer learning about the finnicky language requirements that aren’t deemed core to the curriculum, like imports and file naming requirements.
I had the exact opposite experience. At university, they sat us down at a Unix shell with almost no instruction on the shell or the compiler. We spent so much time learning the finicky shell requirements (and which we had no clear understanding were part of the shell and not the compiler itself or something else), that we were sidelined from understanding what the compiler was telling us or how it worked. You'd run your program and if it gave you an error 11, well, you just read and re-read it until you noticed something off.
Nowadays with an IDE and a static analyzer, it can show my code and show the exact path of execution that will lead to an invalid memory access before I've even run it. Students can learn to find problems themselves because it's laid out right in front of their eyes in relatively-understandable java or C or whatever language they're programming in. They don't need to worry about, "Oh when I compile on this machine, I have to specify the -I argument to the compiler for includes, but on machines I actually use in real life, I don't have to specify anything because it finds all the files I'm actually using because I put them into the IDE myself and can see their relationships."
> it’s crucial to introduce these inconvenient details eventually.
Why? If I'm going to be downloading my IDE from the Internet or an App Store why the heck should I ever learn fiddly Unix commands? I'm writing GUI-based applications. I don't need to understand any of that crap if I don't want to. It's like saying you can't be a taxi driver if you don't understand how the carburetor works. Really? My job is to drive the car around, not to fix it. I know a good mechanic who can do that if the need arises. If they want to learn it, then all the better, but it shouldn't be a requirement.
> What they can’t do, unless they’ve figured it out on their own, is operate a computer outside of the confines of the IDE they’ve been taught.
On the contrary, I had no problem operating the GUI-based computers of my day. It was the bizarre, often contradictory commands in the Unix shell that baffled me. Their names were often stupid puns, their "help" pages did no such thing, and I wasted years learning a bunch of stuff that ended up not being very helpful in the real world.
> When students have only ever programmed in Java using some bespoke learning library provided by their professor, it will take them much longer than necessary to figure out other languages, other libraries, and other approaches.
That has nothing to do with IDEs. That has to do with a deficient teaching environment, and is the exact same problem I described above, which sounds like what the author is advocating.
> Teaching someone to use git is very difficult if they’ve never been taught that a file is an logical unit composed of bytes and metadata.
No, teaching someone to use git is very difficult because it was designed to be difficult because the self-absorbed creator thinks that people should have to suffer to become good programmers. It's just sadistic.
> Students need to know how to use computers before they can program them in a serious way.
I agree, and what the author is proposing sounds like the opposite of that to me.
> After the first foray into programming, take time to teach students about the UNIX command line.
Ugh. I disagree strongly with this sentiment. CS students need to get away from the mentality that Unix is the be-all-end-all of operating systems and programming environments and the quicker that happens the better in my opinion.