diff --git a/src/posts/0022-eternal-language/index.org b/src/posts/0022-eternal-language/index.org
new file mode 100644
index 0000000..1e28133
--- /dev/null
+++ b/src/posts/0022-eternal-language/index.org
@@ -0,0 +1,98 @@
+#+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
+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
+
+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.