Libraries and Standard Library Facilities

Imagine you have been asked to write a program that reads a list of student names, sorts them, and prints a neatly formatted report. You have a programming language and you know its basic ingredients: values, decisions, and repetition. You could start typing immediately. Within a few lines, you would notice that every small job has to be spelled out in full. Comparing two names character by character is a job. Padding a column so that the numbers line up is a job. Each of these must be written as explicit steps, and the program grows long before it does anything interesting.

This experience is the starting point for understanding libraries. Real software is not written in just a bare programming language. Before the work of any individual program begins, a set of libraries is usually developed, and those libraries become the foundation the program builds on. The rest of this section and the ones that follow explain what that foundation is, why it matters, and how a program's work changes once it depends on it.

The phrase pre-written is the key idea. A library does not change what your language can do. It gives you ready-made pieces that already perform a job. When your program needs one of those jobs done, it draws on the library rather than writing the same steps again. The library holds the pre-written steps, while the program holds the decisions about when and why those steps are needed.

The source states that most programs are tedious to write in the bare language. The reason is not that the language is useless. A language's basic facilities are general and small, so any moderately complex job breaks down into many low-level steps. A task that a person could describe in one sentence can require dozens of lines of careful instruction.

The same observation works in the opposite direction. Just about any task can be rendered simple by the use of good libraries. The claim is not that a library makes one task easy in isolation. It is that a good library can make nearly any task simple, because the tedious low-level steps have already been handled inside it.

Follow one request from start to finish. Your program does not copy the library's code into its own text. Instead, it refers to what the library provides and asks it to do the job. The diagram below shows the order of those handoffs for the report task: the program passes the names to a routine, the routine performs the repetitive low-level steps, and the finished result comes back to the program, which then continues with the decisions it still owns.

Notice what stays in your program. The program still decides that the names need sorting, which routine to ask, and what to do with the result. Only the repetitive mechanics move out of your code.

Compare the two ways of building the same report. In the bare-language version, the program itself must contain every comparison, every swap that puts names in order, and every padding step that lines up a column. In the library version, those steps are no longer written in your program. The program names the jobs it needs and lets the library carry them out.

Software is usually organized in layers. At the bottom are the basic facilities of the language. Above them sit the library facilities that come with the language, which handle many common jobs. Libraries added by programmers sit above those, and your program draws on all of them. Each layer is built on the one beneath it, which is why the source describes significant programs as built on sets of libraries that form the basis for further work.