8 ms·

Something’s gotta change though. The path perl5 is on ends in dead language. It’s not attracting young talent, the last really high profile project that sticks

by chomp 6y ago

Something’s gotta change though. The path perl5 is on ends in dead language. It’s not attracting young talent, the last really high profile project that sticks out in my mind is Perl Dancer which was released in 2011, and modules on cpan are getting dusty/losing maintainers. I also created and maintain a large Perl stack and in my opinion, the things that made Perl great 10-15 years ago, other languages have adopted and did better. Now for lack of want of updating the language, it’s just languished. I just don’t see a compelling reason to start a Perl project in 2020.

mokus 6y ago
What’s wrong with letting the language die?
- johannes1234321 6y ago
  It's wrong for those who invested their career on it. If they switch to a different platform they lose their compatitive value. Also a company with a huge Perl code base there is large value in new developers who can become productive without much special training.
  - quonn 6y ago
    Why would you hang your career on the fate of a single language? Most of the knowledge transfers just fine between languages. Over a career you can become an expert in several of them.
    - johannes1234321 6y ago
      You can certainly know multiple languages, but if you are involved deeper in the runtime and language design there is specific investment. I myself did a lot of PHP, went deep into the engine, nowadays do more with other languages where I can transfer some knowledge, but I guess even 5 years after writing my last relevant amounts of PHP I could jump in a consulting gig easily, while for other environments I have to spend more time preparing.
    - Izkata 6y ago
      > Most of the knowledge transfers just fine between languages. A rather low-level example (nothing like understanding good abstraction/design), but useful because it's apparently not obvious - co-workers didn't believe it until I demonstrated with short example programs: Reference semantics are identical between javascript, python, and java. (The first two being the primary languages we use, I don't remember how java came up that day - I know others are also the same)
    - erik_seaberg 6y ago
      Blub languages are all alike; every powerful language is powerful in its own way. It's hard to reuse what I learned about Lisp macros or Python decorators or Scala implicits in other languages that don't have anything like that. The result tends to be reams of cringeworthy boilerplate because that's the only thing that works in every language.
    - jlokier 6y ago
      I have to disagree with the second part. You shouldn't hang your career on any one language. But languages themselves are almost trivial. Knowledge of libraries, and community expectations around them, doesn't translate well between languages. And personal libraries, laden with solutions for the domains you've tended to specialise in, don't translate at all. You basically have to start from scratch, which is a huge loss if they are genuinely useful and took years to develop and accumulate. You can't just rewrite those quickly, and you're unlikely to find a third party library in any language that solves the same problems. I can see how this may be meaningless to someone whose career consists of moving from company to company, never carrying anything forward other than what's in their head. But some people carry forward substantial personal libraries which they use. The loss of those can easily be a 10x loss in productivity, so switching to a new language and its entire ecosystem can be a big and expensive step, compared with not doing so. Yes, over a career you can become expert in several. I would even say quite a lot. And yes, you can always learn new things. But there will be times when you lose a lot of your advantages due to starting from scratch with something new. That's a big cost, it shouldn't be ignored. When it's necessary, such as learning an ML framework, say, it's a justified cost, and everyone pays it. But when it's just due to changing fashions it's a bit galling, and difficult to justify when is the right time. So much is lost.
  - alicemaz 6y ago
    there won't be new developers if they don't move the language past its present state. there's no reason for anyone to learn perl except for a job maintaining legacy software at this point, but that could change if they manage to refashion it to attract new interest that said I don't know what kind of "special training" you need to pick up a new language. I got hired for a perl job despite never having written it. the conversation went something like "can you write c?" "yep." "can you write shell scripts?" "yep." "ok, you can write perl." read what the sigils meant and could write it with minimal competence same day. expertise and nuance can come as you go
- natch 6y ago
  That would be quite a waste of a good thing. It’s a really fun and powerful language. I don’t use it anymore because of the culture of hating on it from non-users, who have just hounded users so much that they have succeeded in dampening the fun a lot. I mean you can’t even talk about it in HN without encountering some serious negativity, usually uninformed. It’s unpleasant. On the good side, there are other great languages that don’t have this problem.
  - WesolyKubeczek 6y ago
    Sounds much like sunken costs fallacy. ;)
    - natch 6y ago
      I don't follow you. Sunken costs fallacy would apply if someone said "well, I spent so much time learning it, I might as well keep using it even though the environment is so hostile." So, that's exactly the path I'm not taking. I'm disregarding any sunken costs. The sunken costs fallacy applies to those who would cling on to a path, not those who leave it. But maybe you're using it from a different perspective.
