"immortal" programming languages

this is a thread for discussion of immortal programming languages. here you should give examples of such languages, argue why they qualify as "immortal" and argue why they're better or more valuable to learn than other "immortal" languages. by immortal we mean those languages that are unlikely to ever get a new "version", "standard" or "revision". a program written in such a language is a program you would expect to run correctly to completion in 20, 30 or 40 years from now. i will start by naming Common Lisp. a new standard is never going to come out, the ecosystem is alright and there are probably 6 or 7 mature implementations. the language is fast to the point where with the SBCL implementation it usually happens to be the fastest language on the chart after C in benchmarks. support for web and desktop applications is present through libraries. plug-ins for modern IDEs like VSCode or IntelliJ are available if you dont like emacs.

>>41375 Got my hopes up after misreading "immortal" as "immoral". And here I was ready to rant about how lewd lisp parentheses are

>>>41376 >((())) >inb4 lisp makes it's own anti defamation league page

brainfuck r a i n f u c k

this is the worst, most disgraceful drawing ive ever seen

>>41376 ( ) ( .)(. ) ) ( ( )( ) )) )) >>41375 >by immortal we mean those languages that are unlikely to ever get a new "version", "standard" or "revision". I think this badly qualifies an 'immortal' language. When I think 'immortal language', I think of ones that will always be around, like C or Fortran. No new standards is more common with languages that aren't used. If we talk about Lisp in terms of the original language, not families or dialects, it is immortal. Frozen at Lisp 1.5; a Lisp 2.0 was intended but was never finished. There isn't a single machine working today that can meaningfully run it because the system is deeply linked to punch card peripherals. Lisp 1.5 is immortal, but at the same time, truly dead. It feels wrong to call it both at the same time. >the language is fast to the point where with the SBCL implementation it usually happens to be the fastest language on the chart after C in benchmarks. Please show me one of these charts, I've never seen this before. I'll quit whining and contribute. Languages defined by IEC 61131-3, used for programming PLCs, could be immortal. The most recent standard is 2013, and I wonder if any more is necessary or will be made? I'm learning about these at the moment, and I think a new standard would be a pain in the ass. It may happen yet, but so far it's 'immortal'. Learning PLC programming potentially outstrips any other immortal language, so long as you have an electrical engineering background. The field is too heavy in machinery and electronics for a compsci grad.

>>41375 It seems your definition of "immortal" would better describe "dead".

>>41381 you are technically correct but a proper definition would have been too verbose. i assumed the capabilities of running the program themselves were implicit in the definition. >Please show me one of these charts, I've never seen this before. pic related are a few examples. i would give you a link to the website/github project but they've since removed Fortran and Lisp because they "want to focus on newer languages".

>>41382 it's a matter of perspective.

>It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification. … Go programs that work today should continue to work even as future releases of Go 1 arise.

- Common LISP: Bicameral syntax, condition system and debugger, live-image, MOP, still has imperative constructs, pretty good type system all things considered, just has a tonne of amazing features - Smalltalk: Message-passing, actor model, GUI builders - PROLOG: The original logic programming, meta-logic, resolution calculus, its constraint processing library is amazing, Warren Abstract Machine, theorem proving (tho to its credit and detriment it is weak at that) - Erlang: 'We couldn't make prolog concurrent after 10 years and 400 million bucks so we made this by turning Prolog into a LISP instead' the BEAM is undeniably really good - Forth: I dunno why people like this actually but I'd wager it's really good

>>41375 C's a pretty obvious one, C99 specifically. If you write a program according to the C99 standard, you should be able to use it on basically any hardware capable of running it to the end of time. C is also like Lisp in that it's relatively easy to implement, meaning that if a compiler doesn't exist for your platform of choice, it shouldn't be hard to write one yourself. Honestly, this immortality is a large part of why I opt for C in general. Something like Zig improves upon it in a lot of ways, but C is C, and there's very few languages that are ingrained to the degree that it is. >>41380 Grow up you pussy.

>>41388 Nah it's not, because standard C99 can't do anything without POSIX or Win32 to give it access to the OS, which means that its stability is dependent on these and praying for no new platform to arrive and disrupt that duopoly. Unlike say C++>=11 or Common Lisp which have big enough stdlibs that you can make complex programs without any dependencies, putting the maintenance burden on implementers.

>>41390 >language needs interface to OS What kind of argument is this? It obviously applies to any language. The solution also doesn't need to come from a standard library. As long as someone does a library its good enough. That aside if you do obscure stuff you will find issues like drivers not implementing functions that are supposed to exist because guess what - mainstream doesnt use it so they didnt care.

>>41388 >C's a pretty obvious one C23 just came out. It's not 'immortal'. Sure C99 is still used occasionally, but the standard has been updated. >>41387 >Forth I would disagree. Forth seems like Lisp in that, because the language is so technically simple, different versions of it proliferate. I would wager that some Forth source is not cross-compatible whatsoever, especially because it's most used in embedded (apparently) with lots of unusual computer architecture.

>>41391 Point is that either that interface lives in the language standard, or in a third-party library/shim trying to cover as much platforms as possible. In the first case, stability is guaranteed by the standard which also allows switching implementation if for example the glibc stops being maintained. Compare pure C (fopen/remove) with C++'s std::filesystem or CL pathname/file funcs and cry because you can't even portably list directory contents. That's why I say I do POSIX C when asked.

SML. Yes, there is next to nothing in terms of implementations or libraries, it is essentially defunct, but it's one of the very few languages which is formally defined, so it may be taken up again anytime. It lays dormant, but anyone may write up one implementation in their favorite environment.