jinnzest / multilanguage-manifesto

Manifesto or main principles to lead developing language specification.

The MultiLanguage

The MultiLanguage is a programming paradigm aimed at creating faster and more robust applications through the automation of routine tasks and reducing complexity by dividing a programming language into several interconnected languages.

All programming languages created until now have attempted to express complex and multi-layered concepts using flat text. Consequently, business logic is always combined with various low-level memory management methods (or even high-level automated ones), control means for execution speed, and other methods for enhancing code durability, etc.

Designing a language that handles all of these aspects simultaneously makes it very difficult to use and raises the bar for entry. On the other hand, designing a language that handles a subset of these aspects leads to a combinatorial explosion of specialized languages that can only perform one task, and the developer has to figure out how to integrate them. This leads to the programmer having to learn many languages to develop a single project, making it more difficult and expensive to recruit a development team. Moreover, each language has its own specific features and pitfalls, reducing the reliability of a system written in multiple programming languages.

Extraction of a minimal core, which any programmer can learn as quickly as possible that does not have implicit and complex behavior, allows a software developer to write programs as fast as possible. Extraction of an auxiliary language responsible for memory management and hardware-dependent optimizations allows writing the most efficient programs without cluttering the business logic code. Extraction of an auxiliary validation language allows validation without complicating the business logic code. The same is true for various other aspects of programming such as algorithmic complexity, memory complexity, etc.

For some auxiliary languages, it is possible to have a separate developer specializing in this aspect of a system (such as the speed optimizer). For projects for which some aspect is not that important, developers can use the default behavior, which is less effective than the one configured by a person but can do without an additional specialist.

At the beginning of a project, a developer can configure a set of auxiliary languages and later add or remove any of them (When a developer disables some aspect, then a MultiLanguage stops generating analytics but still generates default directives). Additionally, it is possible to use auxiliary languages (directives affecting generated code) not for a whole software project but only for specific components. For example, there is no point in optimizing the speed for an entire codebase. Therefore, a developer can use default directives for most parts of a software project and then optimize the most critical pieces only. Etc.

Each of the auxiliary languages, in addition to generating machine code, also generates different analytics. Thus, in contrast to other programming languages, where a programmer needs to keep in mind various aspects of the behavior of a particular language, in a MultiLanguage, all the features of behavior can be checked in the corresponding analytics without being distracted by related aspects. As a result, a programmer does not need to analyze every line of a program from all aspects simultaneously, trying to guess what that line does at runtime. It is enough for a developer to check generated analytics for a system part to check that a directive was applied correctly.

Read the MultiLanguage Manifesto for in-depth details and recommendations.