#+title: Eternal Language
#+description:
#+keywords: blog static
#+author: Yann Esposito
#+email: yann@esposito.host
#+date: [2021-11-15 Mon]
#+lang: en
#+options: auto-id:t
#+startup: showeverything

I recently followed multiple discussions around a similar concept.
Retro compatibility, languages, etc…

I would like to provide a better definition for "Eternal Language".

#+begin_definition
*Definition:* An /eternal programming language/ is a language for which code
written today will still compile and work any time in the future but also
in the past.
#+end_definition

So any new feature introduced in the language should not break anything.

By this definition it provide a great deal of constraint on the language
but provide a tremendous amount of advantages.

As a professional developer it will provides stability.
The work you done today can be forgotten.
Even if the quality of code is not perfect, if it works, it works.
No need, to change unless a new major security issue is discovered.

There are a few programming languages that try to achieve this.
So, by their nature it is normal to have a period of adaptation during
which a language is not Eternal.
The code will break with convention from the future.
Or new feature will be added to the language in the future that will not be
supported today.

Eventually, when a language is used professionally, most would really
appreciate if a language reach the "Eternal Language" status.
There are a few examples I like:

- *TeX*, once written, it was never updated. It contained everything it
  needed. The project was over, and there is an active philosophy of
  software at hand about having a finished program. It does one thing as
  perfectly as possible. Any new feature should be build around TeX, but
  TeX in itself must not be changed. This is an Eternal language reached by
  this culture of providing a finished product.
  Note how different this is today. The first reaction of many people to
  check if they should use a tool or a software is to look at the activity
  of the repository. And if there is no activity, they see that as a sign
  of dead project. Depending on the project this is better to check that
  there is no activity at all.
- *C*, here Eternal Language is reached via a specification

Almost Eternal Languages:

- *Clojure*, this is almost the same kind of philosophy at hand. But it is
  not yet an Eternal language. Clojure introduced a few new feature that
  will not work in the past. But, this is close to be an eternal language.
- *go*, I dislike this language as to me this is like a new *C* without much
  more to it. We can do so much better regarding new languages this sadden
  me people chose it. But the *go* community takes API retro compatibility
  very seriously, and thus, it sounds like it is close to reaching the
  status of Eternal Language.

The opposite of Eternal Language

- *Haskell*, every new GHC upgrade break something. Every new lib update
  break something. People tried to mitigate this via tools. But the real
  issue is due to how the community works. I am myself guilty of breaking
  library API.
  Clearly, as much as I love Haskell, the best you can achieve is a freeze
  in time environment. But this is often a major problem. Because if you
  want to build an application that will adapt to new concerns, eventually
  you will want to use a recent library. And by doing so, you will need to
  upgrade your environment that will forces you to upgrade the libraries,
  the compiler, and will forces you to change many parts in your code that
  you would probably have preferred to forget as a stable asset.
  And quite recently the Haskell community was heated by that.
- *Purescript*, as the updates occurs with slower pace, this is more
  sustainable, but this is still a major concern.

Both Eternal and opposite of Eternal Language;

- *Javascript*, while javascript in itself is close to be an eternal language.
  node.js / npm, etc… The community makes it completely the opposite.

** How to reach Eternal Language?
:PROPERTIES:
:CUSTOM_ID: how-to-reach-eternal-language-
:END:

I am not a specialist of these questions, so my advice will probably be
naive to the extreme. But here is how I imagine a list of mandatory properties:

1. Have a minimal core for your language.
2. Finish the compiler (only fix bugs)
3. Have a language with huge adaptability principles built into it. Like
   LISP with macros for example. Macros are a way to trick LISP to use
   another language within the core language.
