Typically when you open a terminal for the first time on a new computer, you're greeted with something like this Windows command prompt:
Or something like this on Ubuntu:
A few things have happened implicitly that ultimately lead to what you see here.
Shell Programs
A terminal doesn't do much by itself - it's really just a "screen" that you can primarily interact with via text commands. What shows up inside the terminal window is a program that opens with the terminal by default.
In most cases, this is a shell program. Similar to zoological shells that surround an organism but are not part of the organism, a shell program is separate from the operating system, but intimately connects with the operating system. Not similar to zoological shells, you can send commands to a shell program that let you manipulate and gather information about your computer.
Throughout this book I'll sometimes suggest commands for you to run. That will look like this nicely formatted snippet below:
echo "Hello there!"
You can either copy and paste this into your terminal window, or type it out yourself. Some may say the pain and effort of typing it out yourself is better for learning, and it's certainly good practice for when you have to figure out the correct command for your own situation. But it's up to you how you want to see the commands in practice!
Let's try running the above command.
It executed the command we gave it, and then it brought us back to the starting point!
The REPL
When you run a command in the shell, the shell program goes through a little routine:
- Read the command given by you, the user;
- Evaluate the command, or run the command and send the result back to the shell;
- Print the result of the command to the shell interface; and
- Finally - sort of - the shell prepares to do it all over again, waiting for a command so it can go back to step 1 again
And then it does this until the shell program closes. Usually this is when you
close the window, or run the command exit.
Since this routine happens over and over as you run commands, we say that it's running in a loop, like how a loop of string or thread makes a path you can follow continuously. Because of that, we call this read-evaluate-print loop a REPL for short.
The term has some cool historical context you can touch on from Wikipedia, but that isn't required reading.
Programming in a REPL
The REPL is a convenient construction for software development. Many programming
languages provide a REPL program for running bits of code for immediate results,
which may help you with testing or experimentation. The Python language REPL can
be accessed with the command python like below:
And from here you can write some small snippets of Python, or even a full program if you want!
This simple program adds up all the numbers from 1 to 10.
Of course, you wouldn't want to type entire programs into the REPL every time you need to run one. You can also run code by putting that code into a file. In fact, some languages don't provide a default REPL, and you have to put the code into a file so another program called a compiler can make that code into something that the computer can understand.
Compiled Languages VS Interpreted Languages
This ebook isn't intended to be a full discussion on the types of languages a software developer may encounter, but this brief tangent on the subject will be helpful in your development career!
This diagram is a massive oversimplification, but as an introduction to the concept, it will work well enough.
Generally speaking, compiled languages and interpreted programs differ in the relationship between the source code and the "program" that does things in the computer. A compiled program is not the source code that programmers write. Rather, it is a product of the source code being processed by a different program or set of programs. Often, this set of programs is simply referred to as the compiler for that language, since the process is called compiling. In actuality, the compiler is one of several programs, processing the results of previous programs in a chain, and eventually this creates the program that you can run (or execute, or invoke, or kick off...we have a lot of words for this idea) to do things on your computer.
With an interpreted language, by comparison, the source code more or less is the "program". Instead of being compiled, however, the source code is interpreted, line by line, by a program called the interpreter. The Python REPL in the example from before is such an interpreter, and it can operate line-by-line as a REPL does, or it can operate on files of source code.
In practice, the two concepts can get quite blurry. It's possible to partially compile interpreted languages in order to make them run faster, and it's possible to build an interpreter for a language that's usually compiled! You shouldn't have to worry about such things for a while, though, as those details are typically under the hood if they happen at all.
As a final note, interpreted languages are often synonymous with another term, scripting languages. As you may expect, programs written in scripting/interpreted languages are frequently called scripts. "Run the deployment script" is something I've heard and said quite a bit in my career!