Perl 27 years later

                              An ordinary programmer only knows about Perl that the language is dead, 
                              and the code on it is unreadable. But a Perl programmer often doesn't even know that.
                              Every budding rock band should have a Perl programmer, 
                              who would invoke a demonstration of his crooked unreadable code from the scene
                              to the base instincts of the crowd, warming her up.
                              Tribute to stereotypes.

    Contrary to stereotypes, Perl still exists. He lives somewhere on the periphery of the consciousness of those who do not write on it. It causes them great misunderstanding when they meet those who write on it. The culture of Perl is so blurred in time, so imbued with the stability of the language, that it is quite difficult for an outsider to understand what Perl is today. And how to deal with it.

    A myriad of articles on the Internet describe Perl of those times when the sky was green, the grass was blue, and Yeltsin, in a drunken stupor, pleased the country with incendiary dances in front of television cameras, setting the rhythm for the ravers that danced on that blue grass and under that green sky. And the code from those articles is still compiling. As a result, most programmers have an idea of ​​this language represented by information 10-15 ... and even 20 years ago. The inertia of thinking of those who wrote those articles should not be overlooked.

    Therefore, today I will try to shed light on what is happening with the language in its 28th year of life. After all, today is Perl's birthday - he is 27 years old. 20 years of which there is its fifth version. Come in, it will be fun.

Is it still in use?

    Yes, it is still in use. According to webtech , Perl in terms of prevalence still holds an honorable sixth place among languages ​​on web servers, for some reason losing to ColdFusion, but then beating Python. The main thing is to play the card of a good marketer and keep silent about the fact that the total Perl share is only 0.5%.

    And what is created and works on Perl in general? A lot of software, both simple and complex, including. used on the web. Perl, after all, is a fairly broad language and you can find everything on it - from desktop programs and servers to telecoms to hated websites. Buzzfeed, the site of Komsomolskaya Pravda, a significant part of the site code of the largest CIS domain registrar Reg.ru, the operators of the cold calls department of the European department Vodafone, choose the next victim of intrusive advertising using a program written in Perl ... of course DuckDuckGo is also worth mentioning as a service known to many. Unfortunately not to mention, so much has been created in Perl, and the web is just one of its areas of application. Perl's free license has led to that he often gets into the firmware of routers, and God knows what other commercial products. It is difficult to say how strong Perl's position in bioinformatics is, given the strong expansion of python in this area over the past decade, but it is definitely actively used there.

    Perl is also a huge amount of glue between tools written in different languages, no, just a monstrous amount of glue. It is so often written scripts on it to import new data into old programs in compiled languages, the code of which can no longer be found. For them, wrapper scripts and generally graphical interfaces are created, which were not provided at one time. In 2011, I came across a vacancy of barley to support the assembly system of a large Java project. Which can tell us both about the usefulness of Perl and the fact that the Java ecosystem is so overcomplicated that it’s sometimes easier to keep one warlock with Perl than two Maven experts ...

    This is often written in Perl for automation scripts, when there is no more urine to endure sh, or powershell seems a dubious option. The number of single-line systems that system administrators of the whole world write to Perl every day, compensating for the imperfection of the tools they use, simply cannot be calculated. Undoubtedly, Perl makes an important contribution to the development of such an industry as door construction, being an important tool for black seoshniks. Consider it a bedroom theme.

    Looking at vacancies related to web development, and especially those that appear on freelance websites, it might seem as if grabbers with parsers are written on Perl. A somewhat more complete understanding of what and who is written in Perl in the field of web development can be obtained here and here., and a little bit here . But not at the freelance exchange.

    Many small projects are written in Perl mainly by enthusiasts. If during a creative fever they slipped a note - believe me, they would write a project on the note too. So such projects can not be taken into account. And medium and large projects exist (and even are created!) In Perl for several reasons, and enthusiasts have nothing to do with it:

