If the books won’t satisfy you, you can still ask individual questions here. But, as philh said, there is a chance that fully understanding something requires one to actually use it. Otherwise, your understanding will only be powered by analogies, and it will stop at the moment when there is no convenient analogy for something complex (that is, complex for people who never used it, but kinda intuitive for people who use it regularly), or you may misuse the analogy beyond its purpose. Also, you will be unable to distinguish between correct answers and wrong answers. -- That said, I am curious how far you actually can get like this.
For example, I’ve had three people try to explain exactly what an API is to me, for more than two hours total, but I just can’t internalize it.
API is a list of functionality you are supposed to use (because the authors guarantee it will keep working tomorrow), as opposed to functionality that is either inaccessible to you (therefore you can’t use it directly) or is technically accessible but you shouldn’t touch it anyway, because the authors make no guarantee they won’t change it tomorrow.
More generally, this idea of distinguishing between what is meant for use by others, and what are the internal details the others should not touch, is called “encapsulation”.
Encapsulation can happen on multiple levels. You have small units of code, let’s call them classes, which provide some functionality to the outside world, and keep some private details to themselves. Then you can compose a larger unit of code, let’s call it a module, out of hundred such classes. Now there is a functionality that this module as a whole exposes to the outside world, and some details it wants to keep private. Then you compose the entire program or library out of dozen modules, and it provides some public functionality. API usually refers to the public functionality on the level of program or library.
Analogy time:
Imagine that I am a robot that offers some useful service. For example, I can remember numbers. The officially recommended way to use me is to come to my desk and say “Remember the number X” (some specific number, such as 42) and I will remember it; later you can come to my desk and say “Tell me the number I told you the last time” and I would tell you the number (42, in this case). The list of commands you should officially use with me is my API.
You can either use my services as a person, or you can send your own robots to interact with me. My behavior is the same in either case.
Now you are a curious person, and you notice that when you tell me a number, I will write it down on a piece of paper. When you ask me later, I will read the number from the paper. This inspires you to make an improvement to your process. You tell your robots that instead of asking me about the number, they should simply look at my desk and read the number on the paper. This is 40% faster, and that makes you happy!
Five weeks later, your factory stops producing stuff. It takes you a few hours to find out why. The robots that occassionally come to use my service, keep staying frozen at my desk and never return. That’s because there is no paper on my desk anymore.
You complain to my owner and threaten to sue them. But my owner shows you the original contract, which specifies that you (or your robots) are supposed to ask me about the number; and there is nothing there about a paper on the desk. When you ask me, I give you the right answer. It’s because this morning I was installed a new memory, so that I don’t need to write things down anymore. (Which by the way makes me now 80% faster than before.) All other users of my services are happy about this change. Only you are mad, because now you have to reprogram all your robots that interact with me, otherwise your factory remains unproductive. It takes you three days to reprogram your robots, which means a great financial loss for you.
End of analogy.
The lesson is that when the user limits themselves to stuff they are supposed to use, it allows the service provider to make improvements, without breaking things. The only way to allow future improvements is to make some parts of the operation forbidden to use for the customers; otherwise you could not change them, and you can hardly improve things if you are not allowed to change anything.
If the books won’t satisfy you, you can still ask individual questions here. But, as philh said, there is a chance that fully understanding something requires one to actually use it. Otherwise, your understanding will only be powered by analogies, and it will stop at the moment when there is no convenient analogy for something complex (that is, complex for people who never used it, but kinda intuitive for people who use it regularly), or you may misuse the analogy beyond its purpose. Also, you will be unable to distinguish between correct answers and wrong answers. -- That said, I am curious how far you actually can get like this.
API is a list of functionality you are supposed to use (because the authors guarantee it will keep working tomorrow), as opposed to functionality that is either inaccessible to you (therefore you can’t use it directly) or is technically accessible but you shouldn’t touch it anyway, because the authors make no guarantee they won’t change it tomorrow.
More generally, this idea of distinguishing between what is meant for use by others, and what are the internal details the others should not touch, is called “encapsulation”.
Encapsulation can happen on multiple levels. You have small units of code, let’s call them classes, which provide some functionality to the outside world, and keep some private details to themselves. Then you can compose a larger unit of code, let’s call it a module, out of hundred such classes. Now there is a functionality that this module as a whole exposes to the outside world, and some details it wants to keep private. Then you compose the entire program or library out of dozen modules, and it provides some public functionality. API usually refers to the public functionality on the level of program or library.
Analogy time:
Imagine that I am a robot that offers some useful service. For example, I can remember numbers. The officially recommended way to use me is to come to my desk and say “Remember the number X” (some specific number, such as 42) and I will remember it; later you can come to my desk and say “Tell me the number I told you the last time” and I would tell you the number (42, in this case). The list of commands you should officially use with me is my API.
You can either use my services as a person, or you can send your own robots to interact with me. My behavior is the same in either case.
Now you are a curious person, and you notice that when you tell me a number, I will write it down on a piece of paper. When you ask me later, I will read the number from the paper. This inspires you to make an improvement to your process. You tell your robots that instead of asking me about the number, they should simply look at my desk and read the number on the paper. This is 40% faster, and that makes you happy!
Five weeks later, your factory stops producing stuff. It takes you a few hours to find out why. The robots that occassionally come to use my service, keep staying frozen at my desk and never return. That’s because there is no paper on my desk anymore.
You complain to my owner and threaten to sue them. But my owner shows you the original contract, which specifies that you (or your robots) are supposed to ask me about the number; and there is nothing there about a paper on the desk. When you ask me, I give you the right answer. It’s because this morning I was installed a new memory, so that I don’t need to write things down anymore. (Which by the way makes me now 80% faster than before.) All other users of my services are happy about this change. Only you are mad, because now you have to reprogram all your robots that interact with me, otherwise your factory remains unproductive. It takes you three days to reprogram your robots, which means a great financial loss for you.
End of analogy.
The lesson is that when the user limits themselves to stuff they are supposed to use, it allows the service provider to make improvements, without breaking things. The only way to allow future improvements is to make some parts of the operation forbidden to use for the customers; otherwise you could not change them, and you can hardly improve things if you are not allowed to change anything.