Hi all, I agree. I spend probably 70% of my time in notebooks. However, the distinction is between "initial coding" vs. "coding". In my specific environment (which I do not claim is authoritative or representative), I have found many users stay in the IDE/notebook environment. Further, I have found this trend to be more likely (again, small sample size) with R users over Python users. I'm curious if this is true of other environments as well.
Cheers, Matt On Sun, Apr 3, 2016 at 7:31 PM, Alfred Essa <[email protected]> wrote: > 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
