> Most importantly, though, it limits the ability of their peers to learn. If a 300-level software engineering class which budgeted a week to teach basic version control skills has to take a two-day detour to teach the Windows users how to get rid of the CRLFs in their commits, and teach the Mac users to remove the .DS_Store files from their repositories, and get everyone set up in Eclipse EGIT, that’s wasted time. If the professor has to schedule time with students outside of class to demonstrate their code because so many students aren’t able to submit their code in a form that successfully runs on the professor’s computer, that’s wasted time for both professors and students, and it undermines important lessons about portability and good practices.
This is might be an argument against a particular IDE setup for a class, but it isn't an argument against IDEs in general. Instead it is an argument for providing a config file to make these problems go away.
> 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.
The article doesn't support the case that an intro class using an IDE prevents students from learning anything else. The class doesn't set people back--it merely fails to move them forward in that way. I agree that it is important to teach this eventually. But it should be through teaching it deliberately. (EDIT: Someone else posted a link to a class which compares different languages and their tooling side-by-side. That sounds fantastic.)
I have yet to see a class which can do a good job of teaching how package management works to a degree that the student can then confidently debug weird setuptools errors.
I've been looking for such a class since 2009.