I think both OCaml and Haskell are here to stay and are ‘safe’ bets. Erlang will probably still be kicking as well.

Perhaps SML (Standard ML)? Unusually, it has a formal specification of its typing rules and operational semantics, as well as a standard library, all of which are somewhat set in stone. By that I mean that apparently, those specifications haven’t changed in 25 years, even though it is still widely used in certain areas (such as proof assistants). That said, there’s been efforts to improve/extend it, under the umbrella “Successor ML”.

PSA: before proposing your favorite language as a better alternative, make sure to read the previous story to avoid rehashing the same arguments. Thanks :)

Cool blog post Ozymandias. After having my code broken enough times by linux distros I started asking myself the same question. I think the most important things you left out are:

1. Binary. Something like x86-64 is likely to survive. Even a stable language like C there’s still a good chance ABIs will drink your milkshake. So it’s nice to have portable code in addition to portable binaries.
2. Operating systems. Your binaries should run on multiple operating systems. That way if one falls out of fashion, it’ll still run on the others. My binaries run on seven operating systems.
3. Tools. Vendor tools not just dependencies. For example, I always keep a vendored copy of the GCC binaries in my repo. That way my software can build deterministically for everyone anytime. Because compilers break all the time. Even for supposedly stable languages. But the hardware architecture that lets old version of compiler binaries run isn’t going to break.
4. Time. That’s my biggest issue right now. I need to be doing more to audit for instances where I’m using long or long double nanoseconds which will probably only last another 80 years. There’s also Y2036 and a bunch of other ones I need to audit for. Leap seconds are evil. I have to use a zip structure so my binaries can have their tzdata updated if needed. Printing timestamps in general seems to be the biggest hurdle to making a program that can survive until the heat death of the universe.

https://github.com/jart/cosmopolitan

I am looking for an FP language which everyone thinks will last at least 100 years.

What do you mean by “will last at least 100 years”?

Do you mean a program written today will also work 100 years from now? If so, any language (functional or not) would do, because virtualization exists and will exist 100 years from now. (We are still using COBOL…) :)

Or, do you mean a library written today can still be used 100 years from now, perhaps with minimal modifications? Personally I don’t believe this is possible, especially if the library does anything which is not strictly an algorithm juggling some primitives.

In any case, my belief is that the longevity of any language is heavily impacted by its complexity, namely:

• simple concepts and syntax – Lisp/Scheme or even Go (although not functional) will perhaps fare better than C++, Java or Rust; Erlang could fit, but without it’s BEAM and OTP, I don’t see Erlang as a “language” (there are no other implementations);
• self-contained interpreter – the simpler the installation the better (i.e. one binary); as a counter example would be Python or many Scheme interpreters, where you can’t even move them in another folder without breaking;
• interpreted or byte-code compiled (as opposed to native compilation); WASM perhaps;

As for a particular language, I’m hoping Scheme – I’m kind of invested, having written my own Scheme interpreter – however I don’t think this will be the one… (Looking at today’s language popularity I’m afraid it’s going to be JavaScript…) :)

I don’t think this 100 year language has been created yet…

While it’s certainly true that our field has far more inertia than fourty years ago, I’m personally of the opinion that the “100 year program” is not yet the right way to achieve “100 years of usefulness”, and that the right way to get to it is still the “100 year specification”.

I struggled with this myself for the past year or so, after moving my notes/knowledge management system (man that sounds fancy…) to a third solution in about twenty years (HTML via Netscape, later Mozilla Composer, then a wiki, then Markdown). I decided that, at this rate, moving it a fourth time is inevitable, and I’d rather do it for good, so I just wrote my own thing.

My own aims are a lot more modest, I’m aiming for the thirty, fourty years of reasonably good health that I expect I still have left.

Except for terminal programs written in C, I don’t think there’s any 40 year-old tech stack that’s still usable today except through emulators, and even if it were, I don’t exactly want to keep my shit frozen in 2022, that defeats the whole purpose of accumulating knowledge and developing wisdom.

Instead, I settled for a system that will be easy enough to re-implement if I ever need it, and that will still remain useful even while I’m in-between implementations. For example, the “markup” language I use is barely-annotated plain text, supporting hyperlinks and media, but with a little less visual noise than Markdown. If something better comes up and I want to migrate to it, I expect a conversion script would be a few dozen lines. An incomplete implementation (i.e. all of the critical features I need day-to-day, but about 50% of the optional ones) of a WYSIWYG-ish editor for it, including some fancy-ass stuff like in-line LaTeX equation support, is about 1,200 lines of really bad Python, much of which is Tkinter boilerplate. (At its peak it was about 5,000 lines but I ended up dropping a bunch of stuff I figured is better handled separately or not at all, like file browsing and media access and hyperlinking based on unique identifiers).

