5 ms·

I'm not surprised that the language is dying. They seem to be spending time on things no one cares about and things that are inconsequential.

83457 7y ago
Any examples?
- liveoneggs 7y ago
  the name is the example
roryrjb 7y ago
Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable, that the only things that are mentioned are just not the things that newer, fast moving languages such as Rust and Go talk about? I don't think that the naming situation is trivial, I really think it has had a negative effect on both Perl 5 and Perl 6.
- coldtea 7y ago
  >Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable No, it's also declining. If not for anything else, because most younger devs won't touch it (either 5 or 6).
jerf 7y ago
This is by far the most important thing they could be doing right now. It should have been done 10-15 years ago, and is arguably the dominant remaining reason for why the work done on both Perls since Perl 6 has failed to payoff the way it should have. There is a certain contingent of developers who should have been all over Perl 6 and very excited about it. We should have been seeing the stream of "$COMMON_LIBRARY but in Perl 6!" postings on HN for a couple of years, along with the blog posts of "look how crap this is to write in $OTHER_LANGUAGE but with this bit here and there look at how slick the Perl 6 solution is!" every couple of weeks. We should be seeing blog posts about the joys of working in a language with built-in grammar support replacing the old ad-hoc regex support, and how well it integrates with the rest of the features. We should have even eventually seen the contrarian backlash posts about how much of a mess you can make if you overload all your operators and grammar constructs and use all the features at once in an ill-advised manner, followed by comment thread semi-flamewars about whether bad code is the fault of the programmer or the language. But we didn't. Bias disclosure: I actually have no interest in Perl 6, so this isn't advocacy. Anything I've ever seen that Perl 6 looks interesting to me (emphasis) for, I'd rather just use Haskell, which I've already learned and actually does quite a lot of what Perl 6 does. But Perl 6 does it without being a immutable functional programming language, making this all a lot more accessible to a lot of programmers. I'm not saying I'm interested in Perl 6; I'm saying, there is definitely a chunk of programmers who should have been interested in it who are not. And from what I can see, this naming confusion is one of the major reasons. (One other one I would point to is the Perl 6 community's multi-year "joke" that Perl 6 would be released "next Christmas", which nobody outside of the Perl 6 community found even slightly funny, instead creating a reputation for the community that overpromises and underdelivers; that a few people would swoop in to those conversations to actually mock people who weren't insiders enough to know it was a joke and not a real promise, which is to say, 99.9999999% of humanity (that is not random nines; that is all but ~700 people; take one off if you like), really didn't help. I put "remaining reason" in my first paragraph because this has been resolved for many years now. But I can tell you that this significantly diminished my own personal interest, and I'm sure I'm not alone. Finally, I'd point to it just never being done, but, arguably, that alone couldn't have killed it. There's plenty of languages that grow quite substantially over time; the Python of when Python first really got popular and the Python of today are very different, for instance. Had more people been interested and pushing for something usable $TODAY, with more work being done later, this probably wouldn't have been as big a deal.)
- DonHopkins 7y ago
  I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the failure of their common underlying TMTOWTDI philosophy, which encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't help, either.) https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to... http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt While I believe Python's continuing success is evidence supporting the truth of its Zen of Python philosophy: "There should be one — and preferably only one — obvious way to do it." https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
  - jerf 7y ago
    So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to be convinced by another language that I'm wrong now, too.
    - Qcombinator 7y ago
      You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.
  - alabamenhu 7y ago
    The idea that there's only one way implies that code context means nothing. For example, if you have a simple function that kicks backed cached values: sub foo ($bar) { if %cache{$bar}.defined { return %cache{$bar} } } Is an absolutely correct way of doing things. But it's messier then using a postfix: sub foo ($bar) { return %cache{$bar} if %cache{$bar}.defined } Or simplifying: sub foo ($bar) { return $_ with %cache{$bar} } While it's true that sub foo ($bar) { .return with %cache{$bar} } is possible, I don't tend to use it too much because the dot syntax isn't as pretty with postfixes ha. But each of these options has a place where it is the better option, but none of them is universally the one and only best option. Nested ifs with multiple statements may go better with the first one, but if several conditionals have similar elements and are simple statements it might behoove to line them up with whitespace. But the placement of return right at the outset (as opposed to nestled in an if statement) to me makes it clear the return value is a gate-keeper of sorts. Ditto for using 'die if [cond]' which much more in your face then 'if [cond] {die}'. All of the above code is readable though. Of course, a functional approach could be just as valid and readable, and clear: multi sub foo ($bar where %cache{$bar}.defined) { %cache{$bar} } multi sub foo ($bar) { ... } Or taking advantage of traits: sub foo ($bar) is cached { ... } Almost inevitably the unreadable code is where someone is trying intentionally to be cute and write unreadable code. But that can be done in languages like C too, or with any language that allows single letter variables.

83457 7y ago

Any examples?

liveoneggs 7y ago
the name is the example

roryrjb 7y ago

Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable, that the only things that are mentioned are just not the things that newer, fast moving languages such as Rust and Go talk about? I don't think that the naming situation is trivial, I really think it has had a negative effect on both Perl 5 and Perl 6.

coldtea 7y ago
>Could it be that the Perl language (and especially Perl 5) but as a community in general, is established and mature, and very stable No, it's also declining. If not for anything else, because most younger devs won't touch it (either 5 or 6).

jerf 7y ago

This is by far the most important thing they could be doing right now. It should have been done 10-15 years ago, and is arguably the dominant remaining reason for why the work done on both Perls since Perl 6 has failed to payoff the way it should have. There is a certain contingent of developers who should have been all over Perl 6 and very excited about it. We should have been seeing the stream of "$COMMON_LIBRARY but in Perl 6!" postings on HN for a couple of years, along with the blog posts of "look how crap this is to write in $OTHER_LANGUAGE but with this bit here and there look at how slick the Perl 6 solution is!" every couple of weeks. We should be seeing blog posts about the joys of working in a language with built-in grammar support replacing the old ad-hoc regex support, and how well it integrates with the rest of the features. We should have even eventually seen the contrarian backlash posts about how much of a mess you can make if you overload all your operators and grammar constructs and use all the features at once in an ill-advised manner, followed by comment thread semi-flamewars about whether bad code is the fault of the programmer or the language. But we didn't. Bias disclosure: I actually have no interest in Perl 6, so this isn't advocacy. Anything I've ever seen that Perl 6 looks interesting to me (emphasis) for, I'd rather just use Haskell, which I've already learned and actually does quite a lot of what Perl 6 does. But Perl 6 does it without being a immutable functional programming language, making this all a lot more accessible to a lot of programmers. I'm not saying I'm interested in Perl 6; I'm saying, there is definitely a chunk of programmers who should have been interested in it who are not. And from what I can see, this naming confusion is one of the major reasons. (One other one I would point to is the Perl 6 community's multi-year "joke" that Perl 6 would be released "next Christmas", which nobody outside of the Perl 6 community found even slightly funny, instead creating a reputation for the community that overpromises and underdelivers; that a few people would swoop in to those conversations to actually mock people who weren't insiders enough to know it was a joke and not a real promise, which is to say, 99.9999999% of humanity (that is not random nines; that is all but ~700 people; take one off if you like), really didn't help. I put "remaining reason" in my first paragraph because this has been resolved for many years now. But I can tell you that this significantly diminished my own personal interest, and I'm sure I'm not alone. Finally, I'd point to it just never being done, but, arguably, that alone couldn't have killed it. There's plenty of languages that grow quite substantially over time; the Python of when Python first really got popular and the Python of today are very different, for instance. Had more people been interested and pushing for something usable $TODAY, with more work being done later, this probably wouldn't have been as big a deal.)

DonHopkins 7y ago
I believe Perl 5's decline and Perl 6's failure to catch on is evidence of the failure of their common underlying TMTOWTDI philosophy, which encourages write-only "creative snowflake" Perl code that's an inscrutable, unreadable, unmaintainable nightmare. (The sigil-heavy line-noise syntax sure doesn't help, either.) https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it https://en.wikipedia.org/wiki/There%27s_more_than_one_way_to... http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt http://wiki.c2.com/?ThereIsMoreThanOneWayToDoIt While I believe Python's continuing success is evidence supporting the truth of its Zen of Python philosophy: "There should be one — and preferably only one — obvious way to do it." https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
- jerf 7y ago
  So I basically agree with you & jschwartzi. But to expand or reinforce my original point, it is very clear there is a substantial contingent of programmers who do not. While of course in my own opinion, my own opinion is correct (duh), at a more global level, or maybe in a more academic sense, I'm open to the possibility that I'm wrong. I've already flopped on that matter once in my career and I reserve the right to be convinced by another language that I'm wrong now, too.
  - Qcombinator 7y ago
    You don't have to be "wrong". You just have to be not exactly the same as everybody else. And of course, nobody is exactly the same as everybody else, therefore there is not possible for there to be such a thing as The One Perfect Language. The right tool for the job; but also the right tool for the workman.
- alabamenhu 7y ago
  The idea that there's only one way implies that code context means nothing. For example, if you have a simple function that kicks backed cached values: sub foo ($bar) { if %cache{$bar}.defined { return %cache{$bar} } } Is an absolutely correct way of doing things. But it's messier then using a postfix: sub foo ($bar) { return %cache{$bar} if %cache{$bar}.defined } Or simplifying: sub foo ($bar) { return $_ with %cache{$bar} } While it's true that sub foo ($bar) { .return with %cache{$bar} } is possible, I don't tend to use it too much because the dot syntax isn't as pretty with postfixes ha. But each of these options has a place where it is the better option, but none of them is universally the one and only best option. Nested ifs with multiple statements may go better with the first one, but if several conditionals have similar elements and are simple statements it might behoove to line them up with whitespace. But the placement of return right at the outset (as opposed to nestled in an if statement) to me makes it clear the return value is a gate-keeper of sorts. Ditto for using 'die if [cond]' which much more in your face then 'if [cond] {die}'. All of the above code is readable though. Of course, a functional approach could be just as valid and readable, and clear: multi sub foo ($bar where %cache{$bar}.defined) { %cache{$bar} } multi sub foo ($bar) { ... } Or taking advantage of traits: sub foo ($bar) is cached { ... } Almost inevitably the unreadable code is where someone is trying intentionally to be cute and write unreadable code. But that can be done in languages like C too, or with any language that allows single letter variables.