× {{alert.msg}} Never ask again
Get notified about new tutorials RECEIVE NEW TUTORIALS

Be Careful with Persistent Workspaces!

Jonathan Eunice
Jan 06, 2015
<p>Interactive workspaces or "notebooks" like <a href="http://ipython.org/">IPython</a>, <a href="https://github.com/JuliaLang/IJulia.jl">iJulia</a>, and the <a href="http://en.wikipedia.org/wiki/Smalltalk">Smalltalk</a> image are amazingly productive. The entire power of the language is available in a handy, interactive format. Their immediacy is intoxicating. If you want to try several variations on the same theme, just do it. The convenience is extraordinary—even compared to the already-convenient <a href="http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop">REPLs</a> that come with dynamic languages these days.</p><p>But beware! Because it’s easy to cut and paste and try different options, you will. These environments encourage and enable you to work longer with “the same data” and “the same structures.” Usually, that’s an advantage. More “time on station” means more leaning, and deeper understanding.</p><p>But if things go wrong, they can do so in confusing and confounding ways. You’re working longer with what you think is “the same data” or “the same objects.” But when you modify the values for or from one experiment, it can effect the values used for different experiments.</p><p>Your “<a href="http://en.wikipedia.org/wiki/Mental_model">mental model</a>” may not keep up with the sometimes-subtle interactions between code snippets. Change a value in one place and you may not remember that you needed it different in another place. “No! I’ll remember!” Sure you will. For a while. But after 15 or 20 minutes of detailed fiddling, across three or four slightly different takes on the same idea, things get a little fuzzier. Especially if you delete any of the intervening steps—the changes you thought were simply “dead ends,” but for which you changed some shared values in exploring that avenue. You begin to forget the context in which you ran earlier experiments, or all the varied little changes you made in between. Go back to the early experiments and re-run them…and they might not work the same, because the data is different from what it was.</p><p>In the best case you’ll realize: “Oh! Yeah. I changed <code>x</code>. I can put it back!” But in complex trials, what data has changed and what modes and options have been set isn’t so clear.</p><p>The solution is twofold. First, <strong>vigilance</strong>. Keep in mind that extra convenience means you’re making more changes and fiddling longer. Realizing that you’ll be modifying data and settings in ways that don’t happen in normal, completely linear code flow will make you more likely to realize when you have an interaction-between-experiements problem, not a basic code or data problem. Second, be willing to “<strong>flush</strong>” the persistent state. Save your notebook, and quit. Maybe get up and stretch, get some coffee, or take a break. Give your mind time to settle. Then when you restart and come back to it, you’re back to a basic, known state. Run through the steps from the beginning. Proceeding from a known, simple state is often the key to realizing what went wrong, and then starting to make forward progress again.</p>
comments powered by Disqus