It runs really fast, too – even with a hand-rolled, extremely inefficient parser, and a mountain of Tkinter workarounds, it happily chugs along on some of my longer documents (a few hundred pages) on which the likes of TinyMCE choke instantly, and the only things it doesn’t support 1:1 are tables and inline display of some types of media, like video. The former isn’t critical for me (I’m okay with plain text tables), and the latter is 100% deliberate (i.e. I don’t want to poorly re-implement video or music players in my program, the way browsers do – the implementation effort with the current tech stack would be minimal, but I think the results would be worse than an optional preview + an “open” button that launches a proper player, which is what it does now). I expect the complete implementation would be about 2,500 lines, with a few warts that I can live with (e.g. document headings aren’t numbered automatically – a feature that’s not hard to implement but I just don’t care about it enough to bother). I wasn’t even planning to use this, I hastily threw together a Tkinter implementation as a proof-of-concept, expecting this would be the initial prototype that I’d use to validate my approach before implementing it using something less obtuse (Qt, or GNUstep if I could remember enough Objective-C). I was expecting it to be slow to the point of uselessness but nope.

The initial implementation effort was about two weeks of working for a few hours in the evening, but much of it was spent figuring out how I want various things done, and I’ve thrown away about 80% of what I’ve implemented in that time. Re-implementing all this from scratch is something that I can probably do over the course of two or three evenings, in any tech stack that I know well. In fact, the first incarnation was based on TinyMCE – it took a long time because I had to (poorly) reimplement all sorts of browser wrappers over native features, but I could’ve probably pulled it off if I didn’t value my time. Two or three evenings even once a year is something I can live with, and is certainly comparable with the effort of resurrecting thirty year-old technology.

I’d second OCaml. Have even in the past run bare OCaml without an OS/kernel, it is very portable. Whilst Haskell isn’t going to go anywhere, even GHC can’t compile itself with any old version of GHC, so that would fail the 100 years test, IMO.

JavaScript. Straight up unadulterated static hosted prototypically architected, build system free, untyped JavaScript. There’s programs I’ve left completely unattended for 10 years that still work on every computer I own, including the 15 year old ones. Nothing this side of C comes close.

A PL is only as long term viable as its runtime envirobment and toolchain. No ‘proper’ FP langs seem to care

Trying to think why Common Lisp isn’t the right answer, though SML is a good one.

Interesting post! Did you consider Common Lisp? I’m not contesting the choice of Standard ML, but CL is something I’ve heard people mention when the question of a “100 year language” comes up. I’m not a CL user myself, but reports indicate a similar experience to yours, eg the language is stable and there’s very little breakage in the ecosystem

I’m not against people using SML, but I feel like the language the post author might have wanted but for some reason missed is the other ML—OCaml. ;)

• It has all the features of SML since they share common origin, but it’s evolving and has many useful features that SML doesn’t (polymorphic variants, local module opens, monadic let operators…).
• MLton is a very slow compiler (it’s whole program optimizing, but as a side effect also slow) and lacks a REPL, which is why people often use a second compiler for experimentation, e.g. SML/NJ that is interactive but can’t produce binaries. OCaml bootstraps itself in ~10 minutes, but the binaries it produces are neither slow nor bloated. It also has a built-in bytecode target and a REPL.
• SML’s packaging is still in its infancy, while OPAM has been a standard way to install OCaml itself and its packages. There are quite a lot of packages, too.
• There’s a musl compiler flavor readily available for building eternal Linux binaries.
• There’s also a mature tool for trans-compiling to JS that can make a JS version of OCaml’s REPL.

I can also personally attest to it being at least a 20% of a 100-year programming language. The Lua-ML project has been dormant for almost two decades. It also makes rather intricate use of the module system and functors to make the standard library of the Lua interpreter reconfigurable.

When I set out to resurrect it, there were very few things I had to update for modern compiler versions, mostly changing String to Bytes when a mutable string was intended. I don’t remember any runtime errors caused by a new compiler. In the compiler, that change was preceded by a years-long deprecation, too.

