3 ms·

For someone that involved in Perl I must say you are getting a couple things wrong. First let's address the talk you are referring to. That rant was about the

by vgy7ujm 10y ago

For someone that involved in Perl I must say you are getting a couple things wrong. First let's address the talk you are referring to. That rant was about the authors frustration with Perl 5 vs Perl 6, the state of the Perl 5 core maintainers politics at the time rather than actual problems with using the language. The author is the creator of some great modules that could have been made core at the time e.g. giving Perl 5 a new core OO system but it did not happen. From what I can see he is still active in Perl 5. Another point to be made is that the community tried to address Perl 5s "marketing problem" which led to many rants that in hindsight perhaps did not do any good. About SDKs you are right that there often is not an official Perl one for new Cloud services but I have had no problems finding what I need on CPAN for AWS etc. Also there are very good modules for doing generic REST things and with many services using the REST API is less opinionated and less of a hassle anyways. I just don't see the problem. Why even bother to use the language specific SDK for infrastructure like AWS. Terraform is winning that battle right now. I have been working in mostly Java, PHP and JavaScript shops lately and trust me, the "cool" tooling you get there starts sucking the minute you need to doing more unixy/glue scripting. I have replaced 10000 line tools that in the end just does shell commands with 500 line Bash or Perl scripts that does said commands. I guess this all boils down to the use case but if you are doing mainly unix scripting (which is what you are doing in a Linux based web DevOps setting) you will excel with Perl and Bash as your main tools.

vgy7ujm 10y ago
And to anyone writing DevOps scripts doing it in JS/PHP: stop trying to create an MVC webapp when scripting Linux automation. Those tools suck to maintain since the MVC adds 90% stuff that is not needed in the domain and makes it much harder to understand them under stress when production systems fail. Tool != webapp /rant
muraiki 10y ago
> I have been working in mostly Java, PHP and JavaScript shops lately and trust me, the "cool" tooling you get there Given this and your earlier comment, you seem to think that people who have had bad experiences with Perl simply want to be cooler, to use cooler tools, because if only they had your experience they would see how useful Perl is. This is exactly the kind of echo chamber that the talk condemns. Criticisms of Perl as experienced in the real world -- and yes, I have done plenty of automation and devops work in Perl and bash -- are brushed aside with ad hominem attacks. If Perl works for you that's great, but clearly it had problems for my coworkers and I, which you completely brush aside. This attitude that the Perl community consistently demonstrates is just another reason why I intend to never use it again, and why I thoroughly dissuade any newcomers to programming from spending their energy on this language and its community.
- vgy7ujm 10y ago
  When the attacks are coming someone has to hold the flag up high. But seriously, shell scripting in JS or even Go is not a pleasant experience when you know of other tools. You can not deny that. And to be clear there are many tasks where I would rather choose another language than Perl. Mostly for applications where compilation is a win. But I still maintain my position that if you stick with Perl and of course have other skills like web/infrastructure you will be ahead of the pack. And the Perl community is very friendly these days. Despite very strange attacks from outsiders where it is obvious that they have not seen any Perl code written after 5.8 and pull their examples from 90s websites etc. Also it seems like the author of the talk you linked to has been way more optimistic about Perl the last couple of years. Perhaps things has changed a bit from what you remember from 4+ years back. Don't take my word for it, I am JAPH. Go see for yourself, talk to the guys doing the booths at conferences. You will be amazed how welcoming they are.
  - muraiki 10y ago
    > But seriously, shell scripting in JS or even Go is not a pleasant experience when you know of other tools. You can not deny that. I most certainly can and do deny that. Writing scripts in Go, in my professional experience, was extraordinarily better than writing them in Perl. Go's ability to asynchronously run processes using the built in exec package, including capturing stdout and stderr (or piping them as streams!), works awesomely. After much searching of CPAN, the best module that my boss and I could find fails to properly capture output that interleaves stdout and stderr. In general, doing anything async in Go is worlds better than Perl's various competing / community rejected / author abandoned event loops. I went to a small Perl conference in 2015. Yes, the people there were nice. I met TimToady and found him to be very humble. I respect the people in the Perl 5 community, but it simply astounds me as to how much of an echo chamber it is. If Perl 6 can be criticized as taking too much inspiration from other languages, then Perl 5 is essentially the opposite. Trust me, I used to defend Perl very strongly, especially when that guy made a big deal out of the vulnerability that he found in CGI.pm. I've tried many of the modern -- and also the ancient -- parts of the Perl ecosystem and have hung out and helped newbies in #perl. I also spent quite some time in #perl6, trying out its various async capabilities and reporting and documenting bugs (I'm noted in the Christmas release). I don't say this to puff myself up, but rather to explain to you that I _tried extremely hard_ to work with Perl 5 and Perl 6 (most of my language-level criticisms of Perl 5 are rectified in 6). It's simply astonishing to me that people will insist that somehow I'm missing out on something that makes Perl 5 superior to everything else, to the point of denying my very experience, as you have done here.