• so historically. There was no alternative to Perl until 2005, especially in the niche when PHP was already missing and Java was already overkill.
  
  
• with a certain complexity, the web project grows to such a size that it goes beyond the scope of a simple request-response. A complicated and confusing backend appears, where there may be different schemes for caching, content regeneration, integration with system tools. And on the backend there are different demons that do all this. And with all the demonization of PHP by programmers in other languages, not all demons can be written on it, and not everyone can. A similar reason explains why, with much better web frameworks, some projects are written in Perl and Python.
  
  
• you have tons of business logic that goes back to the crazy 90s. You rip off pieces of code from an old Tk program, sculpt them on a REST server, and the perlcode gets a rebirth. The beauty of this approach is that, due to the high stability of the language, changes in the code are usually so minimal that you yourself might think that Perl is already dead.
  
  
• a subset of the previous paragraph - Perl is too good a language for prototyping, not only due to the language itself, but also due to a bunch of modules in CPAN. Therefore, from a certain moment, the prototype written on it can take a deep breath and climb into the server rack of the nearest data center with a creak.
  
  
• the customer spent half of the project budget on validol after he heard how much the javists would take for the specified project. I don’t know why, but foreign customers have some strange reverence for this language, and they are often ready to consider it as an alternative to Java. Not from the point of view of functionality, which for obvious reasons they do not understand, but from the point of view of reputation.
  
  
• after all, Perl is a full-fledged programming language, which constantly brings the best of other languages, and which has everything necessary for the implementation of almost any pressing tasks.
  
  

Resuscitation

    Perl has long been losing ground in web development, not least under the pressure of PHP. The niche was considerable, but losing the language that was intentionally created for web development (at least the same as it was in those days) was quite logical. In the end, Perl was created somewhat for the other. But despite this, problems accumulated in the language - non-standard OOP still scared many people, web development frameworks objectively lost to competitors in other languages, there was simply no comparable IDE (and now, in principle, no), the cost of Perl programmers is often It was higher than PHP-shnikov with a comparable complexity of projects. Then, I myself, I confess, believed that Perl could not adapt and would eventually be crowded out everywhere, and would return to its historical place as a system administration tool.

    This situation was until about 2008, although this is my subjective assessment. Then went hype in Python. This language could completely replace Perl in the niche of bioinformatics, complex web systems, system programming for Unixes (by the way, it was always a mystery to me why the term "system programming" in the Windows world refers to communication with the kernel and writing drivers, and in the Unix world this usually means all sorts of service scripts). And with that powerful support and enthusiasm that arose around the python, if Cobol was in its place, and if it fell into the hands of Google just in time, the result would be the same. Also, this go-ahead from Google gave the go-ahead to the use of scripting languages ​​to all fans of compiled languages, who had hitherto considered that touching scripts was superior to their dignity (according to other sources - understanding). And then it turned out that Python solves the important problem from Computer Science, which is stated as "Even your Mom handles strings better than your compiled language". The importance of this problem is hard to overestimate, and therefore you should not blame those who discovered Python for excessive enthusiasm and tried to impose it on others in every way.

    But ironically, it was Python that gave Perl a chance for development. In addition to Django, python did not have full-stack frameworks, and Django was so good at creating news sites that soon there were more news sites written by him than there were significant news going on in the world daily. It was then that it turned out that not all sites should be news and written using Django. No sooner said than done. A trend has emerged for microframes like Flask, Pyrmaid, Bottle.py (may the nutritionists forgive me for such a free interpretation of the term "microframework"). Perhaps the point here was also that the popularity of REST services was growing, and python had nothing to do with it at all, but microframes went into circulation.

    In Perl, in addition to Catalyst, the second wave frameworks appeared: Mojolicious, Dancer and Jifty. In terms of full stack, they still did not reach the full-fledged PHP-shy Zend or CodeIgniter, but against the background of the Python micro-frameworks they looked quite decent. And most importantly, it was an indicator that the community is still responding to the challenges of our time.

    At the same time, part of the community was actively rushing between Perl, Ruby and Python, dragging features from there. And not only features, but in general style and good practices. At that time, the split of the Perl community into 2 groups was especially clearly marked - actually those who want to pull Perl out of this swamp, and those who are used to writing the best Perl 5 tradition (Perl 5.0 was released in October 1994). And the latter cannot even be reproached - there are quite a few system administrators among them, for whom Perl was ideal in the form in which it existed in 1994. Such a bundle is often seen at conferences, where after a report on how someone wrote in Perl convenient a script that sends him new SMS with eBay by SMS, there is a report on the problems of complex infrastructure using Corona, message queues, own CPAN repository and other terrible things.

    But overall the situation is improving, and Perl has already overcome the point where a final breakdown in stagnation was possible. The community still recognizes its problems and the ways to solve them are visible. Of course, there are not enough resources - in a last year’s report on one of the YAPCs, information slipped through that a couple of people understood the entire C-code interpreter, and another 15 could understand their subsystems. No need to dramatize these numbers - they do it almost for free, but how many people want to delve into the old C-code, and especially in the guts of the interpreter of a whole healthy language, when one of the key requirements is not to break compatibility?

    Of course, Perl will not have such a good IDE as for PHP or Python, because there is not so much commercial support on the one hand, and there is no syntax simplicity that would easily allow you to create Perl parsers that are necessary in every somewhat serious IDE. And even if they are, they will have to catch up for a long time - in fact IDEA and Microsoft are monopolists in the IDE market, they have set such a standard for language support quality that even Eclipse, which has a huge community, is losing ground. Also, due to the fact that Perl is not a purely web-oriented language, the concentration of efforts on web frameworks that occurs in the case of PHP is simply impossible. But given the fact that the thick frontend is gaining popularity everywhere, this is not so scary.

    As for Perl6, it can both give a second wind to the language and play a trick on it, like the third python branch, which was ignored by the community for a long time due to the reluctance of many authors to rewrite Python libraries for the new version. On the other hand, Perl6 solves the important problem of the fifth branch - finally, there is a language specification according to which anyone can write a compiler, which, firstly, will simplify the life of IDE developers, and secondly, it allows you to run Perl6 programs on several backends today, in including JVM.

    Now the outlook for Perl is stable positive. Do not forget that before Perl both Python and Ruby experienced ups, and as a result the noise subsided, and languages ​​firmly occupied that niche in which they really apply. It remains to wait until the same thing happens with Javascript ...

