Kevin, Nice summary; thank you.
It is yet another thing to learn in a short time. I am not a notebook fan, and I remember attending two workshops at a conference that were notebook based -- those were my first real experience with notebooks -- and I had more questions about the mechanics of notebooks than I did about the material being presented using them. I thought that quite counter-productive. On Tue, Aug 28, 2018 at 12:16 AM 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 ------------------------------------------ The Carpentries: discuss Permalink: https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Meb310521de4fab8043b760db Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
