Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Pablo Hernandez via discuss]

Interesting conversation, I would also like to +1 notebooks. Firstly, we
can re-use the same notebook environment with different languages, and even
compiled languages, like c++ with xeus-cling
, are getting kernel versions for
running in notebooks.  They have their limitations of course, I personally
only use them as a easy-to-share script for data analysis and to generate
reproducible figures for manuscripts. But as mentioned, any IDE will
generate cognitive burden, and usually they only work for one language. My
personal favorite is to use just an editor, but I think they do feel more
alien for novices. Lastly, the most important feature of notebooks for me
is that we can get them in a server, and with just a browser, novice
students are getting a working environment.

For more advanced sessions and teaching best practices in software
development, I would go for complete freedom in whatever environment they
are already familiar, as well as the instructor.

Pablo

On Tue, Aug 28, 2018 at 7:43 PM, April Wright via discuss <
discuss@lists.carpentries.org> wrote:

> 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 
>> 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 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[April Wright via discuss]

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 
> 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 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Christina Koch via discuss]

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  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 
> 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 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Rémi Rampin]

2018-08-28 12:27 EDT, Maxime Boissonneault <
maxime.boissonnea...@calculquebec.ca>:

> As a side-discussion, I think we should also be wary of using Anaconda,
> and tell users not to use it in a cluster environment. For reasons, see
> here :
> https://twitter.com/mboisso/status/1034476890353020928
>

Hi Maxime,

All I see in this thread is that "it's like cheating on your partner" (!!!)
and it's "generically optimized software" that might be a bit slower than
locally-built libs (interesting concern when using Python, an interpreted
scripting language (and on the slow side too)).

Could you elaborate on those reasons?

Best
-- 
Rémi

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Meda07db00cd59806d98a30b6
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Carpentry lessons material in multiple (spoken) languages

[Rémi Rampin]

2018-08-28 05:11 EDT, "DVD PS" :

> So, over the last months, I've been working to get something that eases
> the work of the translators and provides all the languages the same
> visibility - i.e. one page for all!
>

Hi David,

