her.esy.fun/src/posts/0022-eternal-language/index.org

#+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


The oldest code I ever wrote was probably in logo, then in Basic.
Then I learned Turbo Pascal, then C, but also awk, csh, bash, etc…
And for most of these programs, I am pretty confident, that taking the
source code and using it today will still work as I would expect.

Then during my PhD, I wrote a quite extensive C++ program.
And, this was probably one of the first time I used extensively a library.
But, a few years later, I couldn't make my code compile.
I updated my code to make it work again.
But today, I wouldn't be surprised to learn it doesn't work anymore.
Why? The compiler will not accept some of my code, the library might have a
few issues.
Whatever, it is difficult.

I think, most of my application code suffer from the same issue.
The ecosystem of the language evolve, but if I don't take care of my code,
it rots.
But really fast.

Wouldn't it be nice to be able to know that a code you write today will
still be usable in 10, 30 or 100 years?
Could this be possible looking at how our industry is going in the opposite
direction?

Have you remarked how difficult it is to have something now.
I mean, really have an object that you know, could be passed to your
children that they themselves pass to theirs for many generations.

In particular in the Software programming industry, or community at large.
This remark is not only valid for the industry but for the science as well.
See how it was difficult to reproduce AI experiments.
See how difficult it is for a searcher to provide the same stable testing
environment he has locally.
Worse than that.
The code they provide will almost not be compatible with the future
environment.
And imagine someone has a great new idea to update an old idea.
It will not be able to use a recent library on the old code.
So having a nice reproducible environment is not enough.

Where are the Joconde of the XXIth century?
Where are the thinker in the Software world?

We should strive to find, if possible a single, "Eternal Language".

#+begin_definition
*Definition:* An /eternal programming language/ is a language both backward and
forward compatible.
#+end_definition

Backward compatible: using code from v1 will work with v2.
Forward compatible: using code from v2 will work with v1.


- *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.