125 lines
5.4 KiB
Org Mode
125 lines
5.4 KiB
Org Mode
#+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.
|