Libraries and APIs

Nobody writes their own square root routine because somebody already wrote one, tested it, and packaged it into a library. A library is just a collection of procedures someone else built, ready to be called. The API, or application programming interface, is the public face of that library: the names of its procedures, what inputs they expect, and what output they return. It tells you what each procedure does without showing you the code that does it. That hidden inner code is called abstraction, the same idea behind procedures in general, just scaled up to code other people wrote.

Because the API only promises behavior, the library's internals can change freely. If the maintainers rewrite sqrt to use a faster algorithm next year, your program calling √25 still gets 5.0 back. You never touch their code, so their rewrite does not break yours, as long as the documented inputs and outputs stay the same. This is the whole point of hiding implementation: it lets libraries improve without forcing every program that depends on them to change too.

This connects directly to procedural abstraction from earlier in the unit. A library is a bundle of abstracted procedures shared across many programs instead of one. It also sets up the idea that modern software is built in layers: your program calls a library, that library might call another, and nobody needs to see all the way down. Understanding libraries and APIs is what makes the next step, reasoning about how programs combine to do complex things, possible.