Michael J Jackson <mailto:[email protected]>
September 23, 2014 at 6:21 AM
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
--
C. Titus Brown <mailto:[email protected]>
September 20, 2014 at 6:45 AM
On Fri, Sep 19, 2014 at 07:53:29PM -0700, W. Trevor King wrote:
On Fri, Sep 19, 2014 at 05:02:41PM -0700, Bill Mills wrote:
An interesting question is coming into focus here - are we trying to
teach best practices *within a toolset* (so we fork and teach excel
and VBA separately from R), or are we doing advocacy to funnel our
students towards the tools that most promote best practice (so we
continue to teach both and contrast the two)?
Software Carpentry has _always_ been about teaching best practices using a
particular toolset, and I still agree strongly with that approach (even though
we've expanded to ungodly languages like R ;). To do otherwise is to
dilute the materials and make something that is already quite hard into
something that is nearly impossible - organizing a practical teaching
community is hard enough as it is without spreading ourselves even thinner.
I think it's not a question of advocacy as much as a question of
advertising. The student likely would not have been angry (or signed
up at all) if the pitch for the workshop read:
Maybe. Haters gonna hate.
There are always people that don't respect the instructors enough to give them
the benefit of the doubt; I've only had one or two incidents like this over the
years (but, note, I'm a self-confident and well-practiced white professor, so
people tend not to yell at me) and I do my best to head them off at the pass by
stressing an accepting and non- proselytizing attitude up front, but at some
point mutual respect needs to be where we *start*, and that requires the
students as well.
Do we have lots of evidence that this is a systemic Software Carpentry problem,
or are we tackling problems simply for the sake of problem solving?
best,
--titus
W. Trevor King <mailto:[email protected]>
September 19, 2014 at 10:53 PM
I think it's not a question of advocacy as much as a question of
advertising. The student likely would not have been angry (or signed
up at all) if the pitch for the workshop read:
"Learn how to use R and join the open-statistics revolution. We'll
go over enough Excel so we can extract your data, and then talk
about regressions and plots while introducing you to modular,
test-backed, version-controlled development."
A less scripted alternative is to just describe the instructors' own
workflows and their benefits along with an install guide, and let the
students decide what they want to cherry-pick from that [1,2,3]. If
anyone has a pool of students interested in an approach like this, I'd
love to give this approach a spin...
Cheers,
Trevor
[1]: https://github.com/swcarpentry/site/pull/465#issuecomment-40879584
[2]:
http://lists.software-carpentry.org/pipermail/discuss_lists.software-carpentry.org/2014-June/001792.html
[3]:
http://lists.software-carpentry.org/pipermail/discuss_lists.software-carpentry.org/2014-August/001986.html
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
Bill Mills <mailto:[email protected]>
September 19, 2014 at 8:02 PM
An interesting question is coming into focus here - are we trying to
teach best practices *within a toolset* (so we fork and teach excel
and VBA separately from R), or are we doing advocacy to funnel our
students towards the tools that most promote best practice (so we
continue to teach both and contrast the two)?
I think either is a valid option, and we should discuss more as a
community what we want, what we can do, and how we can do it well.
Joon makes a good point on the side of advocacy; the risk there is
always that we will alienate people by being too heavy-handed, as was
the case with the student in the original story, and we need to think
about how to perform that advocacy, if that is indeed the path we
choose, without condescending to students' current practice.
I think Josh's story about the professor who successfully participated
in the python workshop, but just didn't see the value, contains a key
lesson. The level of proficiency achieved at the end of one bootcamp
isn't enough to make the benefits of a scripting language totally
self-evident. As I think Ivan rightly points out, we've 'won' when we
go the extra mile to illustrate the value of the workflow we promote
in a convincing way - and when we do, its virtues stand on their own,
no trash talk for excel or anything else required.
But, to Trevor's and other's point about deeply entrenched familiarity
with excel - you're right, there is a limit to advocacy's reach. Is
there a way we can reach both audiences? What if day 1 was 'best
practices in excel', a genuine investment in doing the best science
possible with this tool, and day 2 was 'the power of scripting', where
we focused on illustrating the value proposition Ivan et al mention?
That way, excel die-hards get a lesson that respects their decision
and that they can use, and people who are willing to consider
something different have a space to explore that, too.
As always, structural prescriptions like this are highly case
dependent. But this could be one framing that has something for
everyone, when speaking to an excel-heavy audience.
On 2014-09-19 4:40 PM, Ivan Gonzalez wrote:
--
Bill Mills
Community Manager, Mozilla Science Lab
@billdoesphysics
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
Ivan Gonzalez <mailto:[email protected]>
September 19, 2014 at 7:40 PM
Hi,
I've recently attended a workshop for data journalists and Excel is
basically what they use: they learn it at journalism schools. This is
funny when you think about it: Excel has established as the must-have
tool in the field, despite of its obvious drawbacks. In my opinion,
the main reason is the argument "I'm not a geek/math person, so I
cannot program at all, but I can use Excel, because everybody can use
Excel". How the instructor approaches this issue is very important, as
a fraction of the people in our workshops are trying to overcome this
barrier, are feeling insecure and intimidated and happy to jump back
to their comfort zones.
The second thing I would say is that more than teaching them a new
tool (say R to ditch Excel), we're teaching them a new way of working:
automate things that you repeat often, have your files under (version)
control, and collaborate easily with your colleagues. I believe that
this is why version control is the most popular class. People don't
have preconceptions about it and solves an obvious problem for them. I
totally agree with Dan and think that when we organize the workshop
around this theme, stressing the connections between lessons and doing
a capstone exercise that puts all together, they see the advantages by
themselves (and I'd say we won).
Best,
Ivan
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