I wonder if this is the right approach. There is no real benefit in having
everything be in the same repository, so long as you have links pointing to
the other languages. In fact, I am not sure if git-novice-*es*/01-basics/
is worse than git-novice/*es/*01-basics/ (or the current git-novice/
*es/_episodes/*01-basics/).

I think having separate repos (or branches) for different languages would
make it much easier to keep the translation up-to-date, since you can use
Git merges in the usual way to see what have changed in the upstream (e.g.
the English lesson) and update your translation.

I see that you are not far from this since you are in fact using a
submodule, however:

   - submodules are error prone (especially in sub-directories), it is
   likely that contributors or even maintainers will get this wrong
   - the build process gets more complicated (do contributors to the
   translation have to clone the outer project instead of the translation?)
   - the submodules for each translation will need to be updated in the
   outer repo for changes in the translation to appear on the site
   - you cannot have the translation be a branch that you merge from the
   English upstream (infinite recursion)

What do you think?

-- 
Rémi

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Tdb042c4bc0ecf365-M16279ab9bf8409e8faa1e004
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Carol Willing]

Hi all,

There's positive discussion that has been started by Joel's talk. While I liked 
his talk and there are some good points re: improving support for software 
engineering best practices in Jupyter and JupyterLab notebooks, I'm a bit 
concerned about the direction that this conversation is going.

While all are entitled to their personal opinions and the Carpentries will use 
notebooks when and if needed, I believe that the Carpentries would be doing its 
students a disservice by warning people not to use the notebooks or conda.

The notebooks are a popular and effective tool for scientists and data 
scientists to have in their toolbox. Project Jupyter won the ACM Software 
System Award recently, and the ACM stated "These tools, which include IPython, 
the Jupyter Notebook and JupyterHub, have become a de facto standard for data 
analysis in research, education, journalism and industry." 
https://awards.acm.org/software-system

While it's great for folks to have different personal perspectives, I want to 
make sure that the Carpentries and its lessons do not recommend that the 
Jupyter Notebooks, IPython, and JupyterHub should be avoided by scientists and 
data scientists.

Thanks,

Carol Willing


> On 28 Aug 2018, at 11:38, Maxime Boissonneault 
>  wrote:
> 
> These kinds of things are rather hard to track in time, because everything is 
> a moving target (conda and other package managers constantly get updated, but 
> also version of packages changes), but here is a bit more details :
> 
> - The 10x performance difference was with a user code, which I unfortunately 
> can't share (nor do I still have a copy of it). It was about numpy, which may 
> or may not have changed since MKL can now be shipped with Anaconda.
> 
> - FFTW, 2x performance gain : These slides compare between Conda-provided 
> (and those provided by other package managers) FFTW, and one which was built 
> on an avx2 cluster, the performance gain is 2x (see slides 28 and 29 :
> https://archive.fosdem.org/2018/schedule/event/installing_software_for_scientists/attachments/slides/2437/export/events/attachments/installing_software_for_scientists/slides/2437/20180204_installing_software_for_scientists.pdf
> 
> 
> - Tensorflow, 7x gain for CPU version, slide 28 of this talk : 
> https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/attachments/slides/2297/export/events/attachments/how_to_make_package_managers_cry/slides/2297/how_to_make_package_managers_cry.pdf
> 
>   This one was not comparing Conda itself, but manylinux python wheels 
> provided by the Tensorflow team, but no doubt Conda has the same issue if 
> they build for generic architectures.
> 
> 
> 
> Basically, any package that is compiled in a portable manner, such as what 
> Conda and manylinux wheels do, will have some degree of speedup if compiled 
> for the target architecture instead. This is typically achieved by the team 
> of analysts who manage a cluster.
> 
> Cheers,
> 
> Maxime
> 
> 
> On 2018-08-28 2:20 PM, Ashwin Srinath wrote:
>> I'm very interested to see these examples? We use and advocate the use
>> of conda environments and I'm happy to be convinced otherwise.
>> 
>> Thanks,
>> Ashwin
>> 
>> On Tue, Aug 28, 2018 at 2:17 PM, Maxime Boissonneault
>>  wrote:
>>> Regarding performance, we have example of code using Anaconda-provided
>>> packages that run 10 times slower than the same code using locally built
>>> packages, optimized for the cluster architectures. That's not *a bit*
>>> slower, that's a lot slower.
>>> 
>>> Regarding "cheating on your partner", that analogy is not by me, but the
>>> point he is trying to carry is that Anaconda basically replaces any cluster
>>> provided versions, which HPC center people are working hard to optimize.
>>> Recent versions of Anaconda are even worse, by packaging things like
>>> compilers and linkers, creating conflicts with cluster-provided system
>>> libraries and tools, and creating a lot of debugging problems for users and
>>> support people alike.
>>> 
>>> Regards,
>>> 
>>> Maxime
>>> 
>>> 
>>> On 2018-08-28 12:48 PM, Rémi Rampin wrote:
>>> 
>>> 2018-08-28 12:27 EDT, Maxime Boissonneault
>>> :
 As a side-discussion, I think we should also be wary of using Anaconda,
 and tell users not to use it in a cluster environment. For reasons, see
 here :
 https://twitter.com/mboisso/status/1034476890353020928
>>> 
>>> Hi Maxime,
>>> 
>>> All I see in this thread is that "it's like cheating on your partner" (!!!)
>>> and it's "generically optimized software" that might be a bit slower than
>>> locally-built libs (interesting concern when using Python, an interpreted
>>> scripting language (and on the slow side too)).
>>> 
>>> Could you elaborate on those reasons?
>>> 
>>> Best
>>> --
>>> Rémi
>>> 
>>> 
>>> The Carpentries / discuss / see discussions + participants + delivery
>>> options Permalink
>> --
>> The Carpentries: discuss
>> 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Maxime Boissonneault]

These kinds of things are rather hard to track in time, because 
everything is a moving target (conda and other package managers 
constantly get updated, but also version of packages changes), but here 
is a bit more details :


- The 10x performance difference was with a user code, which I 
unfortunately can't share (nor do I still have a copy of it). It was 
about numpy, which may or may not have changed since MKL can now be 
shipped with Anaconda.


- FFTW, 2x performance gain : These slides compare between 
Conda-provided (and those provided by other package managers) FFTW, and 
one which was built on an avx2 cluster, the performance gain is 2x (see 
slides 28 and 29 :

https://archive.fosdem.org/2018/schedule/event/installing_software_for_scientists/attachments/slides/2437/export/events/attachments/installing_software_for_scientists/slides/2437/20180204_installing_software_for_scientists.pdf


- Tensorflow, 7x gain for CPU version, slide 28 of this talk : 
https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/attachments/slides/2297/export/events/attachments/how_to_make_package_managers_cry/slides/2297/how_to_make_package_managers_cry.pdf


  This one was not comparing Conda itself, but manylinux python wheels 
provided by the Tensorflow team, but no doubt Conda has the same issue 
if they build for generic architectures.




Basically, any package that is compiled in a portable manner, such as 
what Conda and manylinux wheels do, will have some degree of speedup if 
compiled for the target architecture instead. This is typically achieved 
by the team of analysts who manage a cluster.


Cheers,

Maxime


On 2018-08-28 2:20 PM, Ashwin Srinath wrote:

I'm very interested to see these examples? We use and advocate the use
of conda environments and I'm happy to be convinced otherwise.

Thanks,
Ashwin

On Tue, Aug 28, 2018 at 2:17 PM, Maxime Boissonneault
 wrote:

Regarding performance, we have example of code using Anaconda-provided
packages that run 10 times slower than the same code using locally built
packages, optimized for the cluster architectures. That's not *a bit*
slower, that's a lot slower.

Regarding "cheating on your partner", that analogy is not by me, but the
point he is trying to carry is that Anaconda basically replaces any cluster
provided versions, which HPC center people are working hard to optimize.
Recent versions of Anaconda are even worse, by packaging things like
compilers and linkers, creating conflicts with cluster-provided system
libraries and tools, and creating a lot of debugging problems for users and
support people alike.

Regards,

Maxime


On 2018-08-28 12:48 PM, Rémi Rampin wrote:

2018-08-28 12:27 EDT, Maxime Boissonneault
:

As a side-discussion, I think we should also be wary of using Anaconda,
and tell users not to use it in a cluster environment. For reasons, see
here :
https://twitter.com/mboisso/status/1034476890353020928


Hi Maxime,

All I see in this thread is that "it's like cheating on your partner" (!!!)
and it's "generically optimized software" that might be a bit slower than
locally-built libs (interesting concern when using Python, an interpreted
scripting language (and on the slow side too)).

Could you elaborate on those reasons?

Best
--
Rémi


The Carpentries / discuss / see discussions + participants + delivery
options Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Mad4fadc6a6da6de2b5f2aeb9
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Président - Comité de coordination du soutien à la recherche de Calcul Québec
Team lead - Research Support National Team, Compute Canada
Instructeur Software Carpentry
Ph. D. en physique


--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M37b48fabbde91daec4f331d7
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Ashwin Srinath]

I'm very interested to see these examples? We use and advocate the use
of conda environments and I'm happy to be convinced otherwise.

Thanks,
Ashwin

On Tue, Aug 28, 2018 at 2:17 PM, Maxime Boissonneault
 wrote:
> Regarding performance, we have example of code using Anaconda-provided
> packages that run 10 times slower than the same code using locally built
> packages, optimized for the cluster architectures. That's not *a bit*
> slower, that's a lot slower.
>
> Regarding "cheating on your partner", that analogy is not by me, but the
> point he is trying to carry is that Anaconda basically replaces any cluster
> provided versions, which HPC center people are working hard to optimize.
> Recent versions of Anaconda are even worse, by packaging things like
> compilers and linkers, creating conflicts with cluster-provided system
> libraries and tools, and creating a lot of debugging problems for users and
> support people alike.
>
> Regards,
>
> Maxime
>
>
> On 2018-08-28 12:48 PM, Rémi Rampin wrote:
>
> 2018-08-28 12:27 EDT, Maxime Boissonneault
> :
>>
>> As a side-discussion, I think we should also be wary of using Anaconda,
>> and tell users not to use it in a cluster environment. For reasons, see
>> here :
>> https://twitter.com/mboisso/status/1034476890353020928
>
>
> Hi Maxime,
>
> All I see in this thread is that "it's like cheating on your partner" (!!!)
> and it's "generically optimized software" that might be a bit slower than
> locally-built libs (interesting concern when using Python, an interpreted
> scripting language (and on the slow side too)).
>
> Could you elaborate on those reasons?
>
> Best
> --
> Rémi
>
>
> The Carpentries / discuss / see discussions + participants + delivery
> options Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Mad4fadc6a6da6de2b5f2aeb9
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Maxime Boissonneault]

Regarding performance, we have example of code using Anaconda-provided 
packages that run 10 times slower than the same code using locally built 
packages, optimized for the cluster architectures. That's not *a bit* 
slower, that's a lot slower.


Regarding "cheating on your partner", that analogy is not by me, but the 
point he is trying to carry is that Anaconda basically replaces any 
cluster provided versions, which HPC center people are working hard to 
optimize. Recent versions of Anaconda are even worse, by packaging 
things like compilers and linkers, creating conflicts with 
cluster-provided system libraries and tools, and creating a lot of 
debugging problems for users and support people alike.


Regards,

Maxime


On 2018-08-28 12:48 PM, Rémi Rampin wrote:
2018-08-28 12:27 EDT, Maxime Boissonneault 
>:


As a side-discussion, I think we should also be wary of using
Anaconda,
and tell users not to use it in a cluster environment. For
reasons, see
here :
https://twitter.com/mboisso/status/1034476890353020928


Hi Maxime,

All I see in this thread is that "it's like cheating on your partner" 
(!!!) and it's "generically optimized software" that might be a bit 
slower than locally-built libs (interesting concern when using Python, 
an interpreted scripting language (and on the slow side too)).


Could you elaborate on those reasons?

Best
--
Rémi


--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Mb3de150d1dd911032d34b1e8
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Brian Stucky]

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 > 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 mailto:discuss@lists.carpentries.org>>
*Reply-To: *discuss mailto:discuss@lists.carpentries.org>>
*Date: *Saturday, August 25, 2018 at 10:04 AM
*To: *"discuss@lists.carpentries.org
"
mailto:discuss@lists.carpentries.org>>
*Subject: *Re: [discuss] 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Maxime Boissonneault]

As a side-discussion, I think we should also be wary of using Anaconda, 
and tell users not to use it in a cluster environment. For reasons, see 
here :

https://twitter.com/mboisso/status/1034476890353020928

Maxime


On 2018-08-24 4:47 PM, Konrad Förstner wrote:

Dear all,

these are the slide of Joel Grus' Jupyter Con talk "I Don't Like
Notebooks":

https://docs.google.com/presentation/d/1n2RlMdmv1p25Xy5thJUhkKGvjtV-dkAIsUXP-AL4ffI/edit#slide=id.g362da58057_0_1 



Beside the fact that this talk is it really funny, it raises a lot of
issues that I can confirm from my experience:

- hidden states
- encouraging bad habits and discouraging good habits
- less powerful help tooltip than in a proper IDEs
- copy and paste between different media is hard

I personally really like Jupyter Notebooks for teaching (while it
never made into my data analysis tool box) but this talked motivated
me to rethink its usage and maybe I will try to jump earlier than
before into a proper IDE when I am teaching Python. Anaconda comes
with Spyder so there is a good alternative already at hand.

I would be interested in hearing your thoughts regarding this.

Best wishes

Konrad


--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-M84f62eac740739ea0a0f32af
Delivery options: 
https://carpentries.topicbox.com/groups/discuss/subscription



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Président - Comité de coordination du soutien à la recherche de Calcul Québec
Team lead - Research Support National Team, Compute Canada
Instructeur Software Carpentry
Ph. D. en physique


--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/T1505f74d7f6e32f8-Mc3ce4dda4ce68f5225691f61
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Labeikovsky, Wladimir]

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 
>  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  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 
> Reply-To: discuss 
> Date: Saturday, August 25, 2018 at 10:04 AM
> To: "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 

Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Bennet Fauber]

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
 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  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 
>> Reply-To: discuss 
>> Date: Saturday, August 25, 2018 at 10:04 AM
>> To: "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 

Re: [discuss] Data Management Training Material

[Aleksandra Nenadic]

Hi Toby & all,

Here are some resources from the University of Manchester's Library:
http://www.library.manchester.ac.uk/using-the-library/staff/research/services/research-data-management/

They run 2-hour workshops about research data management for each of the 
3 faculties here each month and try to tailor the workshops a bit 
towards each specific research domain/data.


Rosie Higman (rosie.hig...@manchester.ac.uk) is the person to talk to, 
should you want to reuse their material:

https://blog.research-plus.library.manchester.ac.uk/author/rhigman/
https://twitter.com/rosiehlib?lang=en

Cheers,
Aleks


--
. . . . . . . . . . . . . . . . . . . . .
Dr Aleksandra Nenadic, Training Lead
The Software Sustainability Institute
The University of Manchester
Email: a.nena...@manchester.ac.uk
Email: a.nena...@software.ac.uk
Skype: a.nenadic
Office: +44 (0)161 275 0672
Web: www.software.ac.uk
Twitter: @SoftwareSaved
. . . . . . . . . . . . . . . . . . . . .




On 27/08/2018 09:25, Mateusz Kuzak via discuss wrote:

Hi Toby and all,

there are video recordings from FAIR data workshop organised for 
Health Research Board (HRB) Ireland:

https://www.youtube.com/playlist?list=PL5egX8ZzHdSwbtwdQGzNDusf1uH2W18V1

@all thanks for sending so many interesting resources.

cheers,
Mateusz

On 24 Aug 2018, 18:39 +0200, discuss , 
wrote:


https://www.library.illinois.edu/rds/workshops/
*The Carpentries * / discuss 
/ see discussions  + 
participants  
+ delivery options 
 
Permalink 
 



--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Tafdc30751411bcaa-M00654ef68431529b26e72d0e
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

Re: [discuss] Carpentry lessons material in multiple (spoken) languages

[Azalee Bostroem via discuss]

Hi,

I am offline 8/28-9/7. I will reply to your message when I get back.

Thanks,
Azalee

On Aug 28, 2018, at 2:11 AM, DVD PS via discuss  
wrote:

> Hello everyone!!
> 
> TLDR; see the English/Spanish git-lesson: 
> https://swcarpentry-i18n.github.io/git-novice/
> - There are some identified problems, but if you find a new one, please, 
> create an issue.
> 
> The translation of the lessons is something where I think we can produce much 
> more impact than what we have already achieved. Last year some people from 
> the Latino American community did a great effort and fully translated a few 
> lessons into Spanish. However, the way translations are maintained is not 
> optimal while at the same time it doesn't get the same visibility than the 
> English lessons.
> 
> So, over the last months, I've been working to get something that eases the 
> work of the translators and provides all the languages the same visibility - 
> i.e. one page for all!
> 
> I have managed to do that as follows:
> 
> 1.- Create a jekyll theme for the carpentries. Instead of making every lesson 
> to merge with upstream (and solve conflicts), we can use a repository for the 
> theme and keep the lessons clean with only the material. Discussed in 
> styles#229. There it details some advantages.
> 
> 2.- Modify the English text on that theme to variables/tokens, and include 
> them as assets for each of the language translated. There's a PR to the 
> themed style (carpentry-theme#4)
> 
> 3.- Cleaned the git-lesson of all that's not needed, and create a submodule 
> with the automatically generated material from the translation tool. The 
> original lesson material gets converted into a po file using a tool I've 
> adapted for that purpose. Such file can be used with translation tools (e.g., 
> poedit, weblate) and the resultant gets converted into markdown. The idea is 
> that such process gets done automatically in Travis once the translations 
> have been accepted by the translation team. I'll keep working on the 
> automated process during the following weeks and show it up once it's 
> completed.
> 
> An example of the final result is in 
> https://swcarpentry-i18n.github.io/git-novice/ - There are still few issues, 
> and there are more little things I keep finding that needs to be improved. 
> But I wanted to let you all know that this is almost there, and by using 
> themes I think it will not oly help the translators but the maintanence of 
> the normal lessons. If you want to give me a hand, don't doubt it for a 
> second! I will really appreciate it.
> 
> Cheers,
> David
> The Carpentries / discuss / see discussions + participants + delivery options
> Permalink

--
The Carpentries: discuss
Permalink: 
https://carpentries.topicbox.com/groups/discuss/Tdb042c4bc0ecf365-Md52455a5ecdb74faa95da707
Delivery options: https://carpentries.topicbox.com/groups/discuss/subscription

RE: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like Notebooks"

[Gerard Capes]

+1

Notebooks are convenient, but the set up, kernel crashes, and 'when would I use 
a notebook vs spyder' questions make it seem a strange choice to me. One thing 
it does have though is an easily visible history of commands and their output.

Thanks
Gerard
--
Gerard Capes
Research Applications, IT Services, University Of Manchester

From: Kevin Vilbig via discuss [discuss@lists.carpentries.org]
Sent: 28 August 2018 05:15
To: discuss
Subject: Re: [discuss] Slide of Joel Grus' JupyterCon Talk "I Don't Like 
Notebooks"

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 
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 
mailto:discuss@lists.carpentries.org>>
Reply-To: discuss 
mailto:discuss@lists.carpentries.org>>
Date: Saturday, August 25, 2018 at 10:04 AM
To: "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