These days most of the initial coding in Python in scientific computing and data science communities is done in the Jupyter environment. Working in the command line is not how practitioners code in Python.
Best, Alfred VP, R&D and Analytics McGraw-Hill Education On Sun, Apr 3, 2016 at 11:50 AM, Naupaka Bruce Zimmerman <[email protected]> wrote: > 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 >
_______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
