12 ms·

I like the term "Eternal Language" - programming languages where if you write code now - you will be able to compile and use that code ten years from now (a sof

I like the term "Eternal Language" - programming languages where if you write code now - you will be able to compile and use that code ten years from now (a software lifecycle eternity). Common Lisp, C, C++, Fortran, (edit: Java) are close to eternal languages. After losing a huge amount of Python 2 code (I wasn't going to rewrite it) I implemented Clasp, a Common Lisp implementation that interoperates with C++ (https://github.com/clasp-developers/clasp.git https://github.com/clasp-developers/clasp.git) so that I can write code that will hopefully live longer. I am one of the few software developers with code that I wrote 27 years ago that is still in active use by thousands of computational chemistry researchers (Leap, a frontend for the computational chemistry molecular dynamics package AMBER, implemented in C).

georgeecollins 5y ago
I hope that Rust joins the pantheon of eternal languages. I feel like it has a lot of the advantages of a language like C, but is just more modern and well thought through. Also, you did not mention Java. I have very old Java code that still works fine.
- ahohokla 5y ago
  I'd like it to be so, but i dont have faith for it. rust doesnt have a standard like lisp/c/c++ and it stands to those languages for their eternality, and at least with lisp and C their relative simplicity makes all the difference for something like that. they feel like, despite how opposite they are, discoveries rather than inventions when compared to something so complex like rust and c++
- oblio 5y ago
  Java is probably the biggest "eternal" language we have these days. Probably tied with C and C++. There's <<so much>> Java code churned out that it's unbelievable. Business systems have a ton more code than infrastructure systems.
  - yellowapple 5y ago
    C# is also probably in a similar league, for the same reasons.
  - deleted 5y ago
    [deleted]
  - wglb 5y ago
    I would check on cobol first.
    - oblio 5y ago
      There's a ton more Java out there. Java is much newer but it's from a time when we're talking about tens of millions of developers worldwide, instead of tens of thousands. A lot more people have been churning out Java since 1996 than Cobol since 1955 or so.
      - wglb 5y ago
        Do you have a feeling for how many Java LOC are out there?
        Tanjreeve 5y ago
        That's going to be quite a loaded metric considering how verbose Java is.
        kaba0 5y ago
        Java is at most longer than “short program” by a small constant factor, and that is mostly around project initialization. Also, I have never really understood it — c++ is not the shortest thing either with duplicating headers/implementations, go’s error handling deserves a whole discussion in terms of verbosity yet these languages are not considered repetitive.
        wglb 5y ago
        Well as a former cobol programmer, I would argue that it is no less verbose than pretty much any language.
- uoaei 5y ago
  I'd give it another 2-5 years before the syntax settles. Some serious improvements have recently been pushed out and I wouldn't be surprised if further improvements are on the horizon.
  - chayleaf 5y ago
    editions still allow backwards compatibility though, it's not like the syntax changes will break it
    - drran 5y ago
      Rare example of broken backward compatibility: `cargo install gltf-viewer` doesn't work today because of an error in gltf library. The error is fixed, but gltf-viewer is not updated to use the fix. Compiling gltf v0.11.3 error[E0597]: `buf` does not live long enough --> /home/vlisivka/.cargo/registry/src/github.com-1ecc6299db9ec823/gltf-0.11.3/src/binary.rs:225:35 | 119 | impl<'a> Glb<'a> { | -- lifetime `'a` defined here ... 225 | Self::from_v2(&buf) | --------------^^^^- | | | | | borrowed value does not live long enough | argument requires that `buf` is borrowed for `'a` ... 233 | } | - `buf` dropped here while still borrowed
- xapata 5y ago
  Java is younger than Python.
  - p_l 5y ago
    But Java 1.0 code is still (mostly) compile-able on recent Java versions, not so much with Python where I'd worry about going back 5 years.
    - musicale 5y ago
      Many Python developers and users were burned when the Python project decided to set fire to billions of lines of code. I have zero trust in Python as far as code longevity is concerned.
      - throwawayapples 5y ago
        More like trillions of lines of code, from probably millions of developers, dating back to the 90's. "The total code size of Zope 2 and its dependencies has decreased by over 200,000 lines of code as a result." - from the 2013 Zope documentation... how many lines of code was it before then? Python really burned its bridges. It's shown that it's a toy language now, and demonstrably unfit for any real production-quality projects.
        xapata 5y ago
        Right right right. I'll let my CTO know.
        EdwardDiego 5y ago
        > how many lines of code was [Zope] before then? Soooo many. Zope was a very formidable code base to delve into. I was trying to learn it because my company was using Plone, and Zope quickly surfaced through the abstractions. Zope's codebase might have been more accessible if type annotations were a thing back then. Their implementation of "interfaces" for Python were very interesting back in the Python 2.3 days. I disagree that Python is a "toy" language now. It started out as one, and has been stumbling awkwardly away from that ever since the mid 2000s - virtualenvs, pip, pyenv, pipenv/poetry, type annotations, mypy etc. In my entirely unscientific opinion, I think it was Django that started this journey, then of course scikit, numpy leading into pandas etc.
- bsder 5y ago
  > I hope that Rust joins the pantheon of eternal languages. I'm torn about this. On one hand, Rust is so much better than C it is ridiculous and I really hope it does become a language with decade-long longevity. On the other hand, Rust is the first new "systems programming" language in forever and is finally prying the door open to something other than C/C++. I'm really hoping that Rust opening the door and paving the way means that now we can get something better. What worries me about Rust is the impedance mismatch down at the very primitive hardware level--bytes and registers. The embedded guys are doing an amazing job papering over it, but the abstractions leak through quite a lot and you have to twist things around to satisfy them. The problem is: that's a lot of fiddly code with all kinds of corner cases. So, you either have a lot of work or you throw up your hands and invoke C (like Zig does).
- pharmakom 5y ago
  I don’t think Rust will (at least not in current form). It’s breaking too much ground in the (real world) PL-design space. We just don’t know what really work yet!
  - bobbylarrybobby 5y ago
    Eh; sum types, everything-is-an-expression, and composition over inheritance get you very very far toward optimal language design. Sure there are some potential economic improvements that could made to Rust, but the foundation is so strong that I don’t see anything that makes those same design decisions supplanting Rust. More likely that a new Rust edition would incorporate those kinds of changes.
duped 5y ago
C/C++ languages are stable, but building actual software with them is extremely cumbersome on future systems. It is unlikely to "just work" because of how we have inverted the dependency structure of the vast majority of C/C++ programs.
- forrestthewoods 5y ago
  Ehhh. Integrating an old C++ library into a new project may be difficult due to build systems or not useful due to dependencies. However if you want to take an old C++ game written in 2004 and ship it on modern platforms and consoles you only need to update a very small amount of platform specific code. Updating a 20 year old C++ project is probably easier than updating a 3 year old web app.
  - deergomoo 5y ago
    Tbf if you’re just looking to run an app on newer platforms you’d likely not need to do anything with the web app. They have a lot of issues but once stuff works it’s usually a very long time before it doesn’t. It would probably still be harder to add a new dependency to a 3 year old web app than it would be to integrate a 20yo C++ project though, I agree with you there.
  - duped 5y ago
    imo that would be a "forever program" not really a "forever language." The lack of standard packaging and terrible paradigm of shared dependencies has made C/C++ incredibly fragile and non-portable when you need something from years ago to compile today.
Turing_Machine 5y ago
JavaScript probably qualifies, too. It's not going anywhere for a very long time, if ever. Same with COBOL. COBOL will have to be killed with fire. I'm assuming here that "eternal language" doesn't necessarily mean "good language". :-)
- musicale 5y ago
  Unfortunately JavaScript code is often built on DOM and NPM quicksand.
chillpenguin 5y ago
In the realm of spoken languages, they say for a language to become immortal, it has to die. Latin is the classic example of this. Languages that continue to evolve will continue to "break" so to speak. In this vein, Standard ML (SML) is truly immortal, because the standard is set and it is "finished". Just a fun thought!
- LargoLasskhyfv 5y ago
  I think I've recently read that the amount of Akkadian/Sumerian material is vastly more, than anything the Latin period has produced. Yet almost nobody is able to interpret it, in comparison to Latin.
- pjmlp 5y ago
  Well, the Vatican keeps updating it. :) https://www.vatican.va/roman_curia/institutions_connected/latinitas/documents/rc_latinitas_20040601_lexicon_it.html https://www.vatican.va/roman_curia/institutions_connected/la...
  - p_l 5y ago
    Until "modern classics" education became a thing, Latin was arguably a still living language, if in limited use (mainly among the clergy, certain professions and educated circles, and effectively official language of certain countries). Then ~17th century modern classics turned latin education into navel gazing on the topic of bunch of roman republic/empire era works, and disregarded actually using it.
    - TheFreim 5y ago
      If I remember correctly there were still some scientific works being published in Latin in the 1900s
  - WJW 5y ago
    I really enjoy modern translations like "night-club" -> "taberna nocturna".
nikki93 5y ago
One of the newer (newer than C, C++, Common Lisp, ...) languages I feel comfortable about regarding this is Go. Definitely feels like I can write a simple Go program to generate a static website for example and it'll probably still work in that same state for a while.
- exdsq 5y ago
  It’s hard to say with any 1.x versions what’ll happen come 2.x
  - AnimalMuppet 5y ago
    True, but... most languages wouldn't be on version 1.x after the amount of time (and progress) that Go has. Go has a track record by now, of being very careful about breaking things, and providing tools to help fix them when they do. Sure, Go could introduce breaking changes in 2.x. Will they? Track record says "no".
    - randomswede 5y ago
      As far as I can tell, the only reason for a Go 2 (as opposed to a Go 1.nnnn) is "we introduced a breaking change". Things that were considered "Go 2" are being worked in, as the language evolves, without the need to break previously written code.
xapata 5y ago
How do you lose Python 2 code? The old interpreter still works.
- p_l 5y ago
  But is no longer viable option for new work, and in this case a lot of the code IIRC was libraries for writing programs.
Ginden 5y ago
> programming languages where if you write code now - you will be able to compile and use that code ten years from now (a software lifecycle eternity) Fun fact: code written in JavaScript in 1995 will work in 2021, after 26 years. If you are talking about "good practices" - few weeks ago I worked with C code from 2001 and it was just awful. Yes, it compiles - but it wouldn't pass any modern code review.
- rmbyrro 5y ago
  Out of curiosity: would the 1995 JS code pass any modern code review?
  - casion 5y ago
    JS from 2003 passed code review for me a few months ago... so, yes... maybe.
    - deleted 5y ago
      [deleted]
  - np_tedious 5y ago
    Probably depends what it's doing. If it's interacting with HTML and manipulating the DOM then probably not
    - helsontaveras18 5y ago
      How do modern frameworks display content? Must be interacting with HTML and manipulating the DOM in some way.
      - lostcolony 5y ago
        It's not whether they do, it's how they do. For instance, in 2003 there was no such thing as a mobile phone; passing code review today is probably going to entail either being responsive, or directing to a mobile version when accessed from a mobile device.
happy-dude 5y ago
Interestingly, Perl doesn't get a lot of love on HackerNews but I would classify it in the family of "eternal languages."
- oalders 5y ago
  Some of that code has been running for a long time. A lot of the Perl toolchain still works on 5.8.1 (released Sept 2003). https://metacpan.org/release/JHI/perl-5.8.1 https://metacpan.org/release/JHI/perl-5.8.1 Test::Simple still targets 5.6.2, which looks to have been released around the same time (November 2003). https://metacpan.org/release/RGARCIA/perl-5.6.2 https://metacpan.org/release/RGARCIA/perl-5.6.2
- throwawayapples 5y ago
  Even after the Perl 5 / Perl 6 / Raku debacle? Many developers left after that (Python pulled off the same trick a decade later.. apparently some language teams have very short memories.)
  - yellowapple 5y ago
    Said debacle arguably reinforced Perl 5's eternity, if anything.
  - shakow 5y ago
    Especially after de Perl5/6 debacle. The two separate languages solution let them have fun on Raku, all the while ensuring that Perl 5/7/... will preserve retrocompatibility.
- jjav 5y ago
  I have quite a bit of personal scripting in perl that I wrote in the early 90s, still in use every week. Haven't changed any of the code in decades.
tzs 5y ago
I think that to earn the title "Eternal Language" that should have to work in both directions. If I am an expert in language X and take a solar powered laptop and go spend 10 years living as a hermit in some isolated place while working on some big X program, with no communication with the outside world other than idle non-technical chat with the people of the village I go to monthly to buy supplies, if X is an Eternal Language then 1. My code that I wrote as a hermit should build and run on the outside world's systems, 2. I should still be an expert in the language X, only needing to learn library changes, fashion changes (such as coding style changes), and tooling changes to be ready to take a job as an X programmer at the same level as I had before I became a hermit. Alternatively, suppose I don't know X but wish to learn it. To earn the title "Eternal Language" I should be able to go into my library and read the "Learning X" book I bought 10 years ago but never got around to reading and that should mostly be equivalent to buying and reading a recently published book on X.
41b696ef1113 5y ago
Maybe Lua? Started in 1993 and LuaJIT is effectively frozen. I could see this one hanging in for a long time as the goto embedded language.
throwawayapples 5y ago
Go is another that strives for backwards compatibility: https://golang.org/doc/go1compat https://golang.org/doc/go1compat After seeing the Perl5/6 schism, I was hopeful that the Python devs wouldn't make the same disastrous mistake, but.. the same happened with us with approximately 100k lines of Python 2 code (which we are now in the process of porting to Go and Rust), precisely for this reason. It's exceedingly difficult to form trust in language developers who are willing to break working, production code in use all over the world for decades over a new unicode type and a few wishlist library items.
- Zababa 5y ago
  While Go strives for backwards compatibility, it's a bit too young for now at 12 years old, and already had a few changes around packaging and stuff like that. If we get to 20 years without Go 2 that will be a solid signal on the longevity of Go.
jjav 5y ago
> "Eternal Language" Even more than being able to compile and run it in a few decades (which is awesome) there is also the part that such eternal language ecosystems grow excellent tooling (debuggers, tracing, performance analysis, source tooling, build tooling, library maturity, etc) thanks to the stable platform and all the years dedicated to making it all ever better. I greatly dislike the language of the year hype not so much because the language change itself, but because all the wonderful mature tooling doesn't exist in the new shiny thing so we're back to debugging via print and performance analysis via guesswork.
medo-bear 5y ago
was it you that said that the difference between writing templates in c++ and writing macros in common lisp is like the difference between filling out tax forms and writing poetry :)
lenkite 5y ago
The only place LISP is eternal is on HN. A super-microscopic minority of engineers use it for real-world software development. The standard hasn't been updated for 2 decades. There is only one real compiler implementation. No WASM. No proper mobile support. Library support for real world tasks is abysmal. Common LISP's tomb is indeed shiny and eternal. Developers at HN will mourn at its graveyard for eternity.
- lispm 5y ago
  > There is only one real compiler implementation what kind of meaning of 'real' reduces the several compiler implementations to just one? Example: I use two native code compilers (SBCL and LispWorks) on my Mac. Both are available on other platforms, too. Is one of those not 'real'? What about, say, ECL or Allegro CL? Are they unreal?
