+1 Notebooks are convenient, but the set up, kernel crashes, and 'when would I use a notebook vs spyder' questions make it seem a strange choice to me. One thing it does have though is an easily visible history of commands and their output.
Thanks Gerard -- Gerard Capes Research Applications, IT Services, University Of Manchester ________________________________ From: Kevin Vilbig via discuss [[email protected]] Sent: 28 August 2018 05:15 To: discuss Subject: Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks" 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 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-M23eb0c3fe051da7836a88dd5> ------------------------------------------ The Carpentries: discuss Permalink: https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Mab766eb256577e7b581c89db Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
