Identifying the need for another language
Some of the most frequent questions programmers ask during their early learning years are "Why are there so many programming languages?," "Why don't we just use the same language for everything?," and "Why do we keep creating more programming languages?". A useful analogy to explain the diversity of the programming languages that exist today is to imagine programming languages as musical instruments. We have string, wind, and percussion instruments based on different physical principles; in the same way, programming languages are designed based on different architectures and paradigms. However, instruments or programming languages are often used to generate structured and ordered compositions.
We cannot objectively say that a guitar is not appropriate to play the fifth symphony by Beethoven, since we could only give an appreciation for this based on our personal tastes. In the same way, choosing a programming language might not represent preferring syntax or specific expertise.
But it is also true that interpreting some compositions without the appropriate instrument could be an arduous task, and it could mean sacrificing a big part of the piece due to the physical limitations of the instrument's design. A similar scenario unfolds when we're trying to use programming languages to do things that they were not designed to. Often, this could mean putting in a tremendous technical effort, or having to sacrifice performance, productivity, or stability.
In summary, The Four Seasons by Vivaldi can be beautifully played with a violin and maybe not with a drum; similarly, R rather than Lua could be much more suitable and efficient for statistically analyzing information, while Lua is better for extending Nginx servers instead of Ruby. Although we can use the same tools for everything, they will not always be the most appropriate.
Now that we have a better idea about the diversity of programming languages and their suitability for solving some specific types of problems, the following question arises: "Why was Bosque created?"
When it comes to developing high-level programming languages, one of the main objectives has always been to try to simplify the process of writing code so that it's as close to human language as possible. This allows us to simplify the process of giving instructions to machines using the potential of human reasoning.
But generally, each continuously evolving process implies an increase in complexity, and this complexity may cause mistakes, in the same way that programming languages have been acquiring characteristics that make them complex and prone to causing hard-to-identify errors. By learning from the past and questioning the actual complexity of programming languages, Bosque was born. To solve this and to learn from the past, as inspired by the impact generated by Structural Programming in its day, Bosque was born as a new programming language that eliminates accidental complexity.
As a result, we have a coding process that's more straightforward, predictable, and readable. This allows programmers to focus on the most important stuff or the main program logic, thus improving productivity and making software more reliable.
In the words of Bosque's creator (Mark Marron):
Now that we understand why Bosque exists, lets learn how it builds an executable program from high-level source code.