SCLeo 5y ago
I honestly think most languages belong to this category. I can't really think of a language that changed so much that old code no longer works (other than python 2 -> python 3).

georgeecollins 5y ago

I hope that Rust joins the pantheon of eternal languages. I feel like it has a lot of the advantages of a language like C, but is just more modern and well thought through. Also, you did not mention Java. I have very old Java code that still works fine.

ahohokla 5y ago
I'd like it to be so, but i dont have faith for it. rust doesnt have a standard like lisp/c/c++ and it stands to those languages for their eternality, and at least with lisp and C their relative simplicity makes all the difference for something like that. they feel like, despite how opposite they are, discoveries rather than inventions when compared to something so complex like rust and c++
oblio 5y ago
Java is probably the biggest "eternal" language we have these days. Probably tied with C and C++. There's <<so much>> Java code churned out that it's unbelievable. Business systems have a ton more code than infrastructure systems.
- yellowapple 5y ago
  C# is also probably in a similar league, for the same reasons.
- deleted 5y ago
  [deleted]
- wglb 5y ago
  I would check on cobol first.
  - oblio 5y ago
    There's a ton more Java out there. Java is much newer but it's from a time when we're talking about tens of millions of developers worldwide, instead of tens of thousands. A lot more people have been churning out Java since 1996 than Cobol since 1955 or so.
    - wglb 5y ago
      Do you have a feeling for how many Java LOC are out there?
      - Tanjreeve 5y ago
        That's going to be quite a loaded metric considering how verbose Java is.
        kaba0 5y ago
        Java is at most longer than “short program” by a small constant factor, and that is mostly around project initialization. Also, I have never really understood it — c++ is not the shortest thing either with duplicating headers/implementations, go’s error handling deserves a whole discussion in terms of verbosity yet these languages are not considered repetitive.
        wglb 5y ago
        Well as a former cobol programmer, I would argue that it is no less verbose than pretty much any language.
