also not sure it could fit into paradigm shift , but also if you take C and cpp in the context they have been made, they are mostly designed toward developing single threaded console application, in the sense if you want to develop a console application, you have everything you need wrapped in the libC and C language , file system, memory allocation, and the stdin/stdout, string manipulation and basic math function, so that you can code some console application in a completely cross platform manner
and C is pretty much the only language that can be used to develop operating system, from the lowest level, without using even any ASM or hardware/cpu specific thing, it was the goal of C originally, to provide a standard language to code operating system and application thing without having to depend on any cpu or architecture specific thing
now if you take it to nowdays, most application are windowed, and multi threading will become more and more common, and there is nothing to handle that in the libC, so you have to deal with system specific thing for that, which is not really in the original spirit of what C was for
it would be totally in the line of original thinking of the C language that you would have some kind of window and graphic management into it, like you have stdin/stdout, printf, any C application is supposed to be run in the context of some kind of console with an input and an output , which could be transposed to windowed environement, and having equavalent of the stdio made to handle windows, and to have C that are natively made to be run inside of a windows, to manage events , and output inside of a windowed environement
and the importance of the libC is not to be neglected, it's what make C so powerfull, and able to bypass assembly/system level of programming, and the STL is not equivalent, because the compiler doesn't understand the STL objects and functions, like for example if you do " c = cos(x); " you don't say 'call the sin function with the parameter x' but 'do a sinus', which make in sort that if you have "c=cos(x); s = sin(x); " the compiler is able to use the fpu instruction 'fsincos' to compute both, because he know what the function is about, and he can do global scale optimization to a whole routine, because he know what the function are about, moreoever, the compiler will often be able to replace some algorythm by a call the a libC function, like if you make a loop to set all element of an array, he can replace with a memset, , which is not the case with the STL, they are trivial example, but it's still important dimension of how C language works, as well as c++, to have a base tool box of basic operation a program
should use to avoid to have to use cpu or system specific code
like let say you have a calling convention like __async in the same manner that you have stdcall or cdecl , it could be able to insert automatically a call to the libc function to create thread, and mannage more or less automatically concurent access to the variable inside the loop, and having a whole compiler level understanding of the asynchronous dimension of the program, and handle himself all the lock and parallellization on a global program level, and being able to organize itself all the memory sharing and interlocking with some language specification, that could also include vectorization with a native C type if the cpu can handle it, it would not even be paradigm shit, but just apply the original C paradigm to modern hardware and system requirement, to be able to develop application in multi tasking multi threaded windowed environment with the same ease that C was supposed to provide for console app
nowday it would be rather great to have an equivalent of stdio , like win_in, win_out, and the basics of graphic rendering function embeded into the libC, or libstdcpp , even if they are not mapping the whole possibility of each system and not the most performent, it would really be cool to have some sort standard to manipulate image, dialog, basic rendering function, and windowing into it, even if it's bit different from console environment, because in console environment, the program is run from the console, whereas in windowing environment the program created his own windows by itself, and not run 'from it' , it would need that the user create windows and then launch application into them, but it could be made in sort to have an handle to the root node like the desktop, to be able to create windows and manipulate rendering context from within the C/C++ language with a standard interface , at least for basic operation of imaging, blitting, and some basic dialog, like it is with the stdio for console application