[kbenson]

> IMHO, given the state of the language & its ecosystem as compared to its closest cousins (Ruby & Python), I can't really see why any new projects would be started in Perl. If anyone has a counter point I would certainly love to hear it, as I will freely admit to not having had much interaction with the Perl community as of late.

I might, if I knew what your point was. There's just a vague implication that the language and it's ecosystem are substandard to Ruby and Python. Apparently you think it's self evident, so doesn't require explanation, but I don't feel that way, so I'm not sure what to address.

Mind supplying some examples of what you feel Perl is lacking in comparison?

To jump start it, I've been using Mojolicious[1] lately, and find it a dream to work in. And of course, being able to pull from CPAN is a plus.

[1]: http://mojolicio.us/

[doktrin]

>There's just a vague implication that the language and it's ecosystem are substandard to Ruby and Python. Apparently you think it's self evident, so doesn't require explanation

To turn the question on its head, why should anyone choose Perl over the alternatives? I honestly have never seen a reason to switch. Not terribly many others have either, as of late. I will attempt to lay out some of my reasoning.

When evaluating a new language & ecosystem, I tend to look for an active and welcoming community, a large selection of actively maintained libraries, and lastly a language that is interesting and/or fun to develop in. I can't really pontificate with authority on how Perl fares with regards to the above 3, but I will share my perception. Feel free to contradict (of course).

1. Community : there's no doubt Perl's community has taken a bit of a hit over the last n years population wise. In addition, the Perl community has, anecdotally, a reputation for being a bit terse [1]. Nothing cut and dry here, but again nothing that stands out IMHO.

2. Libraries : by extension of a diminishing pool of active contributors, it stands to reason some modules may not be as actively supported as their counterparts in other languages. This is compounded by the uncertain state of the language's version (5,6,7?)

3. Language : I personally have enjoyed coding in Perl, and am not really too intimidated by its historical warts. It's quite possible to write readable Perl, so write-only accusations are of little concern (to me).

Notes :

* Versioning : As an outsider, the current state of Perl's versioning is confusing. Perl 6 has been in development for over a decade, and I've seen mention of Perl 5.2 being released as Perl 7. None of this reflects positively on the language as a whole as it raises concerns about future proofing and maintainability.

* Mojolicious : Looks nice. My only concern would be that, based on the GitHub commit history, it is overwhelmingly governed and contributed to by a single individual. More so than even Rails, and significantly more so than Django. This isn't necessarily a negative, but I'd certainly want to trust him before building a production app using his tool.

[1] http://blogs.perl.org/users/joel_berger/2012/10/why-people-d...

[kbenson]

> To turn the question on its head, why should anyone choose Perl over the alternatives? I honestly have never seen a reason to switch.

Was that the implication of the original statement? When you said you didn't see much reason for a new project to be started in Perl, I took that as any new project, even in a shop that has prior Perl experience, not a project where you are specifically looking for something different than our prior language.

Indeed, if you are already using one of Perl/Python/Ruby, I'm not sure I see a reason to switch from any one of those to any other.

If on the other hand you actually meant "When starting a new project, I see no reason to use Perl regardless of whether that's where you have experience", then we still have a discussion worth having.

> 1. Community : there's no doubt Perl's community has taken a bit of a hit over the last n years population wise. In addition, the Perl community has, anecdotally, a reputation for being a bit terse [1]. Nothing cut and dry here, but again nothing that stands out IMHO.

Did you actually read that link, or just read a section title and assume it made your point? Because the author updated that section saying that he really can't talk much on that point, because he wasn't there, and the evidence shows it to have been fairly civil.

That said, Sebastian does have a bit of a reputation for being "terse". But that's one person. Since when does one person define a whole community?

> 2. Libraries : by extension of a diminishing pool of active contributors, it stands to reason some modules may not be as actively supported as their counterparts in other languages. This is compounded by the uncertain state of the language's version (5,6,7?)

You have a lot of assumptions, and are using them as the basis for more assumptions. How much has the community decreased? What percentage of the community that are still active are contributors of modules, compared to similar communities of other languages?

Or, just look at some data: https://metacpan.org/recent Feel free to change the filter on the left to new distributions, not just new releases, to get an idea of how much active development is going on. It may be more or less than other languages, but I think what's shown should be sufficient to disabuse you of the notion that no development is going on.

