Easy and simple
I am going to use the definitions of "simple" and "easy" from this
- Simple comes from Latin simplex - one fold. Simple is the opposite of
complex, which comes from the Latin for "twisted together".
- Easy comes from old French aiser which in turn comes from the Latin
adjacens "lying close by" ()
"Easy" is what you are familiar with. "Easy" is not far from something you
"Simple" is when you have succeeded in breaking the problem into separate
Easy tools, simple tools
I use a general-purpose text editor for as many tasks as I can. For the last
six years I have used Vim and Gvim; before that, I used Emacs. Like many
powerful text editors, Vim and Emacs can be configured for editing many
different types of text files, including code in different languages. For
example, I am using Vim to edit this text in Markdown format; Vim does
Markdown syntax highlighting.
I had been using Emacs in this way for a long time before I read this advice
in the classic book "The Pragmatic Programmer" by Andrew Hunt and David Thomas
Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is
configurable, extensible, and programmable.
When I have a task that needs thought, I often sketch the code or text on a
piece of paper, then fill out the sketch in Vim. For example, I wrote the
first draft of this post in an art notebook with large pages, and now I am
typing it up and editing in Vim.
I use Vim to read and write:
- code in Python, C and MATLAB;
- papers or reference letters using LaTeX;
- tutorials in Restructured Text;
- presentations in Markdown / LaTeX;
To execute code I use the terminal command line, or the IPython Python
interpreter, which is also a terminal application. I use command-line tools
make to build my papers and presentations. In the days when I used
MATLAB daily, I preferred to start it in
-nodesktop mode, to disable most of
the graphical user interface.
Very occasionally I use a specialized tool for a short task that does not need
much thought. For example I sometimes use LibreOffice or OSX Pages to write
short letters, Keynote for a presentation with many graphics, or the Jupyter
notebook when I am experimenting with plots in Python, or when I am writing a
demonstration of code I already understand.
As soon as the task needs some thought, I switch into my text editor. I do
this to relieve myself of the burden of using the richer and more complicated
interfaces of the other tools. I am very familiar with my text editor, so I
no longer have to think how to do things like editing text. With Vim, in
particular, I find that the cursor seems to follow my eyes; I have little or
no conscious sensation of what my hands are typing as they enter the commands
to move the cursor.
I am sure I am not alone in finding it hard to think clearly. If you give me
an interface that makes it easy to play with code in a sloppy and unstructured
way, I will. Sometimes doing that is useful, but most of the time, giving in
to the temptation to play with code is disastrous for my clarity of thought.
I think more clearly in Vim because I have used Vim enough that my hands and
my motor cortex can do the mechanical work of editing, leaving the rest of my
brain free for thinking (). I do not have to interrupt my
concentration by moving my hands to the mouse or trackpad, because I can do
everything I need with the keyboard commands. Using my text editor is simple,
because the task of editing is not entangled with the task of thinking.
Easy and simple in teaching
When we teach scientists to write and use code, new students are unlikely to
know a general-purpose text editor well, and may never have used a terminal
application. It does not seem practical for them to learn to use an editor
and the terminal as well as the other new things we teach. For that reason,
many courses give students an easy interactive environment such as the MATLAB
workspace, R Studio or the Jupyter Notebook. The idea is that it makes it
easier for the students to concentrate on code rather than learning how to use
the tools. In my experience, the students often continue using the easy tools
from the class, and do not go on to learn the simple tools that experts use.
Some teachers do not believe that their students should be using the same
tools as the experts. The argument is that scientists use and write code in a
different way from programmers, so they do not need the tools that a
programmer would choose. If that argument were correct, that would be happy
for teachers, because the simple tools are hard to teach.
I chose my tools to help me think clearly. Does a scientist using code need
less clarity of thought than a programmer? Your answer to this will probably
depend on your model of scientific practice. If you think that a scientist
should spend most of their time exploring code and data in an informal way,
you might conclude that "easy" is acceptable, even desirable. My own
experience of using tools like the Jupyter Notebook is that I cannot afford to
work in this way without exposing myself to great risk from ubiquitous error
and self-deception (). If your experience of science is
like mine, you will probably prefer "simple".
You might accept that scientists do need to learn the simple tools at some
point, but the constraints of your course do not allow you to spend time on
teaching tools. Teaching the simple tools, would take too long. In that case
you have to consider the potential for damage to the students' practice over
the long term. If a student sees their teachers using easy tools, and
encouraging them to do the same, they are less likely to commit themselves to
the hard work necessary to learn the simple tools. To quote a friend and
colleague: "It would be terrible if we make a generation of copy-paste
As I have taught more, I have put more effort into introducing students to the
simple tools right at the beginning of my course. I want to teach students
tools that I would use myself. We use the terminal to run bash and git
commands, the IPython console for exploring small code fragments, and a
full-featured text editor for editing code and documents. In my most recent
course we used the Atom
text editor. Sometimes I do use the Jupyter Notebook for my own work, but I am
careful not to use it in class, because it is so addictive, and therefore
dangerous for someone new to coding.
Teach simple, not easy
Teaching always involves some degree of instruction that is implicit. The
students take our working practice as a model of expertise. This model can be
more more persuasive than anything else we teach. We should use implicit and
explicit learning to teach effective practice. Sound working practice is
the foundation on which we build; it is worth the cost in curriculum time to
show the benefit of simple, and the risks of easy.