Mythology

    Perl will long be viewed by outsiders, not in terms of the current situation, but in terms of myths about it that go on the net. Typically, these myths affect the unreadability of the code, the importance of regular expressions, the obsolescence of the language, CPAN, Perl6, which will obviously be the zero rider of the apocalypse. And of course, the most important thing is that the language is dead.

His Majesty's unreadability

    According to the statement of those who complained about the unreadability of Perl, there are several main problems:

• Misunderstanding why unless is needed, this if with an inverted condition.
  
  
• Misunderstanding of regular expressions. Unfortunately, those who are too lazy to figure out exactly how regular expressions work, will not be happy with them in any language.
  
  
• Double sigils of the form $, @,% in constructs of the form% {$ self -> {'posts'}} or @ $ posts in which complainants see something more than simple type casting.
  
  
• Here is this code: echo "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|\`{;;y;-/:-@\-`{-};\`-{/" -;;s;;$_;see'But why complain about obfuscated code when other languages ​​elevate code obfuscation to the rank of useful, if not mandatory, technology?
  
  
• Lack of documentation in the code. The fact is that it is often not customary to write function documentation in the Javadoc style - before each function. As a result, the whole beautifully designed footcloth documenting the module is taken out either at the beginning or at the end of the module. Perl gives such freedom. Some programmers feel so free that they don't write documentation at all.
  
  
• A bunch of special quotes and implicit variables. There is a subtlety: instead of a table of variable values, you should make a table of variable names, and then everything will fall into place.
  
  

    Despite the unusual syntax for many other languages, it seems to me that the main reason for rejection is hidden in the dark times when Perl was popular, but the rules of good form in writing code were not popular. In those days, there were many languages ​​in which such code was created that it was difficult to read. But on Perl this code was created more. Ponder this paragraph, it’s not "bad code can be written in any language." Ask yourself, could the industry satisfy the need for good web programmers in the 1990s or early 2000s? Or maybe then on the web (and as a result in Perl) everyone climbed for money, as they are now getting into mobile development, garbage AppStore and PlayMarket?

    Ruby allows you to create on the basis of yourself a new language (DSL) that will work. Perl, in this regard, chose a slightly different path - while you write in any language, the interpreter will consider that you write in Perl. On the one hand, you do not need to describe your DSL as in the case of Ruby, on the other hand, the interpreter can catch more sense in your code than other programmers doomed to support this code in the future. To combat this, there are code standards designed to in every way oppress the creativity of Perl writers. And, no matter how hard it is for me to admit it, but they work, though they work mostly in commercial companies. This is surprising, but the code of an average Perl project on a github looks worse than the code of some commercial project with closed source code.

    The fact that backward compatibility is strong in the language makes us think that once the code written in 2004 will stop working like this in 2024 and will come out. To the delight of archaeologists and pearl haters.