uoaei 5y ago
I'd give it another 2-5 years before the syntax settles. Some serious improvements have recently been pushed out and I wouldn't be surprised if further improvements are on the horizon.
- chayleaf 5y ago
  editions still allow backwards compatibility though, it's not like the syntax changes will break it
  - drran 5y ago
    Rare example of broken backward compatibility: `cargo install gltf-viewer` doesn't work today because of an error in gltf library. The error is fixed, but gltf-viewer is not updated to use the fix. Compiling gltf v0.11.3 error[E0597]: `buf` does not live long enough --> /home/vlisivka/.cargo/registry/src/github.com-1ecc6299db9ec823/gltf-0.11.3/src/binary.rs:225:35 | 119 | impl<'a> Glb<'a> { | -- lifetime `'a` defined here ... 225 | Self::from_v2(&buf) | --------------^^^^- | | | | | borrowed value does not live long enough | argument requires that `buf` is borrowed for `'a` ... 233 | } | - `buf` dropped here while still borrowed
xapata 5y ago
Java is younger than Python.
- p_l 5y ago
  But Java 1.0 code is still (mostly) compile-able on recent Java versions, not so much with Python where I'd worry about going back 5 years.
  - musicale 5y ago
    Many Python developers and users were burned when the Python project decided to set fire to billions of lines of code. I have zero trust in Python as far as code longevity is concerned.
    - throwawayapples 5y ago
      More like trillions of lines of code, from probably millions of developers, dating back to the 90's. "The total code size of Zope 2 and its dependencies has decreased by over 200,000 lines of code as a result." - from the 2013 Zope documentation... how many lines of code was it before then? Python really burned its bridges. It's shown that it's a toy language now, and demonstrably unfit for any real production-quality projects.
      - xapata 5y ago
        Right right right. I'll let my CTO know.
      - EdwardDiego 5y ago
        > how many lines of code was [Zope] before then? Soooo many. Zope was a very formidable code base to delve into. I was trying to learn it because my company was using Plone, and Zope quickly surfaced through the abstractions. Zope's codebase might have been more accessible if type annotations were a thing back then. Their implementation of "interfaces" for Python were very interesting back in the Python 2.3 days. I disagree that Python is a "toy" language now. It started out as one, and has been stumbling awkwardly away from that ever since the mid 2000s - virtualenvs, pip, pyenv, pipenv/poetry, type annotations, mypy etc. In my entirely unscientific opinion, I think it was Django that started this journey, then of course scikit, numpy leading into pandas etc.
