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