- laumars 6y ago
  If it’s going to die anyway then what’s wrong in trying to modernise it and seeing if that does renew interest? Worst case scenario is people don’t migrate and that outcome is no different to if you hadn’t tried. So it feels like the only bad move is not to try at all.
  - toast0 6y ago
    If modernising it splits the community and doesn't suceed, you've redone the Perl6 fiasco, but probably killed both 5 and 7. Is that better than driving Perl 5 to a stable end? I don't really think so. But I'm not involved in the development of Perl, I'll just keep writing Perl scripts until it gets hard to install.
    - laumars 6y ago
      Perl is going to die if they don’t do anything anyway. So absolute it’s better to risk fragmenting the ecosystem. If your result for inaction is eventual death anyway, then the sensible thing is to go out swinging. At least that way you have a half chance of reviving the language — which is better than the zero chance you have if you do nothing.
throwaway2048 6y ago
We must do something -> this is something -> We must do this
jerf 6y ago
Then let it die in maturity, going down providing value to its users to the last, and focusing on any needs its remaining users may still have. Way better than stabbing it's user base in the back, and still not attracting any new users. Because there's no feasible way Perl can just tweak a couple things and open up a new user base. It is what it is. The whole "stab our existing users in the back and chase a new user base" model has been bizarrely popular lately, but I'm not sure I've seen it work even once. (I exaggerate a bit with "stab", but still...)
- chomp 6y ago
  I guess I haven’t really considered that angle before, maybe the maintainers love it too much to let it die. I don’t really know where I stand now. Maybe they should just leave it alone. I just stare wistfully at the hole PHP has dug itself out of over the past decade in terms of modernizing the language, and its 2020 and I can’t even have subroutine signatures without experimental flags. I feel like opportunity was missed with Perl and I don’t know if it can be reclaimed.
  - user5994461 6y ago
    PHP was always one of the top ecosystem for web development (probably the top one in the early 2000s), with strong platforms and userbases centered around them: LAMP, wordpress, discussion boards and other. Perl never had anything like that. It allowed to do CGI in the early 1990s then nothing major I can think of.
    - thesuperbigfrog 6y ago
      >> Perl never had anything like that. It allowed to do CGI in the early 1990s then it didn't keep up. Not quite. Perl actually has several widely-used web frameworks such as: Mason - https://en.wikipedia.org/wiki/Mason_(Perl) https://en.wikipedia.org/wiki/Mason_(Perl) Dancer - https://en.wikipedia.org/wiki/Dancer_(software) https://en.wikipedia.org/wiki/Dancer_(software) Catalyst - https://en.wikipedia.org/wiki/Catalyst_(software) https://en.wikipedia.org/wiki/Catalyst_(software) Mojolicious - https://en.wikipedia.org/wiki/Mojolicious https://en.wikipedia.org/wiki/Mojolicious Many of these were/are widely-used and most are still maintained and in use. Mason powered the Amazon.com retail web site (maybe it still does?). Catalyst powered DuckDuckGo's Community Platform, the BBC iPlayer, and YouPorn.
bachmeier 6y ago
> I just don’t see a compelling reason to start a [X] project in 2020. Fill in the [X] with your choice of language. It's not like it was 20 years ago when you chose a language because it was literally the only practical way to do what you needed to do. Unless you have something pretty niche, there's always another language. I don't see a compelling reason not to start a Perl project in 2020. Granted, I don't use the language much, but I think it still has its place.
- jefftk 6y ago
  Can you give an example of a new project that you think would be right to start with Perl today? Most examples that come to mind for me would make more sense as Python.
  - boring_twenties 6y ago
    Anything that already exists in my shell's history as a one-liner, but needs to be upgraded to a reusable script. As far as I know, one liners are not possible in Python. As a matter of fact, I'm not aware of any popular tools that can even hold a candle to Perl's power at the command line. So, my options are: 1. Forget about one-liners. This is the option most people seem to take, and also by far the worst one. In my career I regularly saw my perfectly competent colleagues take minutes or hours to write throwaway scripts to do what I would do in seconds with a Perl one-liner. 2. Use Perl for one-liners, then rewrite the few that graduate to scripts in Python. This one isn't as obviously absurd as the first, but still seems like a rather large waste of time overall. 3. The obvious: paste your one-liner into a new file, add some newlines and whitespace and command-line options and whatever else.
    - jefftk 6y ago
      That makes sense! When I write one liners I tend to build them up in bash, and so when I want them to be reusable I do the same as your (3) but targeting bash. Then when they get at all complicated I rewrite in python.
