Hi Everyone, I just want to echo what Matt and Titus have said - SWC has never been about advocating a language, it is about giving scientists the tools to do their work in a more efficient manner. In an ideal world, we could present everyone these tools in the language they are already familiar with (as long as it lends itself to reproducibility and automation), however, this would significantly increase the work required to create and maintain our materials and divide our instructors. My understanding of why Python was chosen is that it is easy to learn in a short period of time. The syntax is pretty close to english and the formatting is such that it is easy to parse. This allows us to teach our audience in a single language with which we can communicate the reproducibility and automation we really want to teach. Also, as Greg mentions in his Scipy talk - no one will spend 2 days learning reproducibility, but many people will spend 2 days learning Python - so we can sneak it in our real mission under the guise of something they will sign up for. I believe that the lesson development in other languages, such as R, has been driven by the prevalence of those languages in different fields and instructors who would like to teach in the language that they use for their work (please correct me if I’m wrong here). That being said, many of us do prefer R and Python and I think our conversations with our class should focus on why we believe the tools we are teaching them are worth learning? If the skills we are teaching in Python can be applied to VBA macros - awesome. By teaching students these tools, they can use them in their native language. If the skills cannot be applied, then hopefully students will move towards another language.
To consider: should we mention the short-comings of commonly used languages that we would like students to stop using or just focus on the tools we are teaching and hope they see those on their own. Finally, in terms of advertising what we plan to teach. I think we are very straight forward with what we plan to teach. The biggest complaint I see is students who thought the class was too easy or too hard (usually a few of both). -Azalee On Sep 21, 2014, at 8:14 AM, W. Trevor King <[email protected]> wrote: > On Sun, Sep 21, 2014 at 12:04:12AM -0400, Marianne Corvellec wrote: >> Plus, I concur with Titus that it wouldn't be manageable to >> add/include/append to the SWC materials any and every other tool >> that might be used out there. > > I certainly focus *my* efforts on the Shell/Git/Python side of our > standard lessons, because I don't know, or really care, about > R/Mercurial/…. Does that mean I think the folks who are working on > those lessons are wasting their time and should be contributing to the > lessons for my tools? No. There's a niche for just about every too > (although I think Python has a bigger niche than, say, Matlab ;). > Will explain to the curious why I use the tools I do? Absolutely. > Will I treat them as second-class citizens if they want to teach/learn > other tools? No [1]. > >> We want to focus our efforts indeed; for instance, I can't imagine >> how instructor training would remain consistent and manageable, if >> we don't have a somewhat standard, small enough curriculum/toolset. > > As I understand it, instructor training is mostly about pedagogy. For > example: > > $ git log -p -G 'git ' origin/master..origin/pr/703 > > shows no mention of a Git command in the current version of the > instructor course (see also [2]). The best-practices paper doesn't > force a particular toolset [3,4,5,6], so and I think that pitching > that big tent is important. For example [6]: > > “Many good VCSes are open source and freely available…. As with > coding style, the best one to use is almost always whatever your > colleagues are already using.” > > If instructors are already comfortable with some tool that fits the > bill, I'm happy letting them use that. I'm also happy pointing the > ones that *don't* come in with tools in their box towards our > favorites, and helping bring them up to speed there. If a diversity > of tools makes it slightly harder to collaborate on lesson development > (and Git-vs-Mercurial is not going to make things that much > different), I think the costs are outweighed by the benefits of having > a larger pool of potential instructors and students. Porting the > lesson on modular, testable development from Python to Excel is not > something *I* know how to do, but I'm not going to stand in the way of > anyone who does want to do that. Anything that gets our > best-principles in front of students is going to make their science > better. > > Cheers, > Trevor > > [1]: The equal-standing for any tool is part of the reason I've been > pushing for isolated, per-lesson branches [7], because I don't want > folks working on lessons for some oddball tool to clutter > swcarpentry/bc, and (fair's fair) that means the core tools should > be in their own branches too. Then we don't even have to agree on > what's core. Greg can pull the stuff *he* thinks is core into > swcarpentry/bc (and we'll mostly use that assembly), but it's easy > for folks with different sets of core tool to collect their own > assembly. > [2]: > http://lists.software-carpentry.org/pipermail/discuss_lists.software-carpentry.org/2014-August/001958.html > [3]: > http://software-carpentry.org/blog/2012/10/best-practices-for-scientific-computing.html > [4]: http://arxiv.org/abs/1210.0530 > [5]: > http://software-carpentry.org/blog/2014/01/best-practices-has-been-published.html > [6]: > http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745 > [7]: https://github.com/swcarpentry/bc/issues/102 > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