OOP

    Perl has 3 OOP related issues:

• the lack of standard OOP syntax common to many
  
  
• lack of understanding which module to choose to support OOP syntax common to many
  
  
• the lack of a generally accepted training manual (as in the case of Javascript) with an algorithm to explain to opponents why the first 2 problems are not problems at all
  
  

    But this year, at last, some progress has been outlined - the community agreed on the need for a standard language delivery of a unified OOP system that would not first drive novices into a stupor, and secondly, be compatible with all existing OOP implementations. Read more here .

    In some ways, the situation is similar to Javascript - only in its case we sculpt crutches to the function prototype to depict the object. And in the case of Perl, we sculpt the constructor for the package (or module, if you prefer), turning it into a class. There is only one final - supporters of the traditional OOP do not observe standard encapsulation and polymorphism, but we observe prostration and phallomorphism of the supporters. But it’s not easier for anyone. Perl, unlike Javascript, doesn’t have that demand today to be forgiven for minor flaws. But we forgive - in almost all large projects that I have come across, the standard package-based OOP for Perl is used, and not one of the libraries.

    In general, OOP in Perl is standard - and that is why many interpreter maintainers do not see the point of making an implementation with the usual syntax. So that you can imagine the difference with Javascript, we don’t overwrite the unfortunate function with other functions to get the class visible. We do not patch a function prototype with another function in order to obtain inheritance. In Perl we create a package (module), and then we have a choice - import functions from it as from a module, or add a constructor to the module and use it as a class. Well, if we need inheritance, then for this there are built-in language tools designed specifically for this. On the other hand, the declaration of classes in Perl is the most verbose among all languages; on the third hand, finding an editor in 2014 without snippets is becoming more and more difficult.

    Speaking of objects - Perl is one (if you think that PHP is also a general-purpose language, then not one, but God be your judge) of the few remaining general-purpose scripting languages, where simple data types like strings, numbers, arrays and hashes are not made in as standard objects, but as built-in types. And this, on the one hand, is pleasant for those who love simplicity, on the other hand, it makes chain calls of functions more difficult.

CPAN

    Once the most important advantage of Perl, and now it's just a necessary attribute to be no worse than other languages. But the attribute is not the worst available. Compared to Python, Ruby, Javascript, there are fewer ... hipsters. Yes, yes, those same guys who are so eager to glorify themselves on the github. And then consolidate their fame in the package repositories of their chosen language. There are much fewer such ones in CPAN, because what is the point of PR and typing in the resume for an unpopular language. Maybe I'm wrong, but do you really believe that all 110,000 packets in npmfor a web oriented language are useful and quality? Even if we assume that because of the Javascript node it was used not only on the web, and all these modules are really useful things or, at worst, bindings to existing libraries, then it's just a minefield. It is physically impossible to lick such a large amount of code from different people in such a short time.

    Specific figures for statistics on the number of modules for different languages ​​are given at http://www.modulecounts.com/ . And seeing that Perl is at the very bottom of the rest of the languages, I, as an interested person, will try to come up with comforting explanations in this regard. Firstly, if you look at CPAN itself, then there are still more than 140,000 modules. But there are distributions (a collection of modules often, but not always, depending on each other) and there are really about 30,000. That is in terms of the number of modules CPAN is still leading. Modules in the sense of units of code that can be connected and used on their own. For example, there are 2 modules LWP and LWP :: Simple - both are included in the libwww-perl distribution. In addition, each module can be used on its own and provides a different interface for working with it. Although the modules may have common dependencies or depend on one another. But let's say that it is modules outside of distributions that are considered a bad idea (although how I can count in repositories of other languages ​​I can only guess, and I have suspicions that even forks can be counted there), and consider other languages.

    We kind of figured out Javascript. With Go, the situation is that there may be several versions of one package, judging by the index, as well as * -dev versions. In Python, it is often customary to design not only libraries as a package, but also many applications, scripts. Yes, this is in all repositories, but in python this comes across to me more often. But still, I think that the numbers for python are close to reality, especially considering that python is a general-purpose language and also with a good reputation. Although the moment is not understood how packages are considered for the 2nd and 3rd versions. As for Ruby, everything is already outlined . Also, this site does not show the number of edits and updates to existing packages. Even without looking at the situation of other languages, in the case of CPAN updatesmany, often more than a hundred a day. For December 5 - 194 updated modules per day. Dead languages ​​do not behave this way.

    In general, CPAN is still good. It is so good that it is the only one of the repositories, when installing packages from which I do not start to get nervous, thinking that something will break in the process.

