6 ms·
Hey, downvoter: Perl is cooler than you.
by vgy7ujm 10y ago
Hey, downvoter: Perl is cooler than you.
- deleted 10y ago[deleted]
- gtirloni 10y agoI didn't downvote you but I see zero people using Perl in DevOps and no job posting I've seen lately asks for it. I've worked with Perl in the past and it's as capable as any programming language out there, but the ecosystem isn't there anymore. At least not for DevOps.
- vgy7ujm 10y agoI use it. And bash more often than any of Python or Ruby. I use Go tools more often than tools written in Python or Ruby these days. Demand for something in job ads does no always equal what is used out there. My current job was not announced as a Perl job. The HR department had listed Python though. We use zero Python in our product or tools.. There was already some Perl here. Actually when looking past the makefiles I discovered that the build system was 90% Perl. Let's just say they got lucky with the hire since no one had a clue when they were recruiting. I think this is the situation in lots of places and if you know your devops and prefer Perl you will do as good as or better than anyone using those other languages that "surely must be dying now that we have Go.."
- muraiki 10y agoI have an anecdote to add. I worked for a web hosting company that has around 20 years or more worth of Perl code doing all aspects of devops and also for building numerous services along with web applications. I spent a lot of time learning Perl, using it for both maintenance programming and greenfield development. I also made an effort to interact with the greater Perl community and to keep up with new technologies they've created (such as Mojolicious and Dancer). I've used both old school barebones Perl OO and "Modern Perl" with Moo and Moose. I think that Steven Little summed Perl's situation up correctly in his talk, "Perl is not dead, it is a dead end"[0]. I strongly feel that Perl became a competitive disadvantage for us. New systems that we wanted to use, such as Openstack or Kubernetes, are not being written in Perl. SDKs for services that we want to interact with do not exist for Perl. Simply dealing with the distinction between numbers and strings in JSON was a constant source of pain. Everything we wanted to use we had to make ourselves, which is a huge amount of work. We simply couldn't leverage the open source community's efforts on languages that are much more popular. This is not to ignore the success of the company, which was only possible because of Perl. But in 2017, if you really want to use Perl as the basis for your tech stack or even just in any sort of tooling, you had better expect to write everything on your own. Meanwhile, your competitors can leverage the vastly more active communities of Python, Javascript, Go... heck, even C# nowadays. CPAN was once tremendous, but it really doesn't compare anymore. [0] https://speakerdeck.com/stevan_little/perl-is-not-dead-it-is-a-dead-end https://speakerdeck.com/stevan_little/perl-is-not-dead-it-is...
- vgy7ujm 10y agoFor 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 agoAnd 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.