Niklaus Wirth was right and that is a problem

Wirth’s law is not really a law. Actually, none of them ever are laws. They are adages:

Here is another law that is not a real law: Moore’s law is the observation that the number of transistors in a dense integrated circuit (IC) doubles about every two years.

This means that we can expect the speed and capability of computers to increase while lowering the costs. Sadly, this is where Wirth’s law comes in:

And while Moore’s law has proven to be true since 1975, Wirth’s law seems to be true as well. Niklaus Wirth, the designer of Pascal, wrote an article in 1995:

The problem of modern software development is manyfold. Wirth points out one crucial aspect: time.

And while that was true back in 1995, that is no longer the most important factor. We now have to deal with a much bigger problem: abstraction. Developers never built things from scratch, and that has never been a problem, but now they have also become lazy.

It was Edsger W. Dijkstra who tried to improve the quality of code and coined the concept of structured programming . He tried to get programming out of the state of crisis it was in, and he found support in programmers like Harlan D. Mills, Richard C. Linger and Bernard I. Witt. For a short period of time, programming was seen as a real craftmanship. Programmers cared about the quality of their programs, and that included clarity and efficiency.

Those times have passed. With the introduction of higher-level languages such as Java, Ruby, PHP and Javascript all in 1995, the same year in which Wirth wrote his article, programming became more abstract.

Languages like these made programming a lot easier and took many things out of the programmer’s hands. They were object-oriented and came with things as an IDE and garbage collection.

This meant that programmers had fewer things to worry about, which is of course great. Sadly, everything comes with a price. Having fewer things to worry about, also means having fewer things to think about. 1995 was the year in which programmers stopped thinking about the quality of their programs.

It also marked the beginning of the widespread use of libraries, probably one of the bigger problems. Don’t get me wrong, I love libraries. They are the only reason I am able to get things done. However, a library never comes with the exact things that you need.

Because a library is not made for one specific project, it probably has a bit more functionalities than you really needed. No problem, you would say. However, things pile up pretty quickly. Even the people who like libraries, don’t want to reinvent the wheel. This results in what we call dependency hell. Nikola Duza wrote a post about that issue in Javascript .

The problem does not seem that big, but try to grasp what is happening here. In another tutorial that Nikola wrote, he built a simple todo-list. It works in your browser with HTML and Javascript. How many dependencies did he use? 13,000.

These numbers are insane, but this problem will only keep increasing. As new, very useful libraries keep being built, the number of dependencies per project will keep growing as well.

That means that the problem Niklaus was warning us about in 1995, only gets bigger over time.

And no, you don’t have to learn assembly and start writing your web application in that. A good way to start would be to split up libraries. Instead of creating one big library that does everything you could ever possibly need, just create many libraries. Your god-like library could still exist, but solely as a wrapper.

This way a programmer only has to select the libraries he really requires, while ignoring the functionalities he is not going to use in his application. Not only are his dependencies smaller, but they will also use less of their dependencies because the dependencies of the unused functionalities do not have to be installed.

Note:The proposed solution obviously is not the solution. It would for example require a good way of versioning software to avoid a new dependency hell.