Jobs

    Although it is generally accepted that all Perl programmers sit idle, there is work on it. However, there are 2 “buts”: firstly, few people need junior pearl barley, and secondly, most of the work on Perl involves work in the office. Those. on freelance projects there are few and usually (especially in RuNet) this is a low-paid bucket. Yes, that's right, by the word "low paying" I mean rare piecework projects worth from 10 to 200 dollars. By the word "bucket" I mean that you will have to work mostly with people who want either the parser of someone else’s sites, while the parser usually comes out more intelligent than the customer, or you’ll make edits to the custom CMS (or web store ), which has been playing hide and seek for years and decades. And believe me, it would be better if she was the winner in this game and with you.

    There are some companies willing to pay you perlocode remotely. At least it's oDesk and Buzzfeed. But in general they are few. And hourly rates there are not the highest - mostly $ 15-20 / hour. Projects above $ 30 / hour are hard to find - they will force you to drag them into the office or refuse your services. At the same time, selling yourself for $ 50 / hour on the same oDesk is real, but it will be episodic work. Very episodic. Probably this paragraph is true for almost any language ... Finding a remote job with a payment of up to $ 2500 is not so difficult, difficulties will arise when you want more. In the CIS, I could not get remote work with a payment of more than $ 1,500, maybe it will work out with you.

    But not everything is so sad if you tear your ass away from your favorite chair to exchange it for an office chair. Offline work on Perl is available both at home and abroad. By the way, there are a lot of her abroad, but don’t hope that you will be kissed in the gums and run to get an H1-B visa. Although such employers are found. In general, see for yourself. It will be interesting if one of the readers in the comments tells if everything has worked out well with foreign companies and Perl at the same time.

    If the rotting west disgusts you, we can also work with barley. Sometimes even in the regions. Remember the CMS that play hide and seek? So you can find out not only when she hid, but also where her lair is, and maybe even spread a word with her repentant creator. And, of course, in the regions there are body shops, in which barley is sometimes needed.

    In the capitals is our eternal everything - mail.ru, yandex, reg.ru. Our hope and support, a living reminder that Perl is still needed. If you see someone on YAPC or Perl Workshop and he speaks Russian, then with 90% probability this speaker works somewhere in this trio. From myself I recommend reg.ru - a pleasant interview, professional programmers, which are few, and also use SIP instead of blasphemous Skype.

    Of course, now Perl is not a salary ceiling, but, in comparison with other languages, salaries on it start at an average level. Those. you can get a junior PHP-shnik or a RoR-sheep for $ 500 (Muscovites, keep quiet!), and for Perl there is most likely no such vacancy on the one hand, and on the other, the requirements for middle-pearl are lower than for the mentioned languages. Summarizing, there are fewer jobs on Perl than in many other languages, but this job is looked for in the context of less hassle - you will immediately have normal jobs. And bet on Perl as though the main tool for remote earnings is probably not worth it, at least at first.

