Quoting Azalee Bostroem <[email protected]> on Sun, 21 Sep 2014
10:12:29 -0700:
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.
This was my understanding also. A researcher working with 10000 lines
of legacy FORTRAN is not going to leap to Python but can take away
advice on comments, naming, indentation, modularity and see about
adopting tests using FRUIT or pfUnit. Similarly for Automation and Make,
those using Java are far more likely to use ANT, but the underlying
concepts are the same. Likewise for the other tools. If someone comes
away from a workshop wary of Git but decides to start using Subversion
then that's a success.
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
Same here. Flagging this up at the start ("like hillwalking the slowest
will set the pace of the group") might reduce these complaints (but then
again...)
cheers,
mike
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
--
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
