Dear Nick, Tom and All, I think live coding using an edit -- save -- run cycle has quite a number of advantages:
(1) you have a full editor for editing, which I personally find much easier than editing in a REPL. This is particularly true for Python, where I find that I have much less trouble writing well-formed indentations in a proper editor than in a REPL. (2) By running a fresh interpreter each time, there is no risk of build-up of implicit global variable context, which I've often seen in notebook-type environments. (Yes, you can start a new interpreter in these to get rid of any clutter in the context, but that requires experience and a discipline that is rather difficult to establish in a workshop like format.) (3) Iteratively developing a "scratch.py" script leads to a result that is more ueful to learners in the long run. In my experience, such scripts are rather easier to read and understand than notebook-like collections of code snippets, and if development is done in a REPL, there isn't even a file that can be read later. (4) Writing scripts is an important skill / habit for anyone interested in running their stuff on HPC queueing systems etc. Best regards, Jan On Sun, Nov 06, 2016 at 12:31:54AM -0700, Thomas Ballinger wrote: > Hi Nick, > > I don't have killer objections, but thought I'd describe some advantages > I've found of live coding over this approach. > > Writing code a single line at a time in a REPL keeps my Tested Hypotheses > per Minute high: every sequential step toward a goal is accompanied by a > check of my mental model of the system, and additional side checks are > cheap to make, questions quick to answer. I can keep learners engaged with > questions like what will this print, will we get an error, to what to sort > of thing does this variable refer? > > Because these are the good effects of a REPL I'm most interested in, were I > to take your approach of editing a file and running it instead I would do > the following. > * Run the code a lot; once after even the tiniest change to the code. > * Have both the editor and the terminal onscreen at the same time. The text > size should be bumped way up, so you'll be writing with only 60 characters > wide in your editor and similar in the terminal. > * Play with the functions and objects you've created in the file in a > terminal. > > Regarding this hybrid approach Hans uses F5 in Spyder to achieve, `python > -i scratch.py` will accomplish the same thing: running a script, then > presenting an interactive prompt in that namespace. Terminal IPython and > bpython also have this `-i` flag. > > Live coding has some serious drawbacks: the consequences of mistakes are > much higher, and editing operations are much less efficient. I really like > the approach Hans describes of building small pieces of code in a REPL then > copying them out into a file. Features of bypthon (disclaimer: which I > contribute to) like ctrl-r rewind, F6 reimport modules and rerun session, > F7 to send session to a text editor so snippets can be copied out were > added to specifically support this progression and it also works well in > IPython, and is probably smoothest in a Jupyter notebook, where "moving > into an editor" mostly means combining multiple cells. When live coding I > find the management of screen real estate to be a real problem (especially > with a pumped up font size), so especially like the undo feature. IPython's > newly excellent multiline editing (if you haven't tried terminal IPython > for a few months, give it another shot - the new editing interface provided > by Prompt Toolkit is superb, (see > http://blog.jupyter.org/2016/07/08/ipython-5-0-released/) I agree the > additional complexity of any of these tools can be taxing. I personally > find terminal IPython and bpython similar enough to the regular python > interpreter that one of these can be taught instead of vanilla python, but > many pragmatic teachers don't share this opinion. > > However I find Jupyter notebooks still to be the best option when live > coding for beginners because of the much improved editing experience and > the seamless transition from live coding to writing "libraries" by > combining cells. Wish that editing cells was more like vim or emacs? Tough! > Your learners may not be familiar with these editors. With a Jupyter > notebook, there's no context switching, no learning that the regular copy > and paste commands don't work anymore, no clicking on the terminal to be > frustrated the cursor can't be moved by the mouse. Screen real estate > management is easy because cells can be reordered and combined, and cells > can be edited over and over again, for each mistake you make. > > Tom > > On Sat, Nov 5, 2016 at 8:03 AM, Cameron Macdonell < > [email protected]> wrote: > > > Hi Nick, > > > > I think it's an excellent idea. It's a great way to connect with the > > shell lesson which is typically taught before Python. I find many learners > > see the shell as a bit of separate world from the GUI tools and making that > > connection can help break the shell vs GUI dichotomy. > > > > Do you typically teach with Jupyter Notebooks (the norm) or with a > > different Python IDE? > > > > Another way you can achieve what you've suggested is by using Jupyter's > > ability to export just the Python code from a notebook and then run that > > use "python export.py" from the shell. > > > > Cam > > > > >>> nick james <[email protected]> 11/05/16 6:43 AM >>> > > Hi, > > > > I've had a quick look through the archive looking for killer objections > > to the idea of editing a file, say scratch.py, then switching to a > > console window and doing 'python scratch.py'? > > > > This MO doesn't seem to be deprecated or recommended; I'd be interested > > to hear comments or pointers to discussions I've missed. > > > > Nick J > > _______________________________________________ > > Discuss mailing list > > [email protected] > > http://lists.software-carpentry.org/listinfo/discuss > > > > _______________________________________________ > > Discuss mailing list > > [email protected] > > http://lists.software-carpentry.org/listinfo/discuss > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.software-carpentry.org/listinfo/discuss -- +- Jan T. Kim -------------------------------------------------------+ | email: [email protected] | | WWW: http://www.jtkim.dreamhosters.com/ | *-----=< hierarchical systems are for files, not for humans >=-----* _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
