+1 to this. While notebooks have caveats, and it is definitely valuable to be aware of them, and to make students aware of them, I don’t think we could achieve nearly as much out reaching to no traditional users without them.
Maxime > > On août 28, 2018 at 7:43 p.m., <April Wright via discuss > (mailto:[email protected])> wrote: > > > > > Hi all- > > > > I agree with what Christina said. Someone upthread asked if the notebook was > meant to compete with MatLab. But with novices, our competition isn't MatLab > - it's Excel. You can open Excel, subset data, and plot it. Most of the > learners I work with have experience doing that. They know those little > moments of wonder and excitement of plotting data for the first time, and > having it tell a cool story. My job is to convince low programming > knowledge/awareness audiences that reproducible computational analyses aren't > here to steal the joy from working with data, but to enable deeper and more > exciting ways to interact with data. Jupyter Notebooks, as Christina & Adam > noted, are great for that. The output looks nice, and provides immediate > visual feedback. The interface is much less abstract, and is more familiar to > learners I work with. > > > > Qualitatively, I definitely notice that the conversations students have in > workshops/class are very different when teaching with the notebook than > without. No matter what I did teaching with a text editor and interpreter, > for novices, switching always seems like too much. The pace at which the > interpreter fills up, copy + paste when it works, copy + paste when you have > typos - all that stuff has always seemed to be a little too much for someone > who is just opening the interpreter for the first time. But when the notebook > is used, the content rather than the content delivery seems to be where the > discussion goes. You have to structure your lessons to promote discussion, > but there's no technology that can remove the burden on the instructor to use > it well. > > > > Lastly, I don't know another technology that is doing as much for > accessibility as Jupyter. All my undergraduates work more than 20 hours > weekly. Some are renting computers from the school, and need to renew those > rentals, and might not get the same computer after renewal. If there's a > serious hurricane on the coast, my reservist students can get called up on > deployment. It's hard to express the value of things like JupyterHub and > Binder for in-browser click execution for this population. Maybe there's an > in-browser click execute terminal emulator apart from Jupyter, and I don't > know about it. But it strikes me that if we're serious about meeting students > where they are, then we're serious about this particular technology. > > > > I was pretty skeptical about notebooks for a long time, but I'm basically all > in now for novice training. > > > > > > > > > > > > > > > > > > > --a > > > > > > On Tue, Aug 28, 2018 at 10:59 PM Christina Koch via discuss > <[email protected] (mailto:[email protected])> wrote: > > > > > > > Hi all, > > > > > > > > I was envisioning using a text editor for teaching Python, and keep coming > > back to the idea that I (and my learners) want to be creating a record in a > > file of some kind (script or notebook) but we also want to be able to run > > bits of that file, not the whole thing at once (as it will grow over the > > course of the lesson). I'd shy away from a simple editor + command line > > combination for an entire lesson, as I'd end up creating a lot of noise as > > I keep re-running the script. For R, developing a script in Rstudio allows > > you to run pieces at a time. Is Spyder a Python equivalent that would > > allow me to add to my ("notes") script without executing the whole thing as > > I add pieces to it? > > > > > > > > I'll second Adam's comment about "prettiness" -- esp. if you're doing > > anything with tables, I think the notebook interface is a lot less jarring, > > especially to novice programmers. > > > > > > > > Christina > > > > > > > > On Tue, Aug 28, 2018 at 11:28 AM Brian Stucky <[email protected] > > (mailto:[email protected])> wrote: > > > > > > > > I agree both with Joel's broader criticisms of notebooks and Kevin's > > > SWC-specific comments. As with Kevin, I have mostly been keeping this > > > to myself, so I am happy to see this discussion. Regarding SWC > > > specifically, I have also thought it odd that the early parts of a > > > workshop spend considerable effort trying to convince learners of the > > > value of the CLI as a general tool for patching together scripts, > > > commands, and data flow pipelines, only to seemingly abandon this when it > > > comes time to learn Python. > > > > > > -Brian > > > > > > > > > > > > > > > On 08/28/2018 12:15 AM, Kevin Vilbig via discuss wrote: > > > > > > > > > > > All, > > > > > > > > I do not like Jupyter notebooks for teaching, either and I have been > > > > thinking this privately for a while. They carry a lot of cognitive load > > > > compared to a straightforward CLI REPL, which we actually tout as the > > > > best way to start learning in our materials. I have taught a few SWC > > > > workshops and mostly stuck to the CLI and git lessons for that reason. > > > > I have taught some DC as well, but those are a different beast and are > > > > actually flow a lot more tightly compared to the SWC workshops. I > > > > suspect Jupyter notebooks as being the culprit. The notebooks seem good > > > > for people who learned to code from MATLAB or Mathematica because they > > > > superficially resemble those systems, but that is not most people that > > > > we teach nor even necessarily most of our teachers. > > > > > > > > > > > > I think it would be best practices (especially for the general > > > > pedagogical theories that we use) to teach Python at the level of a > > > > text file written in the same text editor we use for the other lessons. > > > > Then we should be running those scripts as files from the same command > > > > lines we use in the other lessons. Iirc this was the case until the > > > > lessons were changed to incorporate the Jupyter notebooks. This method > > > > would reduce cognitive load and increase mutual scaffolding between the > > > > lessons rather than needing a major cognitive gear-shift between CLI > > > > work and a browser-based IDE. I always wondered why there seems to be a > > > > disconnect between the other lessons where we really do keep it simple. > > > > Is it just to have some flashy GUI to show off like we have RStudio for > > > > the R lessons? > > > > > > > > > > > > I would prefer to teach the basics (variables, arrays, etc.) using the > > > > Python interpreter running from the command line, how to save and run a > > > > script using a text editor from the command line, and using the > > > > techniques we taught in other lessons like command line arguments. > > > > If the teacher uses Jupyter in their actual work, they can show off > > > > their work if there is extra time, (Maybe we should build a 25-30 > > > > minute segment like that into the lesson plan?) but we shouldn't be > > > > starting there. > > > > > > > > -K > > > > > > > > > > > > > > > > On Mon, Aug 27, 2018 at 1:31 PM Purwanto, Wirawan <[email protected] > > > > (mailto:[email protected])> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Jory, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Great moderating points. I don’t think we should throw Jupyter out of > > > > > the window completely, but we need to know how to use this tool. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Drawing from my days using ipython: Jupyter is basically a web-based > > > > > ipython with lots of candies added. There is one feature of ipython > > > > > that allows you to log the “In[NNN]” and the “Out[NNN]” of the python > > > > > code: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > %logstart -t -o LOGFILENAME > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I just checked that this also works on a jupyter session. LOGFILENAME > > > > > is just a text log file. After invoking this statement (once, at the > > > > > beginning of your python Jupyter session), every input and output > > > > > will be logged. But the output of “print” statements or inline > > > > > graphics (such as pyplot output) are not saved. (There are tricks to > > > > > make that happen, but that’s a topic for another thread.) But this > > > > > approach allows you to reason the mystery kernel codes, because > > > > > ipython logging won’t lie, and won’t be subject to cell editing (the > > > > > input/output you deleted on Jupyter will still be there in the log > > > > > file). I added “-t” flag to “logstart” magic in order to add > > > > > timestamp to the logged inputs, because sometimes I work on a > > > > > notebook for a long time, and lose track of when I did what. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would combine real software engineering (i.e. using modules, good > > > > > coding practices) for the heavy-lifting codes, and use Jupyter to > > > > > produce a record of my interactive session. I don’t put very long > > > > > codes in Jupyter cells, because that becomes clutter to me. But > > > > > again, this would call users to be a little bit more savvy: to be > > > > > able to interact with both the modules/other python source files and > > > > > the Jupyter notebook at the same time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > Wirawan Purwanto > > > > > > > > > > > > > > > > > > > > Computational Scientist, Research Computing Group > > > > > > > > > > > > > > > > > > > > Information Technology Services > > > > > > > > > > > > > > > > > > > > Old Dominion University > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Norfolk, VA 23529 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: Jory Schossau via discuss <[email protected] > > > > > (mailto:[email protected])> > > > > > Reply-To: discuss <[email protected] > > > > > (mailto:[email protected])> > > > > > Date: Saturday, August 25, 2018 at 10:04 AM > > > > > To: "[email protected] > > > > > (mailto:[email protected])" > > > > > <[email protected] (mailto:[email protected])> > > > > > Subject: Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I > > > > > Don't Like Notebooks" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I agree with most of the points everyone's making here, and just > > > > > wanted to add some from my experiences as I both teach and use > > > > > notebooks professionally and have taught with spyder. (+ pro / - con) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I tried to at least address the same topics as in Joel Grus' talk. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Teaching [Undergraduate and Graduate python-based courses using > > > > > Notebooks/Spyder] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - the hidden stateness always trips up students (and sometimes me) as > > > > > Joel points out > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - the hidden stateness is hard to teach; I have to use a lesson on > > > > > REPL vs standard interpreter to get the idea across. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - file saving/loading is a bit clunky and confuses students vs > > > > > spyder's approach they grok better (similar to Word or Powerpoint...) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - starting/stopping an instance is confusing to students because the > > > > > server is separate from the GUI > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + students find the label-code-output serialization easy to follow, > > > > > much more-so than spyder with numbered files and slides > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + the faster students like being able to easily scroll ahead until > > > > > they don't know something, then work on their own. With spyder I > > > > > would lose some of the faster students. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + one file / one lesson > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (All the cons are teachable, and they do get it in the end, but it's > > > > > just more cognitive hurdles.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (Also, I think some of this may be solved using the Jupyter NB IDE > > > > > that ships with Anaconda? I've seen screecaps of something > > > > > nifty-looking out there) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Git > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - NB plays poorly with git due to in-file binary blobs > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + I do it anyway > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + Once it's online, you can use nbviewer - it's like an informal > > > > > publication with comments, code, and results! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Professionally > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + NBs are good for prototyping or trying things out because they > > > > > let me quickly scaffold code in a messy fast way > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + Unit testing is straightforward "make a new cell to test stuff" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + NB to final production is easy: With the smallest bit of care, the > > > > > multi-cell NB I've made I download as *.py and immediately can import > > > > > it like a module in my production code and use it as a library! This > > > > > also addresses Joel's final comments on how to hide messy stuff from > > > > > decision-makers. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + Vim-like code and cell navigation and manipulation is so nice! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + There are kernels for everything under the sun, making teaching and > > > > > exploration with a consistent user experience very nice. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Never Experienced as NB issue > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * encouraging bad habits and discouraging good habits: I like that it > > > > > encourages comment cells. The resulting *.py module plays nicely with > > > > > git. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * NB tooltips are bad vs IDE: I teach students to look up > > > > > documentation, or use the help(), and the dir/file completion is > > > > > really nice. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * copy and paste between different media is hard: copying from web > > > > > with mangled quotes for example always bites students no matter what. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Jory > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Kevin Vilbig > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > Christina Koch - Research Computing Facilitator, > > > > University of Wisconsin - Madison (http://www.wisc.edu/), Center for High > > Throughput Computing (http://chtc.cs.wisc.edu/) > > > > Wisconsin Institute for Discovery (http://wid.wisc.edu/); Advanced > > Computing Initiative (http://aci.wisc.edu/); ACI-REF (https://aciref.org/) > > > > email: [email protected] (mailto:[email protected]) // phone: (608) 316 - > > 4041 // calendar: tinyurl.com/ChristinaCHTC > > (http://tinyurl.com/ChristinaCHTC) > > > > > > > > > > > > > > > > > > > > > > > > The Carpentries (https://carpentries.topicbox.com/latest) / discuss / see > discussions (https://carpentries.topicbox.com/groups/discuss) + > participants (https://carpentries.topicbox.com/groups/discuss/members) + > delivery options > (https://carpentries.topicbox.com/groups/discuss/subscription) Permalink > (https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M3ee733974d6dc04c0aab66b3) > > ------------------------------------------ The Carpentries: discuss Permalink: https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M9e02cca8ee51e61e4df6fc77 Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