bsder 5y ago
> I hope that Rust joins the pantheon of eternal languages. I'm torn about this. On one hand, Rust is so much better than C it is ridiculous and I really hope it does become a language with decade-long longevity. On the other hand, Rust is the first new "systems programming" language in forever and is finally prying the door open to something other than C/C++. I'm really hoping that Rust opening the door and paving the way means that now we can get something better. What worries me about Rust is the impedance mismatch down at the very primitive hardware level--bytes and registers. The embedded guys are doing an amazing job papering over it, but the abstractions leak through quite a lot and you have to twist things around to satisfy them. The problem is: that's a lot of fiddly code with all kinds of corner cases. So, you either have a lot of work or you throw up your hands and invoke C (like Zig does).
pharmakom 5y ago
I don’t think Rust will (at least not in current form). It’s breaking too much ground in the (real world) PL-design space. We just don’t know what really work yet!
- bobbylarrybobby 5y ago
  Eh; sum types, everything-is-an-expression, and composition over inheritance get you very very far toward optimal language design. Sure there are some potential economic improvements that could made to Rust, but the foundation is so strong that I don’t see anything that makes those same design decisions supplanting Rust. More likely that a new Rust edition would incorporate those kinds of changes.

duped 5y ago

C/C++ languages are stable, but building actual software with them is extremely cumbersome on future systems. It is unlikely to "just work" because of how we have inverted the dependency structure of the vast majority of C/C++ programs.

