Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Excess of technical detail in episode 4 on processes #956

colinmorris opened this issue Apr 2, 2019 · 3 comments


None yet
5 participants
Copy link

commented Apr 2, 2019

Quote from episode 4 on pipes and filters (emphasis mine):

The vertical bar, |, between the two commands is called a pipe. It tells the shell that we want to use the output of the command on the left as the input to the command on the right. The computer might create a temporary file if it needs to, or copy data from one program to the other in memory, or something else entirely; we don’t have to know or care.

I agree wholeheartedly! But later in the same lesson we do in fact get into some OS-level behind-the-scenes details that seem unnecessary. In particular, the stuff on processes, beginning with:

Here’s what actually happens behind the scenes when we create a pipe. When a computer runs a program — any program — it creates a process in memory to hold the program’s software and its current state.

The term 'process' isn't used anywhere else in the lesson. For the purposes of this explanation, I feel like we could just continue to use either the term 'command' or 'program' (i.e. "the program's standard input"), since those terms are used throughout the lesson.

Also, I think this whole paragraph on the shell's implementation could be cut:

The shell is actually just another program. Under normal circumstances, whatever we type on the keyboard is sent to the shell on its standard input, and whatever it produces on standard output is displayed on our screen. When we tell the shell to run a program, it creates a new process and temporarily sends whatever we type on our keyboard to that process’s standard input, and whatever the process sends to standard output to the screen.

I don't really need to know that the shell is itself a program with a stdout and a stdin, rather than, say, a book of spells animated by dark magic. Do I?


This comment has been minimized.

Copy link

commented Apr 3, 2019

+1 for cutting down on the technical detail.

Good catch!


This comment has been minimized.

Copy link

commented Apr 16, 2019

I completely agree with @colinmorris. These technical details are not relevant for beginners (they are normally not even relevant to know in my daily life as system administrator :-)


This comment has been minimized.

Copy link

commented Apr 16, 2019

I'm not sure the difference between a process and a program is "technical". Using them as if they were synonyms sets up learners for a very hard time when they get to the stage of running multiple processes of the same program. A typical stage where that's required is towards the end of a project, when time starts running out, and the final comprehensive analysis of all files accumulated throughout the project is required. Over the years, I've sorted out a considerable number of people who were stuck with a mental model suggesting to them that running multiple processes of the same program concurrently is unsafe, as data from one process might somehow spill into other processes.

I've also seen this misconception surface during shell trainings / intros, when learners ended up running more than one shell concurrently and struggled to understand how it can be that commands processed in one shell process make no difference to the other shell process.

For these reasons I'd like to keep the mention of process in the lesson, and I definitely recommend against any wording that could suggest to learners that "process" and "program" are interchangeable. I know the shell lesson is already packed as it is, so I'm undecided whether to suggest adding a proper introduction of the terms. But I do suggest leaving the term "process" in the lesson, as it is -- unless there's experience that it frequently confuses / trips up learners. I entirely agree that it's possible to complete the lesson and an entire workshop without differentiating these concepts, but those who end up continuing computational work will almost certainly need it at some point, and may benefit even from having a little seed planted during the lesson that may help them grasping the concepts.

@ErinBecker ErinBecker added this to the June 2019 Release milestone May 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.