Day 601 of 1000
This is the second in a series of posts on how we taught our children to program, what we did wrong and how we think we could have done better. You can see the introductory post and index to the series by clicking here.
[Previous post]
[Next post]
We think it was about 2005 when Christian was ten years old or so that he really took an interest in how software works on a computer. I am not talking about how to use software on a computer. I am talking about how it actually works. We had an old Dell Desktop (I forget the model) with Ubuntu Linux installed on it. All Christian wanted to do at first was install some games and some drawing and rendering programs. The way you did that with Ubuntu is through the use of a GUI front-end program called Synaptic that managed program installation, updating, deleting, etc. using a program tool called APT (Advanced Packaging Tool).
He got pretty good at that, but the computer was so limited in its capabilities and resources he would often get stuck. This led him to the use of Google to find answers to his questions about how to get unstuck. The problem was that he often stayed stuck because there were no good answers on the internet, even after a thorough search. The next step, then, was to ask experts on forums like Ubuntu Fourms. The answers often came in the form of a command line (non-GUI) process where he had to open up a console to get a command prompt so he could follow the procedures he was given. Little by little, he got proficient at using the Linux command line to run APT and other utilities, getting help from man pages, and learning Linux’s basic directory structure.
Next, he started to run into programs that were not set up for installation via APT, so he learned how to install programs from the source code. The way it works is that a program’s source code, usually C/C++ is downloaded from the internet. It is set up for the computer on which it will be installed and customize for the needs of the user by running a program called configure. Then a program called make is run to compile and link the program which creates the binaries (the actual file(s) that will run the program). Finally, make is run again, but with the word install after it so that the program will be moved to the correct folder in the Linux file system so that the user will know where and how to start the program and the program will know the location of other files it needs to run properly.
The set of steps listed in the previous paragraph–configure, make, make install–is the normal procedure used to take programs written in C/C++ as text files, turn them into programs that will run on a computer, put the files in the correct folder on the disk drive, and assure all additional files required to run the program are in the right place. Sometimes the names of these steps change depending on the computer, operating system, and other factors, but the process is essentially the same. The problem is that the configure, make, make install process hides compiliation and linking from the user. That is a good thing most of the time, but a person who wants to learn how to program needs to know how to compile and link a program, not just follow the cookbook configure, make, make install process.
Fortunately for Christian, the configure, make, make install process, for some fairly technical reasons, did not allow him to control the installation of the programs he wanted to run in the way he wanted to run them. Specifically because of that, he started to read and learn about the compiling and linking process. For some programs, there are heavily documented, step-by-step procedures to walk through that process. This helped him understand how a program called a compiler takes a text file that holds a C/C++ program and converts it into a binary file and how a second program called a linker takes that binary file and links it to other program files that it needs to run properly.
It is not possible to program without knowledge about how to perform compiling and linking. This can be hidden from the programmer in something called an Integrated Development Environment (IDE) which we will talk about later, but it is best to get started just the way Christian got started, learning the command line usage of the compiler and linker because this gives a much better understanding of the process needed to test and run a hand-written computer program.
All of the above happened under my radar. At first he did this to get games and drawing programs running, but eventually, he just wanted to learn more about how Linux and the programming process worked. All I really did in this process was provide a ten year old boy an old, piece of trash computer that had no programs on it that interested him. He did the rest. I am not sure how I would have taught this to him in a structured way, but I will take a stab at explaining how that could be done toward the end of this series of posts.