forrestthewoods 5y ago
Ehhh. Integrating an old C++ library into a new project may be difficult due to build systems or not useful due to dependencies. However if you want to take an old C++ game written in 2004 and ship it on modern platforms and consoles you only need to update a very small amount of platform specific code. Updating a 20 year old C++ project is probably easier than updating a 3 year old web app.
- deergomoo 5y ago
  Tbf if you’re just looking to run an app on newer platforms you’d likely not need to do anything with the web app. They have a lot of issues but once stuff works it’s usually a very long time before it doesn’t. It would probably still be harder to add a new dependency to a 3 year old web app than it would be to integrate a 20yo C++ project though, I agree with you there.
- duped 5y ago
  imo that would be a "forever program" not really a "forever language." The lack of standard packaging and terrible paradigm of shared dependencies has made C/C++ incredibly fragile and non-portable when you need something from years ago to compile today.

Turing_Machine 5y ago

JavaScript probably qualifies, too. It's not going anywhere for a very long time, if ever. Same with COBOL. COBOL will have to be killed with fire. I'm assuming here that "eternal language" doesn't necessarily mean "good language". :-)

musicale 5y ago
Unfortunately JavaScript code is often built on DOM and NPM quicksand.

chillpenguin 5y ago

In the realm of spoken languages, they say for a language to become immortal, it has to die. Latin is the classic example of this. Languages that continue to evolve will continue to "break" so to speak. In this vein, Standard ML (SML) is truly immortal, because the standard is set and it is "finished". Just a fun thought!

