Eternal language first draft
This commit is contained in:
parent
cd94e215d4
commit
7c592372cf
98
src/posts/0022-eternal-language/index.org
Normal file
98
src/posts/0022-eternal-language/index.org
Normal file
|
@ -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.
|
Loading…
Reference in a new issue