Importance of Libraries
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.
Why Hand-Written Steps Pile Up
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 one job. Padding a column so the numbers line up is another. 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. This article explains what that foundation is, why it matters, and how a program's work changes once it depends on it.
What a Library Is
A library is a collection of pre-written code that a program can reuse instead of writing every step itself.
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 do a job. When your program needs one of those jobs done, it draws on the library rather than writing the same steps again.
The source describes libraries as forming the basis for further work. A useful way to picture this is that the first set of libraries is built once, and every later piece of work stands on top of it.
Why the Bare Language Feels Tedious
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 source gives the opposite side of the same observation: just about any task can be rendered simple by the use of good libraries. Notice the wording. The claim is not that a library makes one task easy in isolation. The claim is that a good library can make nearly any task simple, because the tedious low-level steps have already been handled inside it.
Where the Library Sits Between Program and Language
A program that uses a library does not copy the library's code into its own writing. It refers to what the library provides and asks it to do the job. The library holds the pre-written steps. The program holds the decisions about when and why those steps are needed. The library takes over repetitive low-level work, while the program keeps the decisions about what the task requires.
Tracing One Call to a Library Function
Follow one piece of work through a report program. The program needs a student name printed in a column of fixed width. With only the bare language, the program must examine the name, count its characters, work out how many spaces are missing, and add those spaces one by one. With a library, the program makes one request: pad this name to this width. The library performs the low-level steps, and control returns to the program with the finished text.
Read the sequence in order. Control starts in the program, moves into the library when the call is made, and the library carries out the steps that would otherwise have been written by hand. Only after that work finishes does control return to the program, which then continues with the next student name. The program's own code stays short because the repeated steps live inside the library.
Bare-Language Code Versus a Library Call
The two approaches below describe the same kind of task. The comparison is an original illustration written for this article to make the trade-off concrete. It is not a line-by-line listing from a specific language.
Padding a column with and without a library
A report must print each student name padded to a width of 12 characters before the score is printed. Compare the work the program does by hand with the work it does when it draws on a padding function.
- 1Hand-written path
The program measures the name, computes how many spaces are missing, and inserts those spaces with its own repeated steps. Each of these is a separate piece of code the author must write and check.
- 2Library path
The program makes one call that passes the name and the width 12. The decision that padding is needed still belongs to the program, but the repetitive steps are handled inside the library.
- 3What disappears
The measuring, counting, and inserting steps no longer appear in the program. The program still decides which names need padding and in what order they print.
- 4Same output
Both paths produce the same padded text for the same name. What changes is how much low-level work the program has to spell out.
The library call shortens the program by replacing several low-level steps with one request, while the program keeps responsibility for the decisions about the task.
Mistakes Learners Make About Libraries
Common mistake Believing a library adds new abilities to the language itself
Why it failsThe source is clear that a library does not change what your language can do. It provides ready-made pieces that already do a job.
Do this insteadThink of a library as a set of pre-written pieces the language's basic facilities can be used to build, not as an upgrade to the language.
Common mistake Assuming a library should be used only for big, complicated programs
Why it failsThe source's reasoning is that the tedious low-level steps appear in ordinary tasks too, such as padding a column or comparing names. Small repeated jobs benefit from reuse as well.
Do this insteadReach for a library whenever a job is a repetitive low-level step you would otherwise spell out in full.
Common mistake Thinking the program copies the library's code into its own file
Why it failsA program that uses a library refers to what the library provides and asks it to do the job.
Do this insteadKeep the library's steps in the library and let the program hold the decisions about when and why those steps are needed.
Common mistake Treating a library call as something that removes the need to decide anything
Why it failsThe library takes over repetitive low-level work, but the program still keeps the decisions about what the task requires.
Do this insteadBefore calling a library function, decide what the task needs, such as which names to pad and to what width.
Practice: Tracing a Report Task
A report program needs to print twenty student names, each padded to a fixed width, and then sort them. Name the work the program should keep for itself and the work it can hand to a library. Then count roughly how many separate low-level steps disappear from the program for each name.
Hints
- Ask which parts require a decision about the task, such as which list to sort and in what order.
- Ask which parts are repetitive low-level steps that the same kind of job would need every time.
- Compare the steps you would write by hand for one name with the single request made to the library.
Key Takeaways
- A library is a collection of pre-written code that a program can reuse instead of writing every step itself.
- Most programs are tedious to write in the bare language because its basic facilities are general and small, so ordinary jobs break into many low-level steps.
- A good library can make nearly any task simple by handling the tedious low-level steps inside it.
- A library does not change what the language can do; the program draws on it, and it keeps the decisions about what the task requires.
- Significant programs are built on sets of libraries that form the basis for further work.