I’ll add my vote for the being wary of notebooks. Their main value for teaching, IMO, is the literate programming aspect but I think we can have that without the setup overhead and the problems that Joel talks about.
Wlad > On Aug 27, 2018, at 10:15 PM, Kevin Vilbig via discuss > <[email protected]> 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]> 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]> > Reply-To: discuss <[email protected]> > Date: Saturday, August 25, 2018 at 10:04 AM > To: "[email protected]" <[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 / discuss / see discussions + participants + delivery options > Permalink -- Wladimir Labeikovsky Bioinformationist Health Sciences Library UC Denver | Anschutz Medical Campus orcid.org/0000-0001-6074-3269 ------------------------------------------ The Carpentries: discuss Permalink: https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Mdfdd6b1ab1c5dd9d07f7d3f9 Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