Web development

    Writing websites in Perl these days, if not sinful, then absurdly for sure. So many people think. And this is partly true: even the whole beauty of Perl is not able to compensate for the myriad of man-hours that you need to invest in a web framework in order to get something to work productively with. And, I note, all languages ​​are more marginal than PHP, namely Ruby and Python have only one such monster.

    Mojolicious, Dancer (?), And Catalyst are the 3 pillars on which modern Perl web development rests. Even in the dark depths of the ocean, monsters like Maypole and Mason are hiding, but you can rarely run into them. And, working with them, there is a risk of getting rich or losing one's mind. And often, both. But all this is a bit different from what you are accustomed to in other languages ​​that have won the favor of the web programming god.

    Perl does not have integrated solutions of such a level as Django, Symfony, RoR. There are either microframes that are basically the same in all languages, or Catalyst is a heavy framework that more or less corresponds to the idea of ​​what a typical fullstack MVC framework for the web should be like. But you yourself choose the method of sending mail, ORM, test framework, etc. Even if in the case of Catalyst you will have the recommended ORM, the template engine, but most likely in the end you hang it with a bunch of all kinds of things, creating something of your own. There are no two similar projects in different companies that would be written on Catalyst. And you will not have the amount of gems or bundles that RoR and Symfony have.

    Integration with client code, work with assets - in the Perl world, all this is also not subject to fashionable trends. You do it as you please - there are those who use rake with the right gems in Mojolicious projects. Another thing is that if you pull yui-compressor through a make-file, then in the Perl world this will be the norm, and in the case of any RoR you can get it on your hands.

    On the one hand, all this gives every right to talk about the backwardness of Perl. On the other hand, after 3 years of working with Symfony and its Procrustean guides, I’m no longer sure which approach to web development is a lesser evil. A good framework will sooner or later get across your work. He has two whole ways to do this: to be too inflexible for you to cry out in attempts to fit into it, or to be flexible enough for you to howl from the weak coherence and smearing of algorithms by code.

    For those who are used to PHP frameworks, the main problem of Perl web development is that you cannot download the archive with the framework, unzip it, and put your code in the src folder. You have to choose how you will work with the database - through ORM or queries, how to generate forms - by hand or using FormFu, and this will determine what your web application will look like. It's not so scary - to understand other people's projects on the same Catalyst or Mojolicious is easy, regardless of which modules are crammed there. But for programmers in other languages, this approach will be unusual.

    Today, most web development is a constructor. To fasten registration through social networks (preferably through all at once), add buttons of likes of the same social networks. networks, integrate with payment systems, add web chat, etc. Of course, not even the language is important here, but the availability of ready-made SDKs, modules, and recipes. Perl here definitely loses, and making many types of sites on it is not always advisable. Once again, what would you feel - Perl lags behind PHP in the same way as the framework lags behind CMS. The framework can be safer, faster, more enjoyable for programming, but part of the work has already been implemented in CMS, this is a saved man-hours. But if there is at least some complex logic in the project and you do not plan to respond to each performance call with horizontal scaling, then Perl still shows itself well.

    True, it’s possible to get money in bulk on Perl - in RuNet there are a lot of craftsmen who have their own frameworks (usually FatFree level), and who are ready to issue typical sites on them in batches, and automatically deploy them to the most hosted shared hosting, which itself It’s not always supporting itself, not like the site located on it.

Perl 6

    The creator of the language Larry Wall loves to excite people with the imminent release of the sixth version of the language. Almost every year. And it began around the year 2000. Perl6 will be released by Christmas, he liked to say, but after Christmas, he refers to the fact that he was not given a specific year. However, this time he surpassed himself and dared to say more than usual . So maybe in the new year everything will be new.

    And given the degreecoverage of language specifications by implementation, maybe in 2015 we really will see Perl6. This is also supported by the fact that, in addition to Parrot, Perl6 did not support other backends for a long time, and C # and JVM backends have appeared in the last few years. Moreover, a backend based on MoarVM appeared, which seems to take into account the shortcomings of the Parrot virtual machine. And with a high degree of probability, the backend on MoarVM will become standard for Perl6.

    Perl6 is not compatible with Perl5. The syntax is pretty much alike, ideas too, but it's a different language. And even if it will be released in production next year, and even if it will be possible to achieve performance level fifth version, fouling modules will be long. Nevertheless, it is hoped that Perl5 modules from Perl6 can be used. Rather, you can do it now:https://github.com/niner/Inline-Perl5/ . But this technology has not been tested in large quantities, so it’s hard to talk about its applicability in real conditions.

    From the point of view of the mass Perl6 programmer, the truth is better than the previous version - there will be no need to sculpt%, @ before different types of variables, the usual OOP will appear, method calls for simple types will finally become available. True, for the same mass programmer, in the case of the release of Perl6, little will change - the fifth branch will not go anywhere, like the code on it.