As for the the version number, this is a non-issue. There is no issue of version numbers, it's a solved problem. Some people in the community occasionally bring it up because it's a sore spot, and it gets a lot of play in the tech media sites, but it's really rather simple (if different than most other languages). Perl 5 is Perl 5, and will stay so unless someone forks it and competes. Perl 6 is a new language, intended as both a successor and a companion to Perl 5. People are NOT expected to migrate Perl 5 code to Perl 6, it is a different language. This has nothing to do with the state of the language's future. Perl 5 is still being developed. Perl 6 is still being developed. Both are available, and useful, for specific subsets of uses. For Perl 6 that happens to be a somewhat smaller subset currently because of performance issues, and some portions of the spec still being fleshed out (this is a different discussion).

> 3. Language : I personally have enjoyed coding in Perl, and am not really too intimidated by its historical warts. It's quite possible to write readable Perl, so write-only accusations are of little concern (to me).

Agreed.

> * Versioning : As an outsider, the current state of Perl's versioning is confusing. Perl 6 has been in development for over a decade, and I've seen mention of Perl 5.2 being released as Perl 7. None of this reflects positively on the language as a whole as it raises concerns about future proofing and maintainability.

Blame tech media sites for taking an internal community discussion, misunderstanding the state of things, taking random suggestions from people as real community movements, and playing it up for page views. I'm sure we can agree the media isn't infallible.

I'll agree that Perl 6 is unfortunately named. If you know the eventual goals (Perl 5 interoperability) the name makes a bit more sense, but it has caused some in the Perl 5 community to feel constrained to a version number (thus the talk of Perl 7). In the end, this is a marketing problem (which is why you see it from the outside).

> * Mojolicious : Looks nice. My only concern would be that, based on the GitHub commit history, it is overwhelmingly governed and contributed to by a single individual. More so than even Rails, and significantly more so than Django. This isn't necessarily a negative, but I'd certainly want to trust him before building a production app using his tool.

