FWIW, when helping in SWC workshops, I’ve often found students getting confused in python notebooks due to hidden state.
The hidden state issues of notebooks are, however, no different to how many of us work in IDEs with interpreted languages (RStudio, MATLAB), where we run bits of code at a time while experimenting or debugging. It’s a useful approach. My suggestion is that we should aim to, 1. Use notebooks, but take care to explain that python != the notebook, similarly to explaining that git != github. 2. Make sure people understand how they work – that you’re running a bit of code at a time, that editing something that you’ve already run doesn’t change what’s in memory, and so forth. It’s a gotcha, but what we teach is full of gotchas, and instructors and helpers will need to take a bit of time with those who don’t immediately see what’s going on. From: April Wright via discuss <[email protected]> Sent: 29 August 2018 00:43 To: [email protected] Subject: Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks" 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> ________________________________ Heriot-Watt University is The Times & The Sunday Times International University of the Year 2018 Founded in 1821, Heriot-Watt is a leader in ideas and solutions. With campuses and students across the entire globe we span the world, delivering innovation and educational excellence in business, engineering, design and the physical, social and life sciences. This email is generated from the Heriot-Watt University Group, which includes: 1. Heriot-Watt University, a Scottish charity registered under number SC000278 2. Edinburgh Business School a Charity Registered in Scotland, SC026900. Edinburgh Business School is a company limited by guarantee, registered in Scotland with registered number SC173556 and registered office at Heriot-Watt University Finance Office, Riccarton, Currie, Midlothian, EH14 4AS 3. Heriot- Watt Services Limited (Oriam), Scotland's national performance centre for sport. Heriot-Watt Services Limited is a private limited company registered is Scotland with registered number SC271030 and registered office at Research & Enterprise Services Heriot-Watt University, Riccarton, Edinburgh, EH14 4AS. The contents (including any attachments) are confidential. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. ------------------------------------------ The Carpentries: discuss Permalink: https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M0b4f2fd6e1a4461d3bbf9fc7 Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