by vgy7ujm 10y ago

vgy7ujm 10y ago

And to anyone writing DevOps scripts doing it in JS/PHP: stop trying to create an MVC webapp when scripting Linux automation. Those tools suck to maintain since the MVC adds 90% stuff that is not needed in the domain and makes it much harder to understand them under stress when production systems fail. Tool != webapp /rant

muraiki 10y ago

> I have been working in mostly Java, PHP and JavaScript shops lately and trust me, the "cool" tooling you get there Given this and your earlier comment, you seem to think that people who have had bad experiences with Perl simply want to be cooler, to use cooler tools, because if only they had your experience they would see how useful Perl is. This is exactly the kind of echo chamber that the talk condemns. Criticisms of Perl as experienced in the real world -- and yes, I have done plenty of automation and devops work in Perl and bash -- are brushed aside with ad hominem attacks. If Perl works for you that's great, but clearly it had problems for my coworkers and I, which you completely brush aside. This attitude that the Perl community consistently demonstrates is just another reason why I intend to never use it again, and why I thoroughly dissuade any newcomers to programming from spending their energy on this language and its community.

vgy7ujm 10y ago
When the attacks are coming someone has to hold the flag up high. But seriously, shell scripting in JS or even Go is not a pleasant experience when you know of other tools. You can not deny that. And to be clear there are many tasks where I would rather choose another language than Perl. Mostly for applications where compilation is a win. But I still maintain my position that if you stick with Perl and of course have other skills like web/infrastructure you will be ahead of the pack. And the Perl community is very friendly these days. Despite very strange attacks from outsiders where it is obvious that they have not seen any Perl code written after 5.8 and pull their examples from 90s websites etc. Also it seems like the author of the talk you linked to has been way more optimistic about Perl the last couple of years. Perhaps things has changed a bit from what you remember from 4+ years back. Don't take my word for it, I am JAPH. Go see for yourself, talk to the guys doing the booths at conferences. You will be amazed how welcoming they are.
- muraiki 10y ago
  > But seriously, shell scripting in JS or even Go is not a pleasant experience when you know of other tools. You can not deny that. I most certainly can and do deny that. Writing scripts in Go, in my professional experience, was extraordinarily better than writing them in Perl. Go's ability to asynchronously run processes using the built in exec package, including capturing stdout and stderr (or piping them as streams!), works awesomely. After much searching of CPAN, the best module that my boss and I could find fails to properly capture output that interleaves stdout and stderr. In general, doing anything async in Go is worlds better than Perl's various competing / community rejected / author abandoned event loops. I went to a small Perl conference in 2015. Yes, the people there were nice. I met TimToady and found him to be very humble. I respect the people in the Perl 5 community, but it simply astounds me as to how much of an echo chamber it is. If Perl 6 can be criticized as taking too much inspiration from other languages, then Perl 5 is essentially the opposite. Trust me, I used to defend Perl very strongly, especially when that guy made a big deal out of the vulnerability that he found in CGI.pm. I've tried many of the modern -- and also the ancient -- parts of the Perl ecosystem and have hung out and helped newbies in #perl. I also spent quite some time in #perl6, trying out its various async capabilities and reporting and documenting bugs (I'm noted in the Christmas release). I don't say this to puff myself up, but rather to explain to you that I _tried extremely hard_ to work with Perl 5 and Perl 6 (most of my language-level criticisms of Perl 5 are rectified in 6). It's simply astonishing to me that people will insist that somehow I'm missing out on something that makes Perl 5 superior to everything else, to the point of denying my very experience, as you have done here.