Should we teach find and grep before rm, mv, and cp?

[gvwilson]

@r-gaia-cs asked this question on the discussion list and sparked a lively back-and-forth - this issue is for people to continue that discussion.

[benwaugh]

The discussion on the list is now more about general issues of student motivation and whether we should be "selling" a particular way of doing things (Git over Dropbox, GUI vs shell) rather than specifically find and grep, so I'm assuming this is now the place for that discussion...

While I agree with Tim that the student, especially in an optional course, should take come with their own motivation for learning, and we should be giving them a lesson and not a sales pitch, I don't think that is the whole point of Software Carpentry. We don't just teach the basics of Git and Bash to students who already know they need them. A student may have enough curiosity to devote two days to a Software Carpentry workshop, but that doesn't mean they will automatically grasp the point of everything we teach, let alone use it afterwards.

I didn't start teaching Software Carpentry because people were queuing up asking me how to use Git. I started because the head of my research group wanted them to write better code. That means not just teaching them but persuading them they need to learn, including explaining what a VCS offers that Dropbox doesn't. The fact that now people do ask me how to use Git is a good sign I hope.

[iglpdc]

I'm really having problems to understand where the "sales pitch" idea is coming from. @r-gaia-cs suggested to switch the order of some of the topics to make the lesson more attractive. Maybe the change is not a good idea, but has nothing to do with a "sales pitch". More attractive lessons brings more attentive learners and better learning.

You have to understand that justifying why one should drop a nice, modern, maybe with a touch screen, GUI for a cryptic tool developed +50 years ago, requires some motivation. A good teaser, for example, is to create a few thousand (empty) files in a folder, half .doc, half .pdf, and list them using ls vs opening the folder in the GUI. (As the GUI has to draw the icons for each file, it takes forever.) Something similar could be done using find or grep in the Nelle's filesystem, which I think is closer to what @r-gaia-cs was suggesting.

In my opinion, the fact that people ask for Dropbox when learning Git, or GUIs when learning CLI, is, actually good. It means that the are confronting their (wrong) preconceptions about the topic with the new ideas introduced by the instructor, which is the only way to learn.

Finally, note that Software Carpentry lessons are not only used in our workshops (they're open source materials), so the course doesn't have to be "optional" or "free".

[gdevenyi]

I'm -1 on this idea. I think the easiest selling point for command-line processing is the "rename 10,000 files, according to some pattern" which relies just on the basic file management commands.

[ChristinaLK]

I'm w/ @gdevenyi. I do agree that we could add some more whiz-bang examples of the power of cp/mv - it would be great to add some exercises (not multiple choice questions, see my comment on #194) at the end of those first lessons that are both instructive + help reveal how powerful the tools are. I would also be tentatively open to the idea of an opening demo - however, if you haven't covered the basics, I wonder if it'll just look like magic to people and might be more intimidating than inspiring. On the fence there.

That said, I think that a) visualizing your filesystem and b) that you can run any command from anywhere on data/inputs that are anywhere are crucial concepts behind understanding/using the shell and those are conveyed best by the simpler file management commands. So those MUST be covered, and at the beginning. Also, I do think "finding things" falls less under the umbrella of "best practices / automation / reproducibility" that should be driving this lesson, which is why it remains at the end.

Something that I do when I teach shell, is about halfway through, have the learners split into 5-6 groups + have them each research a shell command I give them. Then they all report back to the group. (When I'm feeling very ambitious, I have them each give an example for me to type in at the command line.) That way they can see the breadth of what the shell can do, without spending lots of time actually "teaching" those skills - because that's something learners can hopefully do on their own, with the base given in the workshop. (That's also where I explicitly discuss man pages + using the internet.)

tl:dr maybe some better examples of cp/mv power, a demo, leave grep/find where it is as optional lesson "module". If folks would like to see my group exercise inserted into the lesson formally in some way, please add thoughts.

[jevbelikov]

I found find and grep very useful when navigating and trying to understand a legacy code base (could be a use case for justification). Mass renaming depends on loops being previously introduced. Overall I think for the benefit of learning the order should be from easier to more complicated and grep introduces regular expressions which students might find rather difficult to use.