I remember someone asking on here what a good permacomputing language would be to be to learn—to make sure their software would still run in, say, half a century’s time.
A lot of people recommended C. I deliberately kept out of the thread because I didn’t want to disturb anyone or start an argument.
I would recommend Common Lisp. Lisp was discovered in the 50s, and many Lisp programs written from decades ago still run with zero, or minor modifications today.
This is my humble suggestion. There are many benefits to using Lisp as a permacomputing language, such as strong typing, remarkable simplicity of its grammar, and, by its design, exhibits much less undefined behaviour.
My advice would be to seek mastery of:
1. C (plus some basic assembly language)
2. One of the popular Lisps (Common Lisp, Racket, Clojure, etc.)
3. One of the strongly-typed functional languages (Haskell, OCaml, Scala, etc.)
4. One of the dynamic purely-OOP languages (Smalltalk, Ruby).
5. Unix scripting.
And also get some exposure to Forth, Prolog and one of the boring industry languages (Java, C#, Go, etc.).
Do that and you're understand pretty much any language you'll come across.
For example, Scala is a very interesting language, and I would have considered it my favorite at one point. Less than half a decade after I picked it up however, all of the code that I have written in Scala either needs to be compiled using an old compiler, or I need to put in a lot of effort to porting.
I agree with this advice for staying relavent as a career software engineer, but I think the languages that will continue to run as-is is a much smaller list.
Ah, I missed that part.
So yeah, definitely C. One of the major advantages of that language is that (up until the recent standard, anyway) it's pretty easy to implement and also pretty easy to get decent performance out of a mediocre C compiler.
Forth may also be an option, just because it's so easy to implement the core language and because it'll run on really resource-constrained systems.
@suetanvil @robby @vidak The problem with C is that it's easy to write subtly broken code. Whenever there is an architecture specific bug in some package on Guix, it seems to me that it's almost always because someone was doing something weird with C.
So yes, it will compile on lots of platforms, but that doesn't guarantee much about it actually working.
@csepp @suetanvil @robby @vidak C is a headache, because you can quickly stumble into areas where lots of dragons live, without you getting any warning of it before it's too late. I like the suggestion of Forth. Code in Forth often ends up having some stuff for a given system, but it tends to be wired so you can actually fix and port to the next VM without sacrificing a goat or something. Forth is actively hostile to piling on complexity, and _that's_ the key for long term maintenance.
@csepp @suetanvil @robby @vidak Anyway, both Lisp and Forth boils down to “A robust set of abstractions which is likely to be ported to new platforms or can be implemented by a single person in a reasonable amount of time.” I wouldn't want to implement Common Lisp from scratch myself, but I suspect the right people could bootstrap a very minimal system surprisingly quickly. (That would not be _Common_ Lisp, though.) Scheme would be a better bet than Lisp from that perspective, though.
The problem with Lisp-family languages is that while it’s easy to write one that works, it’s very difficult to reach mediocre-C levels of efficiency.
The reason Lisp machines were a thing is that the cheapest computers of the era could support several concurrent users UNLESS one of them ran Lisp; then it took over the machine.
Lisp machines were designed to be CHEAP single-user machines.
So the ideal forever language needs to be:
- efficient (i.e. fast and small)
- easy to implement, even on weird hardware
- type/memory/etc safe
- extensible (i.e. minimal base language used to write the extra features)
- modern (i.e. does the stuff we know works; provides all the common paradigms.)
So how about:
b) a friendlier language that compiles into Forth
c) modern paradigms in b) libraries.
b) is the hard part, of course.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!