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
>
>
> *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-M6995c8e86f51553b91612433>
>
--
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: discuss
Permalink:
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M883a697ba376488aad311649
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription
