At the very beginning of the course, I told you that programs were made of small individual instructions. That's totally true, but it's possible to get the wrong idea about what this means. This is because everything changes as you begin to understand the small idea that makes a huge difference.
What looks like one single instruction could actually be a thousand and that's what gets us from “Hello, world” to “Hello world of Warcraft” and what's gets us from, “I can instantiate one object” to “I can make an iPhone app”. Here's one way to think about this.
Imagine you had to do some work in a programming language that was so limited that the only kind of output the language actually provided was the ability to draw a single dot on the screen, that you could write a statement that would turn on one pixel at one specific X and Y position. So many pixels in and so many pixels down, but that was it. Fig 6.1.1.
Fig 6.1.1: A single dot is drawn on the screen
This is certainly limiting, but if you think about it for a moment, you might realize, well, if I can draw one dot, I could draw 20 dots one after the other. So why don't I do that inside a loop and draw a line, wrap that up and now call it my drawLine() function and I can call that when I want to. See Fig 6.1.2.
Fig 6.1.2: A single line is drawn on the screen using a simple code
Then you think about it a little more, and you decide to make this a function that takes some parameters so you can provide a different start and end position, and then figure out how many dots to draw. Fig 6.1.3.
Fig 6.1.3: A single line is drawn with a function that takes some parameters (a different start and end position)
Now this would take a little more thought, a little more calculation, but with a few hours at it, you could end up with a draw-a-line function that could draw horizontal, vertical and diagonal lines. So far so good. Fig 6.1.4.
Fig 6.1.4: A draw-a-line function is used to drawn horizontal, vertical and diagonal lines
But the great thing is when your college says to you, oh hey, you figured that out. Well great. I'm not even going to look at your draw line function, but I'm going to use it and a bit of my own logic, call it four times, draw four lines and make a new function called draw a square.”
Fig 6.1.5: A drawSquare function is used to draw a square
Then your other colleagues says, well, I'm going to take both of your functions, add a little code to draw two squares and a few extra lines and I'll make a function called draw cube. Someone else takes that drawCube function, add a little bit more code to it and puts it in a loop that draws it at a slightly different position every time.
What you end up with is that a new developer could walk in and find they could write one line of code that says “draw a spinning cube” and get exactly that, just from this idea of developers incrementally building a little bit at a time on top of what's already been done. This is just a tiny example of the power of this, and it's not theory. This is exactly what has happened.
Fig 6.1.6: A drawSpinningCube function is used to draw a spinning cube
From the earliest days of programming, some code was always worth sharing. If a developer had needed to close themselves off in their office for a month thinking about nothing but dates, daylight savings time, leap years and time zones. They've written a whole bunch of code to validate dates and calculate how far one date is from another date. Well, if all that work was good, there's no reason for anyone else to have to do this ever.
Now, somebody else might have obsessed about the fastest way to take an array of integers and sort all the values in it. They've worked through these algorithms, they figured all the different steps, all the potential ways this could be done. Or perhaps, the best way to search through an array for a specific number and return where it is.
Someone else might've built functions that could take a string and convert it to uppercase or converted to lowercase, or tell you if it was a valid URL, or a valid email address. All these kinds of generic functionality and many more all became very desirable.
Fig 6.1.7: A library of generic functions written by different programmers
So, this kind of code was all collected together, but what do we call it? Because this might be code but it's not a program. We don't want to run all these things just by themselves. We want to be able to use them from our code. The most common term for this is a library. It's a collection of pre-written functionality intended to be shared and used by other programs. A few languages use a term like module, but library is generally understood.
Now when we write our own programs, we can use this library. We can have it all available. One distinction: using a library does not just mean, hey, here's a file full of source code for you to copy and paste as you like. The point of a library is that it's complete. Somebody else has thought about this, they figured out the algorithms, the steps, the ways accomplish all these tests. They wrote the code and that code has been battle-tested and optimized often over many years.
If you're using a compiled programming language, the library will have already been compiled into machine code. You may not have access to the source code, even if you did want to look at it, which most of the time you don't.
So,
when using a library, you often need to read some documentation to find out what's available in it, what the functions are called and how you would call them.
But it's not about copying and pasting somebody else's source code. Instead, you just link to or import that library from your program. Often, it's a single line in your source code, like import or include, and by adding that one line, everything in that library is made available to you and your source code.
Fig 6.1.8: The two types of library
This is the first kind of general or generic library and is often called the standard library of a language. The first libraries were general ones - generic tasks you might want an any kind of program. They make it easier to work with dates, times and text. They may contain useful mathematical functions and ways to make it easier to read and write files from the hard drive. It might include ways to help deal with errors and they might include things like multi-threading, the ability to do multiple things at the same time, or include new collections, or other the ways to group data together.
Fig 6.1.9: The standard C++ library
Some libraries are more specialized. They are libraries not everybody needs. They’re perhaps a library full of code to help you work with audio or just 2D or 3D graphics, a library to help connect to databases, or one that's full of ways to work with web pages (HTML) or a library to help you encrypt or decrypt things.
The term standard library is used for C++, Ruby, Python and many others. If there is a standard library it's just taken as a given, that whatever program you ever write in that language you're using that library. You can basically consider it part of the language but after that any other library is optional. It's up to you.
Now in some of these discussions you will also hear the word framework. It’s a similar kind of idea. Some people use these words framework and library casually and interchangeably. There are two differences.
First, you easily see the word framework applied to a well-defined, specific situations like a framework for building websites like Ruby on Rails or AngularJS, framework for making desktop applications, or a framework for creating a phone application. What that means, as the name might even suggest, is when we choose to use a framework, we are choosing it because it provides a lot of predefined structure for making that kind of application.
It's as if you wanted to build a house and you could click one button and instantly have a foundation, the plumbing and the scaffolding all in place. It's great. It's really helpful. It can save us incredible amounts of time. That's the point of using a framework.
But we must also understand that we are now volunteering to fit our code into that framework. We are handing over some control and we must now play by their rules for this to work.
So that's the key difference. Both frameworks and libraries are pre-written code, but when using a library, we're in charge and we decide when to call it. When we're using a framework, it's in charge and it decides when to call us.
Fig 6.1.10: The difference between libraries and framework
There are two more terms related to this that I want to cover in the next section: SDK and API.