Community

    Perl has a large community. A community too large, unforgivably large for a dead language. Moreover, some large libraries have their own support groups, not to mention frameworks. Usually, help can be obtained through mailing lists or on the irc server irc.Perl.org, of course this does not negate the availability of Perl channels on Freenode. Yes, in our age, irc and mailing lists look pretty outdated, but no, these are great ways to organize masses of people. Thanks to mailing lists, it’s easy to find solutions to problems that were solved 10 years ago, and thanks to IRC, you can chat with people who wrote on Perl 20 years ago. Just put up with the fact that the lion's share of active members of the Open Source communities are still sitting in the IRC.

    There are so many people in the Perl community that one wonders where they are all employed if there is no work at Perl. We write this to the omission that Perl is such a good language that many people write it for the soul. Or from hopelessness - in view of its presence in many legacy programs and components of UNIX systems. There is a special layer of people who are more inclined towards Perl culture than to programming in the language itself. Yes, we also have fanboys. But language will not turn to call them boys.

    By the way, finding Perl programmers is quite simple. Finding good Perl programmers (as well as any other language) is not so easy. Finding good Perl programmers at irc.perl.org and getting help from them is easy. We still have (at least in the CIS) a large percentage of people who started with Perl 10 years ago and still use it and still write on it like it was 10 years ago. As a rule, they sit on freelance and write the very grabbers and parsers or sites using the good old CGI. And these people can also give advice, and these tips will work! Well, what can you do if the language is stable. And you should be very skeptical about the tips of barley from RuNet (for example, mine) - such advice, when applied on time, can help not only solve the problem,

    There are also perlmonks.org . If for some reason the stackoverflow is blocked by Roskomnadzor, you can search for the answer to your question there. No, this is not a bad site, it's just that there is usually little information about web development.

    The Perl community is attractive in some ways, although there are still few newcomers, but there are a lot of good people. The system of meetings and conferences is well established, many of them are held around the world. Many speakers have a good sense of humor, usually kindly and unofficial (and office humor is emasculated and conditionally unplanned vulgarity), such that during a speech one does not want to get up and go out or turn off the player. Another, albeit technically uninteresting, report goes well under a plate of pasta on Saturday night. The community has few empty arguments and aggression towards communities of other languages. Due to the fact that there are not enough good barley, you will soon see that the same faces constantly flash at all conferences in the CIS, for example, in August even Larry Wall himself was noticed in Ukraine.

Should I learn Perl?

    If you already know some language in which it is convenient for you to write scripts for processing data, generating test databases, parsing and converting data, then you do not need Perl. Although, to be honest, some modules for basic things in Perl, such as working with mail and ftp, are still more stable than in the same python.

    If you write a lot of scripts in sh, then you should try to force yourself to do the usual things in Perl. The fact is that in the case of single-line perl, you can put more functionality into a script that you can still edit directly in the console, rather than create a file for it.

    If you want fast and easy money, then you do not need Perl. Although in Moscow there may be people who will feed the junior. If you are willing to spend a couple of years and want a lot of money, then it's worth a try. The amount of legacy code in Perl is huge, especially in the west.

    If you want to professionally engage in web scraping, then get out of your head everything except Javascript and phantomjs. In the yard in 2014 and downloading with subsequent parsing of HTML no longer gives the desired result. Or use Perl bindings to phantomjs.

    If you are just starting to learn programming, then I advise you to familiarize yourself with Perl, as a language that combines several paradigms. Even if you are turned back by the syntax of Perl itself, I advise you to read Programming Perl, even in Russian: Programming in Perl, 4th edition. Just because the book touches on a bunch of other things, like Unix philosophy, network programming, concurrent programming, the concept of regular expressions. This book is an introduction to everything that you will encounter in the future, even in other languages, and it is written in the same style as this article.

    If you are a programmer in a compiled language, or working with microcontrollers, but do not plan to surf the web, then you should definitely study Perl - even at the minimum level of knowledge you will have a powerful tool for code generation and all sorts of small assembly scripts. Generating if / switch footcloths for drivers using tables from documentation, state machine tables, etc.

    If you plan to seriously engage in network programming, then Perl can be useful for you at least for prototyping, creating test traffic and stub servers.

    If you like to write code in your favorite text editor, and IDE lovers accuse you of inappropriate retrograde, then Perl will be a very good choice - using a language for which there is no convenient IDE, you will have a good excuse why you do not use it.