kevin_thibedeau 6y ago
Tcl still gets updates despite a small user base. Perl can enjoy the same fate.
- 7thaccount 6y ago
  I like to play around with trying new languages a lot. I've probably read a book on and written a little code in ~20 languages in the past decade, although 90% of my work is in Python. I didn't start playing with TCL until roughly a year ago and have been really impressed with what I've seen so far. Ashok Nadkarni's book is amazing and a lot of things seem pretty straightforward.

by chomp 6y ago

mokus 6y ago

What’s wrong with letting the language die?

johannes1234321 6y ago
It's wrong for those who invested their career on it. If they switch to a different platform they lose their compatitive value. Also a company with a huge Perl code base there is large value in new developers who can become productive without much special training.
- quonn 6y ago
  Why would you hang your career on the fate of a single language? Most of the knowledge transfers just fine between languages. Over a career you can become an expert in several of them.
  - johannes1234321 6y ago
    You can certainly know multiple languages, but if you are involved deeper in the runtime and language design there is specific investment. I myself did a lot of PHP, went deep into the engine, nowadays do more with other languages where I can transfer some knowledge, but I guess even 5 years after writing my last relevant amounts of PHP I could jump in a consulting gig easily, while for other environments I have to spend more time preparing.
  - Izkata 6y ago
    > Most of the knowledge transfers just fine between languages. A rather low-level example (nothing like understanding good abstraction/design), but useful because it's apparently not obvious - co-workers didn't believe it until I demonstrated with short example programs: Reference semantics are identical between javascript, python, and java. (The first two being the primary languages we use, I don't remember how java came up that day - I know others are also the same)
  - erik_seaberg 6y ago
    Blub languages are all alike; every powerful language is powerful in its own way. It's hard to reuse what I learned about Lisp macros or Python decorators or Scala implicits in other languages that don't have anything like that. The result tends to be reams of cringeworthy boilerplate because that's the only thing that works in every language.
  - jlokier 6y ago
    I have to disagree with the second part. You shouldn't hang your career on any one language. But languages themselves are almost trivial. Knowledge of libraries, and community expectations around them, doesn't translate well between languages. And personal libraries, laden with solutions for the domains you've tended to specialise in, don't translate at all. You basically have to start from scratch, which is a huge loss if they are genuinely useful and took years to develop and accumulate. You can't just rewrite those quickly, and you're unlikely to find a third party library in any language that solves the same problems. I can see how this may be meaningless to someone whose career consists of moving from company to company, never carrying anything forward other than what's in their head. But some people carry forward substantial personal libraries which they use. The loss of those can easily be a 10x loss in productivity, so switching to a new language and its entire ecosystem can be a big and expensive step, compared with not doing so. Yes, over a career you can become expert in several. I would even say quite a lot. And yes, you can always learn new things. But there will be times when you lose a lot of your advantages due to starting from scratch with something new. That's a big cost, it shouldn't be ignored. When it's necessary, such as learning an ML framework, say, it's a justified cost, and everyone pays it. But when it's just due to changing fashions it's a bit galling, and difficult to justify when is the right time. So much is lost.
- alicemaz 6y ago
  there won't be new developers if they don't move the language past its present state. there's no reason for anyone to learn perl except for a job maintaining legacy software at this point, but that could change if they manage to refashion it to attract new interest that said I don't know what kind of "special training" you need to pick up a new language. I got hired for a perl job despite never having written it. the conversation went something like "can you write c?" "yep." "can you write shell scripts?" "yep." "ok, you can write perl." read what the sigils meant and could write it with minimal competence same day. expertise and nuance can come as you go
natch 6y ago
That would be quite a waste of a good thing. It’s a really fun and powerful language. I don’t use it anymore because of the culture of hating on it from non-users, who have just hounded users so much that they have succeeded in dampening the fun a lot. I mean you can’t even talk about it in HN without encountering some serious negativity, usually uninformed. It’s unpleasant. On the good side, there are other great languages that don’t have this problem.
- WesolyKubeczek 6y ago
  Sounds much like sunken costs fallacy. ;)
  - natch 6y ago
    I don't follow you. Sunken costs fallacy would apply if someone said "well, I spent so much time learning it, I might as well keep using it even though the environment is so hostile." So, that's exactly the path I'm not taking. I'm disregarding any sunken costs. The sunken costs fallacy applies to those who would cling on to a path, not those who leave it. But maybe you're using it from a different perspective.
