5.4 KiB
Eternal Language
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".
Definition: An eternal programming language is a language both backward and forward compatible.
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?
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.