LargoLasskhyfv 5y ago
I think I've recently read that the amount of Akkadian/Sumerian material is vastly more, than anything the Latin period has produced. Yet almost nobody is able to interpret it, in comparison to Latin.
pjmlp 5y ago
Well, the Vatican keeps updating it. :) https://www.vatican.va/roman_curia/institutions_connected/latinitas/documents/rc_latinitas_20040601_lexicon_it.html https://www.vatican.va/roman_curia/institutions_connected/la...
- p_l 5y ago
  Until "modern classics" education became a thing, Latin was arguably a still living language, if in limited use (mainly among the clergy, certain professions and educated circles, and effectively official language of certain countries). Then ~17th century modern classics turned latin education into navel gazing on the topic of bunch of roman republic/empire era works, and disregarded actually using it.
  - TheFreim 5y ago
    If I remember correctly there were still some scientific works being published in Latin in the 1900s
- WJW 5y ago
  I really enjoy modern translations like "night-club" -> "taberna nocturna".

nikki93 5y ago

One of the newer (newer than C, C++, Common Lisp, ...) languages I feel comfortable about regarding this is Go. Definitely feels like I can write a simple Go program to generate a static website for example and it'll probably still work in that same state for a while.

exdsq 5y ago
It’s hard to say with any 1.x versions what’ll happen come 2.x
- AnimalMuppet 5y ago
  True, but... most languages wouldn't be on version 1.x after the amount of time (and progress) that Go has. Go has a track record by now, of being very careful about breaking things, and providing tools to help fix them when they do. Sure, Go could introduce breaking changes in 2.x. Will they? Track record says "no".
  - randomswede 5y ago
    As far as I can tell, the only reason for a Go 2 (as opposed to a Go 1.nnnn) is "we introduced a breaking change". Things that were considered "Go 2" are being worked in, as the language evolves, without the need to break previously written code.

xapata 5y ago

How do you lose Python 2 code? The old interpreter still works.

p_l 5y ago
But is no longer viable option for new work, and in this case a lot of the code IIRC was libraries for writing programs.

Ginden 5y ago

> programming languages where if you write code now - you will be able to compile and use that code ten years from now (a software lifecycle eternity) Fun fact: code written in JavaScript in 1995 will work in 2021, after 26 years. If you are talking about "good practices" - few weeks ago I worked with C code from 2001 and it was just awful. Yes, it compiles - but it wouldn't pass any modern code review.

rmbyrro 5y ago
Out of curiosity: would the 1995 JS code pass any modern code review?
- casion 5y ago
  JS from 2003 passed code review for me a few months ago... so, yes... maybe.
  - deleted 5y ago
    [deleted]
- np_tedious 5y ago
  Probably depends what it's doing. If it's interacting with HTML and manipulating the DOM then probably not
  - helsontaveras18 5y ago
    How do modern frameworks display content? Must be interacting with HTML and manipulating the DOM in some way.
    - lostcolony 5y ago
      It's not whether they do, it's how they do. For instance, in 2003 there was no such thing as a mobile phone; passing code review today is probably going to entail either being responsive, or directing to a mobile version when accessed from a mobile device.

happy-dude 5y ago

Interestingly, Perl doesn't get a lot of love on HackerNews but I would classify it in the family of "eternal languages."

