Around the year 1992 there was a drastic event in the domain of software programming. The former well standardized Ansi C language has felt of fashion and was replaced by object oriented languages and scripting languages. Until today the fact itself is seldom mentioned and the reason why remain unclear.
A possible hypothesis is, that it has to do with the creation of GUI apps. From a technical perspective a GUI app can created with a library. In the easiest case the curses.h library allows to create an interactive text based application. More advanced software can be realized with GTK+ and the Win32 API. For reason of better understanding let us first focus on the curses.h library.
In contrast to the established Win32 API the curses.h library works out of the box in linux and windows as well and is much smaller than graphical libraries. So it is a great choice for programming a modern user centric application in the Ansi C language. The problem is, that even simple hello world apps written with curses.h are hard to understand and difficult to improve. not because of the library itself or because of the C language but because the subject is complicated.
The typical curses.h application contains of event handlers, keystroke events, multiple windows and object oriented style message parsing. Non of these techniques are created by the programmer itself but they are the logical consequence if the attempt is to create a GUI app on the text console.
If the console.h library is replaced by graphical oriented GUI libraries like GTK+ the complexity will grow further. Before the programmer can write a simple hello world app he has to read a dozens of books with each 1300 pages and even then many new problems will become visible. The situation in Windows and Mac OS is the same.
The only working advice to avoid the complexity of a GUI app is to dismiss GUI libraries at all. Without the curses.h libary only non interactive software can be created which are command oriented but not menu oriented. The average command line tool in Linux like the cat or the grep command doesn't need the curses.h or the gtk library but they can be programmed in the C language style before 1992.
So we can say that no a certain programming language or library has caused the increased complexity but the problems have increases since the year 1992 with the advent of text GUIs and graphical GUIs. Such a proram type is easier to use by the end user but it is very complicated to program it in software. There is not a single programming language or library available for this purpose but lots of different approaches were created over the years. And all of them are very complicated to use. Easy self claimed lightweight GUI toolkits like FLTK which are reduced to a minimum of features will need 100 MB to install the package and the documentation contains hundred of different methods and classes.
The advent of object oriented languages like C++, RAD Tools like Visual studio and JIT languages like C# wasn't a coincidence but it was the natural answer to the problem of creating GUI programs. It is not possible to write a modern GUI app the same way like a c program before the year 1992. In theory it is possible to write a GUI app with the c language, for example with the win32api or with the gtk.h library. BUt the resulting program will look the same like a complex C++ app which was scripted with additional languages. It seems, that the requirement itself to write a gui app is the cause of the complexity.
Programming in the classical ”before 1992” style is only possible in the case of command line programs. It seems, that the growing complexity after this years is caused by the objective to write the mentioned GUI apps.
This thesis would explain why the amount of GUI apps for Linux is low or even zero. The cause is that for creating a GUI app a huge amount of manpower and additional tools is needed. The best design decision is to avoid GUI apps at all and program only command line tools. Such piece of software can be written in ansi C,, will need a short amount of codelines and is easy to understand.
Let us give a simple example. A state of the art method to create a GUI app in Linux would be to use the Java language in combination with additional libraries and RAD tools for creating the buttons and widgets. The programmer has to install around 10 GB of software before he can create a simple hello world app which is doing nothing. This kind of workflow isn't a sign of failure but it is the best practice method. The cause is, that programming a GUI app is a complicated task and a complicated workflow with lots of layers and bloatware languages is the only way to handle it. Even if the user prefers a lightweight programming environment like Forth he will run into the same problems if he likes to create GUI applications.
The cause why software engineering before the year 1992 was so much easier was is because during this period GUI programs were not available. The typical program in that time was a MS-DOS game in single user mode or a unix command line tool without any interaction. Writing such pre-1992 apps is much easier. A normal c compiler is fits perfect to the problem.
What all the GUI apps in all operating systems have in common is, that they are large scale projects. No matter if the program was realized in C++, java or ansi C and no matter if it was programmed for Linux or Windows and every single case the average gui app will need 100 MB and more on the harddrive, contains of 100k and more lines of code and depends on lots of libraries.