4.4 KiB
Eternal Language
I recently followed multiple discussions around a similar concept. Retro compatibility, languages, etc…
I would like to provide a better definition for "Eternal Language".
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.
So any new feature introduced in the language should not break anything.
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?
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:
- Have a minimal core for your language.
- Finish the compiler (only fix bugs)
- 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.