There's a fair number of other people that have committed[2], but I won't argue the impression that it looks to be primarily Sebastian (even if there's supposedly 4-5 core developers, according to changelog notices). That said, from your earlier link that explained him leaving the core Catalyst team[1], he started Catalyst, so he's got some experience in this area.

I feel fairly certain others would step up to the plate if he couldn't commit as much.

[1] http://blogs.perl.org/users/joel_berger/2012/10/why-people-d...

[2] https://github.com/kraih/mojo/contributors

[doktrin]

> Was that the implication of the original statement? When you said you didn't see much reason for a new project to be started in Perl, I took that as any new project, even in a shop that has prior Perl experience, not a project where you are specifically looking for something different than our prior language.

Yeah. This wasn't about a Perl shop switching gears, but rather seen from the POV of a blank slate. I tend to think in terms of new startups, and put myself in the shoes of someone trying to bring a new product to market.

>Did you actually read that link, or just read a section title and assume it made your point?

I did. A lot of the back-and-forth in the comment section helped me make the decision to include that link as illustration.

>It may be more or less than other languages, but I think what's shown should be sufficient to disabuse you of the notion that no development is going on.

I never said "no development" was going on. Please don't put words in my mouth.

My concern is that upon requiring a module for purpose X, to find that libraries A B and C are poorly supported / no longer supported. This isn't really as simple as counting global library updates on a given day.

For what it's worth, roughly twice as many new modules were added to ruby gems during the equivalent time period [1]. The data isn't made accessible anywhere near as neatly as on metacpan, and requires futzing with the API.

>You have a lot of assumptions, and are using them as the basis for more assumptions... Did you actually read that link..I might, if I knew what your point was...Apparently you think it's self evident

Feedback : you've spent a lot of time talking about me and my perceived flaws. Not sure if this is what you intended, but this conversation feels hostile. My intention is certainly not to be on the offensive, and I hope the same holds true for you.

[1] http://guides.rubygems.org/rubygems-org-api/#activity

[kbenson]

> I did. A lot of the back-and-forth in the comment section helped me make the decision to include that link as illustration.

Ah. I assume when linked to an article that the article itself is the intended object of my attention. The comments are indeed a valid source of community info, but I also imagine an article title of the format "Why people don't like X", you're going to get some polarized views.

> I never said "no development" was going on. Please don't put words in my mouth.

You're right. My apologies. I know you weren't implying that. That was a sloppy turn of phrase on my part.

> My concern is that upon requiring a module for purpose X, to find that libraries A B and C are poorly supported / no longer supported. This isn't really as simple as counting global library updates on a given day.

Indeed, I agree with that assessment. I struggled with a way to provide the links as a way to indicate there is development while also alluding to the fact that I think number of updated and new modules over time is a bad metric for quality of modules, as well as being misleading as the number may change over time as many of the common, core needs are met, and those modules stabilize.

That said, CPAN module pages show the last updated time, as well as the dates of previous commits. The dependency (and reverse dependency) graphs available on metacpan also go a long way towards letting you know how much else a module relies on (for the purpose of assessing possible problem modules farther downstream), and how stable and mature a module is (to some degree, considering how many other modules rely on it).

> For what it's worth, roughly twice as many new modules were added to ruby gems during the equivalent time period. The data isn't made accessible anywhere near as neatly as on metacpan, and requires futzing with the API.

Yeah, I did some research, and found it a bit harder to get counts for Python and Ruby. But we agree raw count isn't all that useful, I was just including it to show that there was activity, and of a level that I would consider significant.

> Feedback : you've spent a lot of time talking about me and my perceived flaws. Not sure if this is what you intended, but this conversation feels hostile. My intention is certainly not to be on the offensive, and I hope the same holds true for you.

It's definitely not what I intended.

> I might, if I knew what your point was

Intended literally. I thought the statement was vague, and I wasn't sure the actual point, but it appeared to indicate something regarding the desirability of using Perl for new project due to the state of the language in comparison to similar languages. I was trying to be explicit.

> Apparently you think it's self evident.

Not meant to be snide, although I can see how you could take it that way. I assume assertions without explanations are put forth because the reasoning is self evident (or discerned easily enough to be self evident to those familiar). There were no explanations put forth, and if you did think it was self evident, that expresses something in itself. I have no doubt there are a great many people that will argue similar points to your original statement with little to no experience, by simple repeating claims they've heard as though they are fact.

> You have a lot of assumptions, and are using them as the basis for more assumptions

I'm not sure how you think this is hostile, but obviously by it's conclusion you do. it was in reference to a statement where you seemed to assume the Perl community was in decline, and used that to make more assumptions about module quality. You can't use community population and involvement decrease to indicate module decline because of lack of people without first qualifying community population and involvement decrease. That's what I meant about making assumptions, and using those to make more assumptions.

> Did you actually read that link, or just read a section title and assume it made your point?

A poor choice of words, but meant literally. The only portion of the article I found that might support your point there was replaced by a retraction that reversed the stance. I felt compelled to ask whether you had actually read that, or just went by the section title "The Developers are Mean/Antisocial/Stubborn/Other". A poor choice of words on my point, and you clarified your point to reference the comments, which indicates why you included that link.

> My intention is certainly not to be on the offensive, and I hope the same holds true for you.

No, I enjoy a good discussion, and actually attempt to monitor my speech (written or verbal) closely to try to avoid misunderstanding, but that's so hard to do with a natural language. :)

P.S. While it may seem like I'm trying to defend myself overly hard by addressing each point where you interpreted me as possibly hostile, I think it's important to explain my true point in each case to accurately reflect what I was trying to convey. If you interpreted them as hostile, it's possible you may have also misinterpreted my point, as tone often affects meaning. Individually addressing each allows you to look at each one anew.

Okay, that's enough meta. I do find examining the misunderstandings of an argument/discussion fascinating though...

[doktrin]

I appreciate you taking the time to address the statements I was not interpreting correctly. It goes without saying, but communicating over text always leaves some small room for misunderstanding.

This discussion has certainly left me interested in re-exploring the world of Perl. As minor as it sounds, I really enjoyed playing with metacpan, which as mentioned is definitely more fleshed out than its counterparts.

In addition, while perusing various Perl repos I remembered how much I once liked writing Perl, and will probably revisit it in a side project (if not production just yet).

[kbenson]

> It goes without saying, but communicating over text always leaves some small room for misunderstanding.

Definitely. Even spoken English is rife with misunderstandings, and when the tone is almost entirely removed as in writing, that just makes it all the harder.

> In addition, while perusing various Perl repos I remembered how much I once liked writing Perl, and will probably revisit it in a side project (if not production just yet).

Nice to hear!

Re: metacpan, it's amazing what interesting modules show up when you follow some of the metacpan dependency graphs. IMHO, once you're above a certain number of modules, the problem starts becoming less of whether a solution exists and more about how the candidate modules rate WRT reliability, platform compatibility, dependencies you do or do not already have, etc.