4 ms·

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

by 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.
- vgy7ujm 10y ago
  Working with text in general is what Perl excels at so it baffles me that you guys with 20 years experience was not able to make that work. Capture::Tiny is one module just from the top of my head. That module lists 10-20 other modules that probably can do the same things like IPC::Open3. Now I don't know exactly what your use case was but I have always been able to solve my capturing of stdout and stderr with Perl. Concurrency is definitively a pain point since it is not built into the core but for Web and even certain terminal apps I have found Mojo/Mojolicious to be both well designed and well maintained. I don't deny that sometimes Java, Erlang or Go is the correct tool. I am actually very interested in Go and use many tools written in it like Docker/Kubernetes, Consul, Terraform etc. Go will probably be my choice for anything that needs concurrency until Perl catches up or something else better comes along. But I will not abandon Perl for my unix scripting needs as it is still the best in my opinion. Getting max work done in a short time and with less code with max convenience and unix-y feel is where Perl whipes the floor with every other language. And that is also a sweet spot for DevOps needs where you don't develop everything from scratch. You take the best practices tools of the day and glue it together with Perl. I am sad to see someone like you that clearly was involved with Perl at one point abandon it completely. The thing is that for every negative comment someone with a bit of clout spews on the internet there needs to be hundreds of positive ones to counter it. I still hear that "Perl is dead" because of that guy who clearly did not know Perl and used an example from the Stone Age that at one time was considered a feature but we now know is a vulnerability. It also exists in PHP by the way, and web developers worth their grain of salt have known better than to let user data just pass unsanetized to internal execution for quite some time now... I call TIMTOWDI and hopefully we will se you back in Perl some day. You know it is a very special little language and if you ever "clicked" with it you will always miss its good stuff.

by vgy7ujm 10y ago

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.

vgy7ujm 10y ago
Working with text in general is what Perl excels at so it baffles me that you guys with 20 years experience was not able to make that work. Capture::Tiny is one module just from the top of my head. That module lists 10-20 other modules that probably can do the same things like IPC::Open3. Now I don't know exactly what your use case was but I have always been able to solve my capturing of stdout and stderr with Perl. Concurrency is definitively a pain point since it is not built into the core but for Web and even certain terminal apps I have found Mojo/Mojolicious to be both well designed and well maintained. I don't deny that sometimes Java, Erlang or Go is the correct tool. I am actually very interested in Go and use many tools written in it like Docker/Kubernetes, Consul, Terraform etc. Go will probably be my choice for anything that needs concurrency until Perl catches up or something else better comes along. But I will not abandon Perl for my unix scripting needs as it is still the best in my opinion. Getting max work done in a short time and with less code with max convenience and unix-y feel is where Perl whipes the floor with every other language. And that is also a sweet spot for DevOps needs where you don't develop everything from scratch. You take the best practices tools of the day and glue it together with Perl. I am sad to see someone like you that clearly was involved with Perl at one point abandon it completely. The thing is that for every negative comment someone with a bit of clout spews on the internet there needs to be hundreds of positive ones to counter it. I still hear that "Perl is dead" because of that guy who clearly did not know Perl and used an example from the Stone Age that at one time was considered a feature but we now know is a vulnerability. It also exists in PHP by the way, and web developers worth their grain of salt have known better than to let user data just pass unsanetized to internal execution for quite some time now... I call TIMTOWDI and hopefully we will se you back in Perl some day. You know it is a very special little language and if you ever "clicked" with it you will always miss its good stuff.