Generally, both compiler maintainers and library authors take compatibility very seriously. Modules removed from the standard library become OPAM packages. Many third-party library packages has the upper bounds of their dependencies open rather than pinned, and that rarely fails.

Of course, it’s not a perfect language or a perfect ecosystem, but to me it’s quite close.

There’s a lot of difficult trade-offs here, but IMO the clear winner for “functionalish thing that will still be around more or less as-is for the indefinite future” is Scheme. Probably r5rs specifically.

It just is what it is. The spec is quite small and understandable. Countless people have implemented it, in various ways, to various degrees of completion and/or quality (no doubt several people reading this have had a go at some point). It’s pretty aggressively distilled down to its essence and has a philosophy of not bolting on genuine new language features unless it’s completely unavoidable.

Of course, it’s Scheme, so… yes, parentheses, and dynamically typed, and many of the above things that make it a good contender for this “long-lived stability” criteria are also the reasons why it’s not the most practical language to use, and there is quite a lot of implementation variability if you’re not careful to restrict yourself to the actual standard, and and and…

Still though, I have a very hard time imagining a future world where one couldn’t grab a copy of SICP or whatever and fire up some ~r5rs environment or another and get on with programming in much the same way they could have any number of decades in the past, much like C. Scheme is forever, and the almost religious philosophy of not adding special case syntax and piling on complexity to solve problems keeps it that way. One could make similar arguments for many other languages, especially those with a more academic background, but Scheme seems relatively unique in being something defined precisely in what are more or less timeless papers, while also being widely implemented and not a dead language in practice (like, say, SML).

Being a dead language could be considered an advantage here (as another thread is diving in to), but I don’t think that is universally true. An alive language community doesn’t necessarily mean that the language itself will tend to break. That’s at least partially an outcome of the language design itself. Love it or hate it, the hyper-minimalist “lambda is all you get” anti-syntax s-expressions thing of the Scheme world keeps that at bay much more than, say, in the ML-derived world.

Long-term language stability, I think, mainly derives from having a relatively small set of core concepts that everything else is built on top of. You can learn and understand more or less everything that’s in C, or in Scheme, now or 30 years ago or 30 years from now and they’ll still be more or less the same as they’ve always been. It’s the “concept” part that really clarifies this for me: you can even see it in the discussions in programming language communities. C and Scheme forums almost never have topics about entirely new concepts in the language (beyond the superficial anyway, I’m using a sort of capital-C “Concepts” here), the language just is what it is. They are also very stable languages. Meanwhile, C++ and Rust forums are constantly packed with whole new concepts for the language, or why existing ones are bad, or (etc etc etc). They are notoriously unstable languages. This is not a coincidence.

I guess that rambling rant boils down to: find a language where the answer to “what fundamental or syntactic constructs is the community likely to try and add to the language in the future?” is “probably none at all”.

I think there’s a decent argument to be made for Clojure for two reasons:

1. It runs on the JVM. There’s a high likelihood that JVM’s will be running in 100 years, given how much Fortran is running right now.
2. Clojure is a remarkably stable language, with very few breaking changes.

These are not languages which I can step away from and come back to 10 years apart without having to remember things or reading updates.

I don’t know a single language that this wouldn’t apply to.

These are not languages which I can step away from and come back to 10 years apart without having to remember things or reading updates.

This is highly anecdotal, and in direct conflict with your requirement of “closer to Haskell than Lisp/Scheme” and “built on top of C, C++ or Rust”, but I think Clojure might be worth taking into consideration.

I have a personal project that’s 10+ years old, and I tend to work on it at a cadence of a couple of days of work a year — or less. Obviously, my progress on the project is not something to write home about, but every time I come back to it, I’m surprised at how stable the language and the ecosystem are, and how easy it is to pick up where I left off.

Sure, the language changes, but it does so slowly enough to avoid “FOMO” even if I don’t upgrade to the latest version. Libraries and tools come & go, but even the ones that have been replaced by something new & hip still work — they’re either actively maintained or stable enough. The JVM is a decent platform that values backwards compatibility while continuously improving. The community is small, but strong. You can target JavaScript as a platform should you need so, and write parts in Java if performance is a concern.

For what it’s worth, the project I’m talking about is a database-backed HTTP service with a very simple frontend. 100 years is a big ask for anything computer-related, but I could vouch for the 10-year viability of Clojure.

Out of all the languages I’ve working with during my career, Erlang and POSIX shell have felt the most ‘solid’. I can look at a shell script or Erlang program written in the last 30 years and be confident that I

