Hi Matt,
I agree with that difference (IDE vs command line). During the initial
data exploration/visualization phase, it can be easier IME to have the
interactive IDE environment to prototype things in. My sense is that
many/most R users prefer to just work with their scripts interactively
(like your labmates). Once people get to the point where they're putting
together multi-script workflows, for example with make, then most people
tend to use R similarly to python (that is, writing scripts that take
input and create output).
I could be wrong on this, but it seems to me that the way python code is
written these days is different than it used to be (at least in the
context of scientific data analysis), largely because of IPython/Jupyter
(even without the notebook interface). The command-line inclination you
pointed out among python users might have to do with the legacy of how
python/perl/etc were often written before IPython came along. I'd be
interested to hear what long-time python users think of this shift (or
if I'm way off-base). I think python IDEs like Rodeo and PyCharm with an
IPython kernel (or even the notebook) are much closer to the RStudio way
of doing things than, for example, editing a script in your editor of
choice, saving the script, and then running it from the command line,
which is how I originally learned to write both perl and python.
In contrast to python, I don't think that coding in perl has changed
much, because there is no perl equivalent to IPython (as far as I
know?). Alternatively, that could just be because perl is so closely
related to sh/sed/awk and the 'shell' way of doing things, vs python
which is further from that set of syntax. Anyway, interesting to think
about how these things shift over time.
Also, there is indeed a SWC lesson on using R from the command line,
here:
http://swcarpentry.github.io/r-novice-inflammation/05-cmdline.html
Best,
Naupaka
On 3 Apr 2016, at 6:58, Matthew Gidden wrote:
Hi all,
Some additional observations from the R vs. Python world in my current
context:
I'm finding that there is another natural divide between primary users
of
each language, which deals with how they actually *use* the tools.
From my
experience, R users expect to be working in R studio (or a similar
IDE),
and while there are Python IDEs, etc., I find most Python users to be
*in
general* more familiar with the command line. I think this has a
direct
impact on how users perceive of the usefulness of each tool. I have
two
anecdotal examples. I recently made an R CLI to do a simple analysis;
however, I found that when I went to shop it around my research group,
no
one wanted to use it -- they'd rather a script or module that they
could
run directly in their IDE (that is, their workflow is: open IDE, open
file,
click run). Further, I learned recently that the dplyr package (very
popular in the R ecosystem) has specific functions for "programmatic"
use,
e.g., summarize_each() vs. summarize_each_(), again speaking to the
use of
the tools in a "hands-on" mode, rather than a "headless" mode.
With the use if IPython, we teach lessons for both languages in a very
IDE-friendly envrionment, but I have always provided at least one
example
of running files from the command line when I teach the SWC stack
using
Python. Do teachers of the R stack also do this? Is it important to
make
such a distinction?
Cheers,
Matt
On Fri, Apr 1, 2016 at 3:01 AM, Vilbig, Kevin P
<[email protected]>
wrote:
Most of the really rad tools out there use polyglot stacks, anyway.
There is no reason why you can't run a bash script that runs a python
script (or some weird ancient legacy tool) to run some analysis that
pipes
a final CSV into an R script's dataframe for plotting using the
prettyness
of ggplot.
Programming Languages are for people.
------------------------------
*From:* Discuss <[email protected]> on
behalf
of E.W. <[email protected]>
*Sent:* Thursday, March 31, 2016 2:51 PM
*To:* Matthew Gidden
*Cc:* [email protected]
*Subject:* Re: [Discuss] Any tips for learning R and Python?
If I am recalling things correctly, and this will certainly be
contentious
for some folk, but Python is a general purpose programming language
while R
is a statistical programming language.
I think it is generally the case that with enough hacking you can
accomplish nearly any task with any tool, but some tools are more
geared
towards performing certain tasks. I like to stress to brand new
students
that the question is never "can" but "should" or "which is easier?"
when it
comes to this kind of thing. Sometimes even a brutal hack is more
efficient
or mentally easier to accomplish than fighting to learn something in
a new
language that you aren't comfortable with. "I know this could be
better R,
but I need to get the job done. [translation: please don't judge my
for
loops]" is a completely sane and normal reaction. Programming
communities
or those offering consultations shouldn't turn into handwriting
judges.
This doesn't mean we should reject or toss away the importance of
language
idioms, but turn our attention to respecting that it's the research
content
that matters and not which plotting library or whatever else they
used. I
think that SWC does a great job of this balance and showing it in
action.
I don't believe there is a clear line to be drawn between Python and
R,
except in the cases when a specific package is needed and does not
exist
for that other language. The choice between Python or R is never
*just*
about the task, but also about the skills, experiences, and support
networks of the person who will be writing the code for that task.
Elizabeth
_______________________________________________
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
_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
