Discovering regularized programming

One of the main paradigms that is used when stepping away from machine code and representing instructions in high-level expressions is structured programming, which is based on the theory proposed by Böhm-Jacopini during the 1960s, when it was proved that any computable function can be modeled using flow control structures, iteration, and subroutines. It was also asserted that the GO TO instruction could be exempted because its use could lead to the development of spaghetti code. One of the recognized promoters of this idea was E. Dijkstra, who covered it in his paper Go To Statement Considered Harmful.

Following this paradigm, we can design flow charts that represent our program's logic in a more readable fashion. This allows programs to be developed in a more efficient, trustworthy, and legible manner:

Figure 1.3 – Basic structures proposed by the structured programming paradigm

This paradigm was used by IBM investigator Harlan Mills to develop an indexation system for The New York Times investigation files. It was a great success and gave birth to other companies who had started to adopt the paradigm with enthusiasm.

A new age had arrived and code had become easier to write. The problems at hand could be reduced using a series of structures and diagrams.

Afterward, we saw the imminent arrival of structured design, modularity, and modular programming because of the use of structured programming in more complex settings, thus dividing the problem at hand into more straightforward, smaller problems, and these into other, simpler problems.

This happened in the middle of a golden age for programming that gave birth to more programming languages and more compilers, allowing us to abstract the complexity of the architecture where programs would be executed. IDEs and high-level tools were also that reduced the entry barriers for writing code, taking programs to the many industries that existed at the time.

In the next few years, we saw the uprising of new paradigms such as object-oriented programming (OOP), which represented programs as systems containing entities with properties, behaviors, and states. It intended to apply mental models to problem solving since it was easier to represent the problem in terms of their objects, properties, interactions, and the effects of these interactions.

With OOP, not only mathematical or automation problems could be shaped, but more complex systems could be represented through software, allowing us to reuse mental models or knowledge about the industry and transfer it to an application. However, because of this, we had to worry about remembering and following the state changes of all the objects that had been created during the application's entire life cycle. This implies that even though it's easier to model a real-life system through entities and their interactions, we also have to deal with the language's technical complexity and abstraction issues.

Many years have passed since those days, and we've witnessed the appearance of many other paradigms, the fall of some models, and the revindication of others that seemed like they'd never come back. Technology has also changed – nowadays, problems are more complex, and the internet has taken great relevance in software development. Today, we need to write code much faster to comply with the pace of the changes that are being made, but we also live with what we've inherited from the predecessors of the first designs, architectures, and models, even though we also have many open problems from more than 30 years ago.

Bosque proposed that we go a step further and, just like structured programming, presented a new way to simplify the code writing process through regularized programming. This enhanced the legibility, productivity, and code analysis process, and also helped simplify existing models. This starts with throwing out the source of the mistakes that come with accidental complexity, making it easier to implement formal reasoning models to code. Bosque proposes that we rethink the way in which we build programming languages from a perspective similar to structured programming, with the goal of simplifying the code writing process, thus enhancing its legibility, reliability, and productivity.

This simplicity is a consequence of eliminating the sources of accidental complexity, avoiding the unexpected behavior of our programs, and providing a deterministic perspective for writing code. This new design favors translating formal reasoning models into source code. As a result, we have a new paradigm called "regularized programming."

In the next section, we will understand the advantages of eliminating complexity in programming languages