3 ms·

Pick your poison. Either you evolve your language to keep people interested and old code becomes stale and eventually stops working, or you don't and you lose

Pick your poison. Either you evolve your language to keep people interested and old code becomes stale and eventually stops working, or you don't and you lose your community and interest in the language, like Perl. We run twenty year old Perl scripts on new hosts at work all the time, with little to no change required in them. We have lots of microservices written in Perl over the last decade or more, and those generally have very little to no problem being ported to new systems as well. The problem now? Finding people that know Perl or want a job writing it.

ww-picard-do 4y ago
> Finding people that know Perl or want a job writing it. Indeed. Although writing Perl is not so bad, reading not so much.
- kbenson 4y ago
  It's not that I think reading it is necessarily bad, but Perl does shift the onus of writing from making it correct to making it legivlem later. It's easy to write correct perl code, there's often many ways to do it because the language tries to do what you want for you. That unfortunately makes it harder to read, as when not in the exact same frame of mind, those shortcuts the language does for you are harder to intuit later. I think the total amount of effort required to write good legible code is about on par with it's contemporary languages if you take the time to write it well, but it's hard to resist being able to write it quickly and be done because it's easy to ignore the problem of tomorrow you're creating by being so quick and productive today.
jonas21 4y ago
An exception is C++, which HN loves to hate, but has managed to remain mostly backwards-compatible while evolving into a modern language and maintaining a large community.
- cgh 4y ago
  Same with Java on all points, including the hate.
enneff 4y ago
It doesn’t have to be that way. 10 years since Go 1 and almost all Go programs written then will run correctly, unchanged, against Go 1.19. It takes a lot of effort but the effort pays off big time. Any programming language that wants to survive the test of time should push hard on maintaining compatibility imo. I think people lost interest in Perl because Python was just a better language for a lot of people’s use cases (and arguably a lot less mysterious). And the focus on Perl 6 (now Raku) arguably distracted a lot of people from Perl 5 and then took too long to mature. (At least that’s how it looked from my outside perspective.)
- kbenson 4y ago
  I wasn't very clear, but I view this specifically as something interpreted languages have to deal with far more than compiled languages. Compiled languages have a slightly different set of trade offs that make this less of a problem (less, but not nonexistent). > Python was just a better language for a lot of people’s use cases I won't argue that about the short term, but long-term? Long-term the difference in policy in how it deals with changes ends up at exactly the problem we're discussing. The fact that (IMO) pyenv and virtualenv are needed to manage python deployments in any sane way is evidence of this. Long-term a lot of projects that ended up using Python would likely have been better served by Perl because of the expected target and lifecycle of the programs in question. There are a lot of aspects of languages which aren't necessarily the thing people were thinking of at the time that they do think of now, because of very negative examples. Examples such as package distribution, which Javascript has had numerous problems with in the past with NPM, and Python occasionally still struggled with (I'm looking at you, pip, and your CLI search interface brokenness). These days new languages take package management and deprecation policies and cycles and how to deal with long-term stability extremely carefully, because of the examples of Perl and Python and Javascript, etc. At least the ones that plan to have any real adoption do. Rust is a somewhat recent example of that. Look at all the effort they put into making sure they got those aspects as correct as they could and communicated them well to users. I don't think Rust would have nearly as many people using it or interested in it if they didn't give those the importance they did (I imagine C# and Java are similar, but I follow news about them somewhat less).

ww-picard-do 4y ago

> Finding people that know Perl or want a job writing it. Indeed. Although writing Perl is not so bad, reading not so much.

kbenson 4y ago
It's not that I think reading it is necessarily bad, but Perl does shift the onus of writing from making it correct to making it legivlem later. It's easy to write correct perl code, there's often many ways to do it because the language tries to do what you want for you. That unfortunately makes it harder to read, as when not in the exact same frame of mind, those shortcuts the language does for you are harder to intuit later. I think the total amount of effort required to write good legible code is about on par with it's contemporary languages if you take the time to write it well, but it's hard to resist being able to write it quickly and be done because it's easy to ignore the problem of tomorrow you're creating by being so quick and productive today.

jonas21 4y ago

An exception is C++, which HN loves to hate, but has managed to remain mostly backwards-compatible while evolving into a modern language and maintaining a large community.

cgh 4y ago
Same with Java on all points, including the hate.

enneff 4y ago

It doesn’t have to be that way. 10 years since Go 1 and almost all Go programs written then will run correctly, unchanged, against Go 1.19. It takes a lot of effort but the effort pays off big time. Any programming language that wants to survive the test of time should push hard on maintaining compatibility imo. I think people lost interest in Perl because Python was just a better language for a lot of people’s use cases (and arguably a lot less mysterious). And the focus on Perl 6 (now Raku) arguably distracted a lot of people from Perl 5 and then took too long to mature. (At least that’s how it looked from my outside perspective.)

kbenson 4y ago
I wasn't very clear, but I view this specifically as something interpreted languages have to deal with far more than compiled languages. Compiled languages have a slightly different set of trade offs that make this less of a problem (less, but not nonexistent). > Python was just a better language for a lot of people’s use cases I won't argue that about the short term, but long-term? Long-term the difference in policy in how it deals with changes ends up at exactly the problem we're discussing. The fact that (IMO) pyenv and virtualenv are needed to manage python deployments in any sane way is evidence of this. Long-term a lot of projects that ended up using Python would likely have been better served by Perl because of the expected target and lifecycle of the programs in question. There are a lot of aspects of languages which aren't necessarily the thing people were thinking of at the time that they do think of now, because of very negative examples. Examples such as package distribution, which Javascript has had numerous problems with in the past with NPM, and Python occasionally still struggled with (I'm looking at you, pip, and your CLI search interface brokenness). These days new languages take package management and deprecation policies and cycles and how to deal with long-term stability extremely carefully, because of the examples of Perl and Python and Javascript, etc. At least the ones that plan to have any real adoption do. Rust is a somewhat recent example of that. Look at all the effort they put into making sure they got those aspects as correct as they could and communicated them well to users. I don't think Rust would have nearly as many people using it or interested in it if they didn't give those the importance they did (I imagine C# and Java are similar, but I follow news about them somewhat less).