laumars 6y ago
If it’s going to die anyway then what’s wrong in trying to modernise it and seeing if that does renew interest? Worst case scenario is people don’t migrate and that outcome is no different to if you hadn’t tried. So it feels like the only bad move is not to try at all.
- toast0 6y ago
  If modernising it splits the community and doesn't suceed, you've redone the Perl6 fiasco, but probably killed both 5 and 7. Is that better than driving Perl 5 to a stable end? I don't really think so. But I'm not involved in the development of Perl, I'll just keep writing Perl scripts until it gets hard to install.
  - laumars 6y ago
    Perl is going to die if they don’t do anything anyway. So absolute it’s better to risk fragmenting the ecosystem. If your result for inaction is eventual death anyway, then the sensible thing is to go out swinging. At least that way you have a half chance of reviving the language — which is better than the zero chance you have if you do nothing.

throwaway2048 6y ago

We must do something -> this is something -> We must do this

jerf 6y ago

Then let it die in maturity, going down providing value to its users to the last, and focusing on any needs its remaining users may still have. Way better than stabbing it's user base in the back, and still not attracting any new users. Because there's no feasible way Perl can just tweak a couple things and open up a new user base. It is what it is. The whole "stab our existing users in the back and chase a new user base" model has been bizarrely popular lately, but I'm not sure I've seen it work even once. (I exaggerate a bit with "stab", but still...)

chomp 6y ago
I guess I haven’t really considered that angle before, maybe the maintainers love it too much to let it die. I don’t really know where I stand now. Maybe they should just leave it alone. I just stare wistfully at the hole PHP has dug itself out of over the past decade in terms of modernizing the language, and its 2020 and I can’t even have subroutine signatures without experimental flags. I feel like opportunity was missed with Perl and I don’t know if it can be reclaimed.
- user5994461 6y ago
  PHP was always one of the top ecosystem for web development (probably the top one in the early 2000s), with strong platforms and userbases centered around them: LAMP, wordpress, discussion boards and other. Perl never had anything like that. It allowed to do CGI in the early 1990s then nothing major I can think of.
  - thesuperbigfrog 6y ago
    >> Perl never had anything like that. It allowed to do CGI in the early 1990s then it didn't keep up. Not quite. Perl actually has several widely-used web frameworks such as: Mason - https://en.wikipedia.org/wiki/Mason_(Perl) https://en.wikipedia.org/wiki/Mason_(Perl) Dancer - https://en.wikipedia.org/wiki/Dancer_(software) https://en.wikipedia.org/wiki/Dancer_(software) Catalyst - https://en.wikipedia.org/wiki/Catalyst_(software) https://en.wikipedia.org/wiki/Catalyst_(software) Mojolicious - https://en.wikipedia.org/wiki/Mojolicious https://en.wikipedia.org/wiki/Mojolicious Many of these were/are widely-used and most are still maintained and in use. Mason powered the Amazon.com retail web site (maybe it still does?). Catalyst powered DuckDuckGo's Community Platform, the BBC iPlayer, and YouPorn.

bachmeier 6y ago

> I just don’t see a compelling reason to start a [X] project in 2020. Fill in the [X] with your choice of language. It's not like it was 20 years ago when you chose a language because it was literally the only practical way to do what you needed to do. Unless you have something pretty niche, there's always another language. I don't see a compelling reason not to start a Perl project in 2020. Granted, I don't use the language much, but I think it still has its place.

jefftk 6y ago
Can you give an example of a new project that you think would be right to start with Perl today? Most examples that come to mind for me would make more sense as Python.
- boring_twenties 6y ago
  Anything that already exists in my shell's history as a one-liner, but needs to be upgraded to a reusable script. As far as I know, one liners are not possible in Python. As a matter of fact, I'm not aware of any popular tools that can even hold a candle to Perl's power at the command line. So, my options are: 1. Forget about one-liners. This is the option most people seem to take, and also by far the worst one. In my career I regularly saw my perfectly competent colleagues take minutes or hours to write throwaway scripts to do what I would do in seconds with a Perl one-liner. 2. Use Perl for one-liners, then rewrite the few that graduate to scripts in Python. This one isn't as obviously absurd as the first, but still seems like a rather large waste of time overall. 3. The obvious: paste your one-liner into a new file, add some newlines and whitespace and command-line options and whatever else.
  - jefftk 6y ago
    That makes sense! When I write one liners I tend to build them up in bash, and so when I want them to be reusable I do the same as your (3) but targeting bash. Then when they get at all complicated I rewrite in python.

kevin_thibedeau 6y ago

Tcl still gets updates despite a small user base. Perl can enjoy the same fate.

7thaccount 6y ago
I like to play around with trying new languages a lot. I've probably read a book on and written a little code in ~20 languages in the past decade, although 90% of my work is in Python. I didn't start playing with TCL until roughly a year ago and have been really impressed with what I've seen so far. Ashok Nadkarni's book is amazing and a lot of things seem pretty straightforward.