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 <wpurw...@odu.edu
<mailto:wpurw...@odu.edu>> 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 <discuss@lists.carpentries.org
<mailto:discuss@lists.carpentries.org>>
*Reply-To: *discuss <discuss@lists.carpentries.org
<mailto:discuss@lists.carpentries.org>>
*Date: *Saturday, August 25, 2018 at 10:04 AM
*To: *"discuss@lists.carpentries.org
<mailto:discuss@lists.carpentries.org>"
<discuss@lists.carpentries.org <mailto:discuss@lists.carpentries.org>>
*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://urldefense.proofpoint.com/v2/url?u=https-3A__carpentries.topicbox.com_latest&d=DwMFaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=KegVEkA2ctAq0km1vjAxCdEFbMwuTmvOTW_VPYwXliM&m=zm7nn8JKDCCO28zpJ6nEbfvlXkf2sTJravXXklptlUQ&s=xxwm-0LYNrjjqTSIQ23Ebkg4caQthCZFhMrl9sImDCk&e=>*
/ discuss / see discussions
<https://urldefense.proofpoint.com/v2/url?u=https-3A__carpentries.topicbox.com_groups_discuss&d=DwMFaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=KegVEkA2ctAq0km1vjAxCdEFbMwuTmvOTW_VPYwXliM&m=zm7nn8JKDCCO28zpJ6nEbfvlXkf2sTJravXXklptlUQ&s=Xg34mI7-hOE-4WObWJ8NmGWwG0OZK7-tjRtlI16wfNU&e=>
+ participants
<https://urldefense.proofpoint.com/v2/url?u=https-3A__carpentries.topicbox.com_groups_discuss_members&d=DwMFaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=KegVEkA2ctAq0km1vjAxCdEFbMwuTmvOTW_VPYwXliM&m=zm7nn8JKDCCO28zpJ6nEbfvlXkf2sTJravXXklptlUQ&s=ODXUi7fv9zRPfPcGl79dVMubtf5IiFPh-OZpOSYGuuE&e=>
+ delivery options
<https://urldefense.proofpoint.com/v2/url?u=https-3A__carpentries.topicbox.com_groups_discuss_subscription&d=DwMFaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=KegVEkA2ctAq0km1vjAxCdEFbMwuTmvOTW_VPYwXliM&m=zm7nn8JKDCCO28zpJ6nEbfvlXkf2sTJravXXklptlUQ&s=o4DKKmGkv0u3vk18xo99xPetsuxRDOtco5dBNjcwP9A&e=>
Permalink
<https://urldefense.proofpoint.com/v2/url?u=https-3A__carpentries.topicbox.com_groups_discuss_T1505f74d7f6e32f8-2DM23eb0c3fe051da7836a88dd5&d=DwMFaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=KegVEkA2ctAq0km1vjAxCdEFbMwuTmvOTW_VPYwXliM&m=zm7nn8JKDCCO28zpJ6nEbfvlXkf2sTJravXXklptlUQ&s=0wz1DPLQL4l4Hlz17kBBbNj-C-WpV_mIjwHXFnBK1QQ&e=>
------------------------------------------
The Carpentries: discuss
Permalink:
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M6995c8e86f51553b91612433
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