1. can understand it
2. can run it on modern systems

Erlang definitely doesn’t shine in the pure-functional department. Its type system is very lispy, not offering the wonders of what ML-based systems give you. … yet despite all that, it’s a very fun and elegant programming environment, and I could see it hanging around long-term.

I would like to add Prolog, even though it’s logic programming, some idioms are also used in FP. It’s already 50 years old, and the Prolog core is still the same. It was standardized in the 90s and there are lots of systems.

The bad news is that the ISO standard is a bit small when it comes to real-world applications, and systems outside the standard can implement a lot of different things.

Bare Scheme can be a bit trying, although Guile is a very useful tool. If I was going for Scheme I’d go for Racket https://racket-lang.org/

An interesting contender, although I dislike it’s reliance on the jvm is Clojure.

Multiparadigm languages like Ruby and D allow your laundry list, and everything else!

So the question then becomes, do you wanta full no mutable state no side effect FP language or only composition, partial application, and first-class functions.

If you want the first, then you want Clojure or Haskell not Scheme.

If you want “code is data” then Clojure or https://factorcode.org/ (Factor is a very interesting one on the code is data front)

Lisp.

Lisp is 70 years old. Even if you don’t start the timer with John McCarthy’s first version, it’s clearly an idea with staying power.

@wizeman’s suggestion of ML is good for many of the same reasons - it’s already stood the test of time.

One possibility, if all you’re interested in is longevity, is Coq. It’s a year older than Haskell (making it nearly 33), and for nearly all of that time it has had many fancy features that Haskell still lacks. It’s widely used in some mathematical research communities, and I believe its popularity has steadily grown. The primary downside is that it doesn’t do I/O by default (though there are now ways of getting around that, and e.g. extracting OCaml programs from your Coq code).

suprised no-one shared https://www.unison-lang.org/ already, but I smiled when I saw how opitimistic you are about 100 years.

Aren’t we in a “cambrian explosion” age of languages?
Nothing but useful concepts and stable ways to represent them will remain in 100 years.
Referential transparency might be one of them.
Equational reasoning might become mainstream.
Algebraic effects might stick around to compose effectful programs.

Learn any language(s) that contain those concepts and you’ll be covered if you plan to code a thing at age 120. PS: my 2 cents, I have no idea what I’m doing :)

100 years is a very long timeline. Just think about tech 100 years ago for example. :P

It’s possible computing will be so different that current programming languages won’t have any relevance in that paradigm. I would think that even 50 years things will be so different that current ideas will be heavily obsoleted.

FWIW Python 2.7 is pretty much frozen in time and is a very capable language …

SML is nice but I haven’t seen many (any?) big or common programs written in it. One reason may be that a language isn’t a sufficient foundation for useful programs (100 year or otherwise) – you also need a definition of an operating system.

On the other hand, I’m sure there are many >100K and >1M line codebases still running on Python 2.7 (mostly inside companies or big organizations).

Also it feels like this 2003 essay deserves a mention: http://www.paulgraham.com/hundred.html

In fact I remember Larry Wall saying it was partly an inspiration for Perl 6 (now Raku).

And the two languages from its author: Arc and Bel

http://arclanguage.org/

http://www.paulgraham.com/bel.html (apparently defined in a single big text file: https://sep.yimg.com/ty/cdn/paulgraham/bellanguage.txt?t=1595850613&)

I’ve never used them but the design motivation is related. They’re trying to “define away” most of the implementation details of scheme, i.e. bootstrap the language from a smaller set of axioms. So presumably they won’t change in 100 years.

But I think the real reason that something won’t change is because a lot of working software depends on it. There are large portions of Unix and the web that will never change.

This is mostly food for thought… If you are having fun with SML, then that is what is important :-) But it seems like there is a lot of personal taste involved. Invoking the “Lindy Effect”, I’d choose Unix / C / Shell / Fortran / Lisp / SQL, since those languages are extremely old and still widely used.

So it seems like there are 2 directions here:

1. Finding a language IMPLEMENTATION that has not changed very much and is likely to exist in the future. That’s why I pointed to Python 2.7

2. Building your own language (like Arc or Bel, though of course it doesn’t have to be a Lisp). I feel like if you take the the 100 year goal very seriously it will eventually lead to this :-)

Did you consider Ocaml? It seems to have cannibalized most of SML’s audience these days.

[Comment removed by author]