oalders 5y ago
Some of that code has been running for a long time. A lot of the Perl toolchain still works on 5.8.1 (released Sept 2003). https://metacpan.org/release/JHI/perl-5.8.1 https://metacpan.org/release/JHI/perl-5.8.1 Test::Simple still targets 5.6.2, which looks to have been released around the same time (November 2003). https://metacpan.org/release/RGARCIA/perl-5.6.2 https://metacpan.org/release/RGARCIA/perl-5.6.2
throwawayapples 5y ago
Even after the Perl 5 / Perl 6 / Raku debacle? Many developers left after that (Python pulled off the same trick a decade later.. apparently some language teams have very short memories.)
- yellowapple 5y ago
  Said debacle arguably reinforced Perl 5's eternity, if anything.
- shakow 5y ago
  Especially after de Perl5/6 debacle. The two separate languages solution let them have fun on Raku, all the while ensuring that Perl 5/7/... will preserve retrocompatibility.
jjav 5y ago
I have quite a bit of personal scripting in perl that I wrote in the early 90s, still in use every week. Haven't changed any of the code in decades.

tzs 5y ago

I think that to earn the title "Eternal Language" that should have to work in both directions. If I am an expert in language X and take a solar powered laptop and go spend 10 years living as a hermit in some isolated place while working on some big X program, with no communication with the outside world other than idle non-technical chat with the people of the village I go to monthly to buy supplies, if X is an Eternal Language then 1. My code that I wrote as a hermit should build and run on the outside world's systems, 2. I should still be an expert in the language X, only needing to learn library changes, fashion changes (such as coding style changes), and tooling changes to be ready to take a job as an X programmer at the same level as I had before I became a hermit. Alternatively, suppose I don't know X but wish to learn it. To earn the title "Eternal Language" I should be able to go into my library and read the "Learning X" book I bought 10 years ago but never got around to reading and that should mostly be equivalent to buying and reading a recently published book on X.

41b696ef1113 5y ago

Maybe Lua? Started in 1993 and LuaJIT is effectively frozen. I could see this one hanging in for a long time as the goto embedded language.

throwawayapples 5y ago

Go is another that strives for backwards compatibility: https://golang.org/doc/go1compat https://golang.org/doc/go1compat After seeing the Perl5/6 schism, I was hopeful that the Python devs wouldn't make the same disastrous mistake, but.. the same happened with us with approximately 100k lines of Python 2 code (which we are now in the process of porting to Go and Rust), precisely for this reason. It's exceedingly difficult to form trust in language developers who are willing to break working, production code in use all over the world for decades over a new unicode type and a few wishlist library items.

Zababa 5y ago
While Go strives for backwards compatibility, it's a bit too young for now at 12 years old, and already had a few changes around packaging and stuff like that. If we get to 20 years without Go 2 that will be a solid signal on the longevity of Go.

jjav 5y ago

> "Eternal Language" Even more than being able to compile and run it in a few decades (which is awesome) there is also the part that such eternal language ecosystems grow excellent tooling (debuggers, tracing, performance analysis, source tooling, build tooling, library maturity, etc) thanks to the stable platform and all the years dedicated to making it all ever better. I greatly dislike the language of the year hype not so much because the language change itself, but because all the wonderful mature tooling doesn't exist in the new shiny thing so we're back to debugging via print and performance analysis via guesswork.

medo-bear 5y ago

was it you that said that the difference between writing templates in c++ and writing macros in common lisp is like the difference between filling out tax forms and writing poetry :)

lenkite 5y ago

The only place LISP is eternal is on HN. A super-microscopic minority of engineers use it for real-world software development. The standard hasn't been updated for 2 decades. There is only one real compiler implementation. No WASM. No proper mobile support. Library support for real world tasks is abysmal. Common LISP's tomb is indeed shiny and eternal. Developers at HN will mourn at its graveyard for eternity.

lispm 5y ago
> There is only one real compiler implementation what kind of meaning of 'real' reduces the several compiler implementations to just one? Example: I use two native code compilers (SBCL and LispWorks) on my Mac. Both are available on other platforms, too. Is one of those not 'real'? What about, say, ECL or Allegro CL? Are they unreal?

SCLeo 5y ago

I honestly think most languages belong to this category. I can't really think of a language that changed so much that old code no longer works (other than python 2 -> python 3).