Progress happens slow in the short term and fast in the long term.
In the 1980s, there was a consensus that "software components" enabled by object orientation were a pipe dream.
They were so long as you were using C++ which was barely binary compatible and where you couldn't reuse objects in a .so file without also having an .h file. It was awful, not at all a minimal viable product.
Then Java came along and a number of other languages that adopted essentially the same model for OO programming such as Python, PHP, Ruby, C#, etc.
Now you can cut and paste a few lines of XML into Maven and woohoo... You've incorporated a software component into your system.
People bitch that it has to be XML, but the sheer ease of doing so means it is not hard at all to get 100+ dependencies in a project and now the problem is dealing with the problems that come when you have 100+ dependencies.
(And of course the same is true with npm and every other language that has similar tools.)
Two big themes are: (i) tools that reduce the essential difficulty of software development and (ii) antiprofessionalism in software engineering.
Compilers like FORTRAN mean you don't need to have the intimacy with the machine you need to write, say, Macro Assembler. That is mainstream, but other technologies, such as logic programming and rules engine are still stillborn. In theory tools like that mean the order of execution does not matter so much so you don't need the skill to figure out what order to put the instructions in. Practically they are yet to become vernacular tools that are palatable to programmers and non-programmers. (Anything programmers can't stand will be 10x more painful to non-programmers, I can tell you that!)
Anti-professionalism is another big theme. Had computers come around 20 years earlier we would probably have a programmer's union, licensing and other things that would make a big difference in our lives. As it is, the beef that programmers have is not that we don't get paid enough, it is that we are often forced into malpractice by management.
In the 1980s, there was a consensus that "software components" enabled by object orientation were a pipe dream.
They were so long as you were using C++ which was barely binary compatible and where you couldn't reuse objects in a .so file without also having an .h file. It was awful, not at all a minimal viable product.
Then Java came along and a number of other languages that adopted essentially the same model for OO programming such as Python, PHP, Ruby, C#, etc.
Now you can cut and paste a few lines of XML into Maven and woohoo... You've incorporated a software component into your system.
People bitch that it has to be XML, but the sheer ease of doing so means it is not hard at all to get 100+ dependencies in a project and now the problem is dealing with the problems that come when you have 100+ dependencies.
(And of course the same is true with npm and every other language that has similar tools.)
Two big themes are: (i) tools that reduce the essential difficulty of software development and (ii) antiprofessionalism in software engineering.
Compilers like FORTRAN mean you don't need to have the intimacy with the machine you need to write, say, Macro Assembler. That is mainstream, but other technologies, such as logic programming and rules engine are still stillborn. In theory tools like that mean the order of execution does not matter so much so you don't need the skill to figure out what order to put the instructions in. Practically they are yet to become vernacular tools that are palatable to programmers and non-programmers. (Anything programmers can't stand will be 10x more painful to non-programmers, I can tell you that!)
Anti-professionalism is another big theme. Had computers come around 20 years earlier we would probably have a programmer's union, licensing and other things that would make a big difference in our lives. As it is, the beef that programmers have is not that we don't get paid enough, it is that we are often forced into malpractice by management.