It's tied in with the whole idea of "frameworks".
Basically, what's happened for a long time (since C became popular) is for people to have "class libraries". This is where people would typically put all the common stuff - you know, the basic routines that people use all the time, and don't want to rewrite all the time. Then the typical way to create an application was to start writing code that calls the routines in these "class libraries".
Along the way, it became apparent to some that we were still rewriting a lot of the same code over and over again. So they got the idea to try and include EVERYTHING that we write all the time in a "framework". As opposed to having a class library full of routines that get called by our application, we have a framework that contains all the common components of an application. Then we only write the parts that are different from other applications. We actually start an application by simply instantiating an "Application" class (or a subclass of an "Application" class). Then this "Application" class has a bunch of hooks (i.e., events and delegates), which allow us to add our custom pieces. Net result is we can build a better application faster.
In other words, instead of creating a bunch of custom code that makes a bunch of calls to a "Class Library", we have a framework that makes a bunch of calls to our custom code. In many respects, it's the mirror-image approach to what we did in C.
When we start looking at things this way, then most of the time, all we need to do is specify little pieces of high-level logic. Everything else is done by the framework. So we actually aren't losing anything as programmers. By contrast, we're gaining, and we can concentrate only on the important logic of our application. All of (or at least most of) the "grungy details" are taken care of in the framework.
Now of course, not EVERYTHING can be done via a high-level approach. So we might still find ourselves breaking out chunks for implementation in some lower-level language, such as C++ or (in very rare cases) even Assembly. But for most application programming, this approach yields FAR better results, FAR quicker, than attempting to do everything via a low-level approach.
