Each programming language has different syntax for handling different scenarios and means of problem solving. However, at eons, we believe the richness this ecosystem provides is contrary to our goals of universal accessibility and sustainable development. As professionals, we view programming as a science with an achievable “best language” rather than as an art with numerous interpretations.

In pursuit of the best programming language, we follow the same rules as we do for development:

  1. Consistency and documentation are paramount: as much as possible, code should look and read the same regardless of the language used or project at hand and all idiosyncrasies should be thoroughly explained.
  2. Variations and deviating forks should be merged upstream: once the problem a language solves is proven to work, its improved syntax should be made available to all other languages.
  3. Incompatible optimizations are provided equally: users and target systems may select the syntax variations they prefer based on what is best form them, not those which are forced by the language.
  4. Code bases are universally accessible: developers should synchronize with the code base in a way that provides the developer with a language and style of their preference and provides the code base with a single and expected language and style. Not all people are they same and catering to different languages, disabilities, and backgrounds is not the responsibility of the developer; developers, as people, should read and write code in a way that is best fit for them, and that code should be (or become) consistent with the code base they are working on. Thus, reading code and style are the individuals responsibility.
    This implies:

    1. Code style should be strongly but smartly enforced by the code base; e.g. tabs are better than spaces as they give individuals more freedom in how to read the code, but if tabs are elected as the governing style, spaces should not be allowed and vice versa.
    2. Developers must employ and use a system for translating their personal preferences into the governing style of the code base; e.g. spaces must be converted to tabs or Chinese must be translated to English before code is merged upstream.
    3. The code base should be written and styled in a way that maximizes the freedom of individuals; e.g. translations for different languages should be made applicable and difficult words should have definitions available.

Looking to the future, it is a goal of eons to merge binary and non-binary coding systems into a single, comprehensive, and universal language. For example, in order to facilitate the advancement of our species, we intend to develop a means of compiling ribonucleic and deoxyribonucleic acids (RNA & DNA, respectively) with the full power of current software development techniques, including version control, automated testing, continuous integration / continuous delivery (CI/CD), etc. This goal will be infeasible, at best, if there is not a consistent means of writing code for binary, quaternary, n-ary, n-imal, etc. compilation targets and any number of compilers there-of (n-imal is meant to describe systems like “decimal” but of any base, not just 10).

You may track our progress toward this goal on our website (eons.llc), specifically projects like Develop Biology, the Bio Build System, and Bio Programming.

We realize that rebuilding the Tower of Babel is not likely a possible task but we do not take that as a reason not to try. Who knows: maybe together we can do the impossible.