In a previous post, I listed a range of Matlab’s idiosyncrasies and flaws that seemed so much more blatant once I returned from several years of Python use. This post is a continuation, except this time highlighting ways in which Python makes life simpler rather than Matlab making life more difficult.
If you haven’t tried Python and you’re on the fence about whether it’s worth learning, let the points below convince you.
Physics is like sex: sure, it may give some practical results, but that’s not why we do it quipped Richard Feynman. The oceanographer Curtis Ebbesmeyer1 provides a similar, albeit less memorable quote, when describing his early work on water slabs (aka snarks), which had relevance to both military and pollution issues: such practical matters did not interest me. I found snarks fascinating, even beautiful in their own right. The introductions to many scientific papers, however, are framed in terms of practical results. Hence the rhetorical question implied in the title: are the rationale we as scientists publish convenient little white lies: simply a way to validate undertaking the science that we find personally interesting and intrinsically satisfying?
Using Python daily for more than three years as part of my scientific workflow and then abruptly returning to regular Matlab use has made me realise how much better Matlab could be and how evident its idiosyncrasies are. Conversely, while I was aware and noticed that Python makes things simple, it is Matlab’s comparative flaws that really made me come to appreciate just how much has been achieved in the past decade by the community in making Python an indispensable scientific tool.
An aim of this post is to recognize Python’s impressive convenience and versatility. Unfortunately, however, this post more naturally develops by taking the pessimistic approach of highlighting Matlab’s flaws. What follows are several minor, and a few major, annoyances that I’ve noticed on returning to Matlab.
E-readers are no good for reading scientific papers.1 They’re grayscale, they’re too small, and flipping back and forth between pages takes time. That said, my e-reader has two key benefits for me as a scientist/academic. It provides a truly offline method to read content later and it lets me read books that are only available as PDFs.
Keeping track of scripts used to generate figures is difficult. Before realising that Jupyter Notebooks could solve most of my problems, I would have directories with dozens of scripts with filenames of varying levels of ambiguity. Names that probably meant something to me at the time, but are hardly descriptive months or years later. Names like ISW_plume_plots.m, new_ISW_model_plots.m, and plot_model_behaviour.m. A certain PhD comic springs to mind.
Regardless of whether its Python, R, Julia, Matlab, or pretty much any other type of code, Jupyter Notebooks solve the problem. For example, I use a single notebook to archive the code for all figures in a paper and, more importantly, I can associate each set of code with the figure it generates. Rather than trying to remember what file I want, I need only remember which figure I want. (I say archive because I much prefer to do the bulk of my exploratory analysis in an editor. Alternatively, JupyterLab may work better for you.)
Catching up on the literature is a daunting aspect of graduate studies. As a physical oceanographer, I regularly cite work from 30 to 40 years ago. In that time, and all the way back to the turn of the 20th century, the scientists before me got to answer all the low-hanging-fruit problems and write the papers that will be cited thousands of time. They leave behind the messy, complex, and esoteric questions for the current grad students. Surely, then, I would think the 60s or 70s or even earlier would have been the best time to be a grad student?