So why Perl and not something else?

    Everyone decides for himself. What I personally like about Perl, among more or less provable things:

• Separate operators for comparison and concatenation for both strings and numbers
  
  
• Broad interpretation of false: "", 0, undef, () are interchangeable to a reasonable extent, without draconian comparisons using === both in Javascript and PHP
  
  
• Strict syntax; in real projects, it is really strict; you will not find there the horrors that are commonly believed to occur in every Perl program.
  
  
• Declaration of variables indicating the scope, as well as the localization of external variables within the block.
  
  
• Approach to documenting CPAN modules - usually, to use the module, just read the Synopsis section.
  
  
• Convenient assignment in a list context.
  
  
• Working with Unicode - sometimes it seems to me that Perl maintainers lick it first and foremost, and they do everything else on a residual basis.
  
  
• The implicit variable $ _, like this from Javascript, is only more convenient. Because $ _, unlike this, can be omitted.
  
  
• An ideal selection of functions that you don’t need to import, work with files, regulars, date, random, directory traversal, sleep, printf ...
  
  
• The simplicity of the language - you can write on a small subset of the syntax.
  
  
• You can write in a style close to PHP, and the code will correspond to the generally accepted ideas of today how the code should look.
  
  
• Single line running on the command line. Yes, almost all interpreters of other languages ​​have this opportunity, but here everything is thought out and convenient.
  
  
• POD, it looks beautiful, it looks like documentation. And not as a Javadoc type annotation.
  
  
• It is convenient to write service scripts on it, which sooner or later are required for a large web application.
  
  
• The absence of argument signatures allows us not to refactor all calls of the subprogram, but simply to check whether the argument was passed in the subprogram.
  
  
• Perl is on almost any Unix from any hoster. Yes, python too, but there may be a deuce, a triple, and it is unclear which libraries.
  
  
• Conferences, many conferences. One story is more surprising than another.
  
  
• We have a whole monthly magazine in Russian dedicated to Perl
  
  
• Legacy on Perl is interesting, there is something to see, especially on ways to scale the pre-cloud era.
  
  
• The stability of the language is comparable only with C and Java.
  
  
• A simple deploy through copying code through explorer. Complex deployment through its CPAN repository. Newfangled deployment through Carton. Senile deployment through the Makefile. And everything is acceptable by the community.
  
  
• Pleasant interviews. Most often they offer test tasks or conduct general conversations. No furious botany.
  
  
• Among colleagues there are few young and enthusiastic. Mostly people just do their job.
  
  
• A culture that preaches many ways to do the same thing eliminates many conflicts in a team.
  
  

    And most importantly - Perl does not interfere with thinking, unlike many languages. There is no concept right and wrong, you can focus on solving the problem, and not on everything to be in accordance with the high calm. Of course, there are some norms, coding standards - but this is not that level, this is the level of regulated rules. There is no need to chase after someone, no need to listen to the opinions of superstars, no need to try to match some kind of standard. You do not need to use the correct library, which is now in fashion. You can do as you please, and this is an unacceptable luxury for many mainstream languages.

    Outside of work, you will have every right to write thrashy govnokod from the 90s, and if you post this code as a solution on the forum, they will not make fun of it. The community has not accepted cheap self-assertion, but everyone understands that everyone has a different level of language proficiency. They don’t chase after the perfect code, because every day they see not only complex systems, but also scripts written on their knees. This is a kind of vaccine against the panic fear of govnokod, which is so permeated by many communities of other languages.

Finally

    No matter how much the cat doesn’t kiss the nose, it still dances.