As a self-taught programmer I hoped for one of these to explain whatever I needed to wrap my head around "frameworks"--abstractions which make it possible to build the vast diversity of programming development tools built on top of programming languages, while themselves being written in that language.
You can learn about the idioms such as Callbacks and Hooks, but to really grasp how these are organized into frameworks seems difficult for authors. It's easier to just tell you, If you want this effect, Do that. Or, I'm just not getting something about computer science pedagogy; Maybe the domain of programming where I find my interests doesn't teach programming the way I think about learning it. I will dig into this to see what's here.
A framework is kind of like a big template for software applications. A framework gives you a skeleton to work with, where the programmer fleshes out the details in the flexible spots. Except that instead of just some boilerplate code, you have a whole set of libraries and applications.
For a trivial analogy, consider this template for a C program:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
// Your code here.
return 0;
}
It is not technically a "framework" because it's just a few lines in one file, but it's different mostly by magnitude (though also by the fact that it is trivially modifiable). And maybe, if this is an IDE, it puts our cursor right at the line where you're supposed to start putting your own code. Conceptually, what this does is give you a clear place to start developing. It sets up some libraries that you'll probably use defines a main function that accepts arguments and gives you a default return code of 0 (which means success, by convention).
Frameworks essentially do the same thing on a larger scale, and usually with multiple discrete components. The key difference between a library and a framework is that a library is something that the developer imports and invokes, whereas the framework establishes a useful context for a specialized type of development.
CS doesn't really cover software design at the level of programming language idioms like callbacks. The closest it might get is lambda calculus and reasoning about code as graph reduction, where code is just a data structure.
Software engineering might cover design patterns, but even then it's a limited set of techniques with broad application - idioms in practice are tuned to their language and execution environment, because clumsy idioms don't propagate.
Figuring out how to put those things together to make a cohesive library or program is the hardest thing I've had to do on my own. I haven't really found anything that teaches that. There's lots of begginer stuff about syntax and programming concepts. There's some fairly technical abstract stuff out there about algorithms and data structures but not a lot about how to put everything together into a useful program.
The only way I've learned that was to just start making things. Whenever I ran into a problem i'd look up whatever I was having trouble with. It failed a lot. I've had to go back an restart things more than once or endes up giving up on things that were dead ends. Then after a couple years of that I stopped having to quit because i'd completely messed up the idea of what I was doing.
I honestly have no idea if the things I've learned are correct or not but programs I write seem to do what they're supposed to now.
I think the reason why there's not much about how to put programs together is that it's pretty much up to you. There's a million ways to do one thing and most programs have a million things that need to do one thing. You need a good idea of what you would like these things to be. Then you pick one and do it, then another one and another one making sure the first things you made still work with the new ones. If you don't know how to do one of the things either look up and see how other people did it or move on for a bit and come back to it.
A framework, library or program is just input data, either from you or a user, processing of data and output. It's up to you to figure out how to structure these things for the needs of your program.
There is no right way, just whatever way you find that works. You can look at a program like building a machine. The programming language you learned gives you the nuts, bolts and basic materials you need, the algorithms, callbacks and hooks are the different prefabbed parts and you're the mechanic that bolts it all together with a wrench and a whole lotta grease.
You can learn about the idioms such as Callbacks and Hooks, but to really grasp how these are organized into frameworks seems difficult for authors. It's easier to just tell you, If you want this effect, Do that. Or, I'm just not getting something about computer science pedagogy; Maybe the domain of programming where I find my interests doesn't teach programming the way I think about learning it. I will dig into this to see what's here.