Understanding Language Models

Before you learn any concept in this course, you need one concrete experience: writing a small program, running it, and seeing it do what you asked on your own machine. Many learners find that abstract ideas make more sense once they have watched a program produce output for themselves. This lesson is that experience. It is deliberately short on theory. Its job is to show you how the course works, what you need in place, and what a healthy first run looks like, so that the lessons after it can focus on ideas rather than setup.

Treat this lesson as a checklist you can complete. By the end you should know where your code lives, whether anything needs installing, and how to confirm that your environment is working. The whole process rests on one loop that you will repeat throughout the course: write, save, run, read the output.

Before reading on, make a guess. Suppose you save a program in one folder, but the terminal is open in a different folder. Will the program run as expected?

In this course, the environment is your own computer unless a lesson tells you otherwise. You write the program in a plain text file or an editor, then save it. Saving it puts the file in a folder, and that folder is where the file lives. Running the program is a separate action: you type a command into the terminal, which is the text window where commands are typed and results are printed. The terminal always has a current folder, and the run happens from that folder.

Those three things are linked. The saved file sits inside a known folder. The terminal must be working in that same folder when you run the file. If the terminal is somewhere else, the command that refers to the file may not find it, and the run fails before your program does anything. The diagram below shows the relationship.

Some setups need software installed before anything will run, and some need nothing beyond a text editor and a terminal. Whether you need an installation depends on the environment the lesson asks you to use. The course setup instructions are the authoritative guide for your first run. Do not assume that a program you have seen elsewhere is the one this course uses, and remember that installation steps can change over time.

A simple way to tell that the setup is ready is to ask whether you can complete the loop from the course: write a file, save it in a known folder, run it from that folder, and read the output. If any step in that loop is missing a required tool, the setup is not ready yet.

A first run moves through a fixed sequence. Each stage depends on the one before it, so the sequence is worth following in order. The flowchart shows each stage and the decision at the end, where the output is checked.

A successful first run has a precise meaning. The program starts, executes every instruction without raising an error, and prints the output you expected. Nothing more is required. This means a successful run is not judged by how impressive the output looks. It is judged by three checks: the program started, no error occurred, and the output matches your expectation.

The distinguishing feature is the absence of error text. Error messages are the environment reporting what it could not do. If you see them, the run did not succeed, even if some output also appeared. Use the comparison above to decide which case you are in.

When a run fails, the terminal usually prints an error message. Read the first line first, since it usually names the problem. Then check the two causes that account for most failures: the location and the file name. Change one thing at a time and run again, so you always know which change made the difference. The flowchart follows that order.