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 <
discuss@lists.carpentries.org> 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 <stuc...@flmnh.ufl.edu>
> 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 <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>
>>> *Reply-To: *discuss <discuss@lists.carpentries.org>
>>> *Date: *Saturday, August 25, 2018 at 10:04 AM
>>> *To: *"discuss@lists.carpentries.org" <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
>>
>>
>>
>
> --
> 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: cko...@wisc.edu // phone: (608) 316 - 4041 // calendar:
> 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-M883a697ba376488aad311649>
>
------------------------------------------
The Carpentries: discuss
Permalink:
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M3ee733974d6dc04c0aab66b3
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
