Learning to program gets harder

Hi, Habr! I present to you the translation of the article by Allen B. Downey, the author of such books as Think Python , Think Java , Think Bayes, and others, published in the author's personal blog .

I have written several books in which topics like Bayesian statistics and digital signal processing are explained using the Python programming language. In addition to books, readers can download the code from GitHub. In order to use this code, you need to know some of the basics of Python. That is, readers should have a computer on which the interpreter of this language and the necessary libraries are installed, they must know how to download the code from GitHub, and they also need to know how to run the code they downloaded.

Trying to do all this, many readers begin to experience difficulties.
')
Some email me. They share their disappointment because they want to learn programming in Python, Bayesian statistics, or digital signal processing, rather than installing specialized software, cloning repositories, or setting environment variables.

I understand their feelings. In a certain sense, their disappointment is justified. Download and run the code should not be so difficult. Sometimes they blame the difficulties of Python, and sometimes they blame me. And I think it is not entirely deserved.

Let me explain my understanding of the problem and suggest several solutions (or at least workarounds).

The fundamental problem - the barrier between using a computer and writing programs for it increases.

When I got the Commodore 64 (I think, in 1982), this barrier was not. When you turned on the computer, it ran the development environment. And in order to do anything, you had to enter at least one line of code, even if you just wanted to start another program.

Since then, three things have made the path from user to programmer more difficult.

1. Computers are no longer sold with default development environments. Now anyone who wanted to learn how to program had to first establish a development environment. And this is a bigger barrier than it might seem. Many users have never installed anything at all, did not know how to do it, and could not have the necessary rights to do this. Now it has become much easier to install programs than it was before, but possible errors during the installation have not gone away, and this can cause serious inconvenience to users. If someone wants to learn how to program, he should not first learn system administration.
2. User interfaces are heavily away from the command line in the direction of graphical interfaces. The latter, as a rule, are easier to use, but they do not display information about what is actually happening in the system. When the user does not need to know all these details, there is nothing terrible about such behavior. But the problem is that graphical interfaces hide information that programmers need to know. Therefore, when the user begins to learn to program, he is suddenly confronted with things that are usually hidden from him. If someone just wants to learn how to program, he does not have to learn the structure of operating systems.
3. Cloud technologies only complicate the situation. People using web applications often have a very vague idea of ​​where their data is stored and with which applications they can access it. Many users, especially on mobile devices, do not see differences between operating systems, applications, web browsers and web applications. When they download data or send it via the Internet, they often do not fully understand where exactly this data comes from and where it goes. And when something is installed, they often do not fully understand what is being installed and where.

For a man who grew up with Commodore 64, learning to program was quite a challenge. For people surrounded by mobile devices connected to cloud services, it is even more difficult.

Good, and what can we do about it? Here are a few options:

1. Back to the Future. First, you can create computers (like my Commodore 64) that would break the barrier between using the device and programming it. One of the prerequisites for the creation of Raspberry Pi, according to Eben Upton , was the desire to create an environment that would turn users into programmers.
2. Meet the pain face to face. Another approach is to teach students how to set up and use the development environment before they start programming (or at the same time).
3. Delay the pain. The third option involves the use of cloud services so that students can immediately start programming and postpone the preparation of their own development environment for a while.

At one of my courses, we use the second approach. Students learn to use the UNIX command line at the same time as learning the C programming language. However, these students already know how to program and have the opportunity to turn to instructors for help.

For beginners, especially for those who work on their own, I recommend the third approach. Here are some tools I used:

1. Interactive tutorials that allow you to run code directly in the browser, such as this adaptation of How To Think Like a Computer Scientist
2. Browsing development environments such as PythonAnywhere
3. Images of virtual machines with already configured and ready-to-work development environments that the user can download and run on himself (provided, of course, that he can install the software for running the virtual machine).
4. Services like Binder , which represent the runtime in the cloud, and allow users to access certain functions through the browser.

In some of my projects I used all these tools at once. In addition to the interactive version of How To Think Like Computer Scientist, there is also an interactive version of Think Java , prepared and maintained by Trinket .

In Think Python, I suggest that readers use PythonAnywhere for at least the first four chapters, and then provide instructions on how to proceed to using Python locally .

I have used virtual machine images for some courses in the past, but lately I have been using online services more often, as was the case with this Jupyter laptop for the Think DSP book. And the repositories for all my books are prepared to work with the Binder service.

The described approaches help to start programming, but they also have their limitations. Someday the students themselves will want to, or they will need to install and configure the working environment on their computer. But if we separate the study of programming from the study of how to install and configure the appropriate software, the chances of success will increase.

Nick Coghlan suggested on Twitter a fourth approach that I would call Look into the future . Quite possibly, newbies can start from cloud development environments and stay on them.