I have written several books that use Python to explain topics like Bayesian Statistics and Digital Signal Processing. Along with the books, I provide code that readers can download from GitHub. In order to work with this code, readers have to know some Python, but that’s not enough. They also need a computer with Python and its supporting libraries, they have to know how to download code from GitHub, and then they have to know how to run the code they downloaded.
And that’s where a lot of readers get into trouble.
Some of them send me email. They often express frustration, because they are trying to learn Python, or Bayesian Statistics, or Digital Signal Processing. They are not interested in installing software, cloning repositories, or setting the Python search path!
I am very sympathetic to these reactions. And in one sense, their frustration is completely justified: it should not be as hard as it is to download a program and run it.
But sometimes their frustration is misdirected. Sometimes they blame Python, and sometimes they blame me. And that’s not entirely fair.
Let me explain what I think the problems are, and then I’ll suggest some solutions (or maybe just workarounds).
The fundamental problem is that the barrier between using a computer and programming a computer is getting higher.
When I got a Commodore 64 (in 1982, I think) this barrier was non-existent. When you turned on the computer, it loaded and ran a software development environment (SDE). In order to do anything, you had to type at least one line of code, even if all it did was another program (like Archon).
Since then, three changes have made it incrementally harder for users to become programmers
Computer retailers stopped installing development environments by default. As a result, anyone learning to program has to start by installing an SDE – and that’s a bigger barrier than you might expect. Many users have never installed anything, don’t know how to, or might not be allowed to. Installing software is easier now than it used to be, but it is still error prone and can be frustrating. If someone just wants to learn to program, they shouldn’t have to learn system administration first.
User interfaces shifted from command-line interfaces (CLIs) to graphical user interfaces (GUIs). GUIs are generally easier to use, but they hide information from users about what’s really happening. When users really don’t need to know, hiding information can be a good thing. The problem is that GUIs hide a lot of information programmers need to know. So when a user decides to become a programmer, they are suddenly confronted with all the information that’s been hidden from them. If someone just wants to learn to program, they shouldn’t have to learn operating system concepts first.
Cloud computing has taken information hiding to a whole new level. People using web applications often have only a vague idea of where their data is stored and what applications they can use to access it. Many users, especially on mobile devices, don’t distinguish between operating systems, applications, web browsers, and web applications. When they upload and download data, they are often confused about where is it coming from and where it is going. When they install something, they are often confused about what is being installed where.
For someone who grew up with a Commodore 64, learning to program was hard enough. For someone growing up with a cloud-connected mobile device, it is much harder.
Well, what can we do about that? Here are a few options (which I have given clever names):
Back to the future: One option is to create computers, like my Commodore 64, that break down the barrier between using and programming a computer. Part of the motivation for the Raspberry Pi, according to Eben Upton, is to re-create the kind of environment that turns users into programmers.
Face the pain: Another option is to teach students how to set up and use a software development environment before they start programming (or at the same time).
Delay the pain: A third option is to use cloud resources to let students start programming right away, and postpone creating their own environments.
In one of my classes, we face the pain; students learn to use the UNIX command line interface at the same time they are learning C. But the students in that class already know how to program, and they have live instructors to help out.
For beginners, and especially for people working on their own, I recommend delaying the pain. Here are some of the tools I have used:
Interactive tutorials that run code in a browser, like this adaptation of How To Think Like a Computer Scientist;
Entire development environments that run in a browser, like PythonAnywhere; and
Virtual machines that contain complete development environments, which users can download and run (providing that they have, or can install, the software that runs the virtual machine).
Services like Binder that run development environments on remote servers, allowing users to connect using browsers.
On various projects of mine, I have used all of these tools. In addition to the interactive version of “How To Think…”, there is also this interactive version of Think Java, adapted and hosted by Trinket.
In Think Python, I encourage readers to use PythonAnywhere for at least the first four chapters, and then I provide instructions for making the transition to a local installation.
I have used virtual machines for some of my classes in the past, but recently I have used more online services, like this notebook from Think DSP, hosted by O’Reilly Media. And the repositories for all of my books are set up to run under Binder.
These options help people get started, but they have limitations. Sooner or later, students will want or need to install a development environment on their own computers. But if we separate learning to program from learning to install software, their chances of success are higher.
UPDATE: Nick Coghlan suggests a fourth option, which I might call Embrace the Future: Maybe beginners can start with cloud-based development environments, and stay there.
UPDATE: Thank you for all the great comments! My general policy is that I will publish a comment if it is on topic, coherent, and civil. I might not publish a comment if it seems too much like an ad for a product or service. If you submitted a comment and I did not publish it, please consider submitting a revision. I really appreciate the wide range of opinion in the comments so far.
via Allen Downey