Perl. 27 Jahre später

                                  Ein gewöhnlicher Programmierer weiß nur über Perl, dass die Sprache tot ist, 
                                  und der Code darauf ist nicht lesbar. Aber ein Perl-Programmierer weiß das oft nicht einmal.
                                  Jede angehende Rockband sollte einen Perl-Programmierer haben, 
                                  wer würde eine Demonstration seiner krummen unlesbaren Code aus der Szene aufrufen
                                  zu den Grundinstinkten der Menge, die sie aufwärmten.
                                  Tribut an Stereotype.
    

        Im Gegensatz zu Stereotypen gibt es Perl immer noch. Er lebt irgendwo am Rande des Bewusstseins derer, die nicht darauf schreiben. Es führt zu großen Missverständnissen, wenn sie auf diejenigen treffen, die darauf schreiben. Die Kultur von Perl ist in der Zeit so verschwommen und von der Stabilität der Sprache durchdrungen, dass es für einen Außenstehenden ziemlich schwierig ist, zu verstehen, was Perl heute ist. Und wie man damit umgeht.

        Eine Vielzahl von Artikeln im Internet beschreibt Perl aus jener Zeit, als der Himmel grün und das Gras blau war, und Jelzin erfreute das Land in betrunkenem Zustand mit Brandtänzen vor Fernsehkameras, die den Rhythmus für die Raver festlegten, die auf diesem blauen Gras und unter diesem grünen Himmel tanzten. Und der Code aus diesen Artikeln wird noch kompiliert. Aus diesem Grund haben die meisten Programmierer eine Vorstellung von dieser Sprache, dargestellt durch Informationen von 10-15 ... und sogar vor 20 Jahren. Man sollte die Trägheit des Denkens derer, die diese Artikel geschrieben haben, nicht aus den Augen verlieren.

        Deshalb werde ich heute versuchen, Licht in das Geschehen mit der Sprache im 28. Lebensjahr zu bringen. Immerhin ist heute Perls Geburtstag - er ist 27 Jahre alt. 20 Jahre, von denen es seine fünfte Version gibt. Komm rein, es wird Spaß machen.

    Ist es noch in Gebrauch?


        Ja, es wird noch verwendet. Laut webtech nimmt Perl in Bezug auf die Verbreitung immer noch den sechsten Platz unter den Sprachen auf Webservern ein. Aus irgendeinem Grund hat Perl gegen ColdFusion verloren, Python jedoch geschlagen. Die Hauptsache ist, die Karte eines guten Vermarkters zu spielen und darüber zu schweigen, dass der gesamte Perl-Anteil nur 0,5% beträgt.

        Und was wird generell erstellt und funktioniert unter Perl? Eine Menge einfacher und komplexer Software, einschließlich. im Web verwendet. Perl ist schließlich eine ziemlich breite Sprache, auf der Sie alles finden können - von Desktop-Programmen und Servern über Telekommunikation bis hin zu verhassten Websites. Die Perle sagt Buzzfeed, die Website von Komsomolskaya Pravda, ein großer Teil des Site-Codes für den größten CIS-Domain-Registrar Reg.ru, die Betreiber der Cold-Calls-Abteilung der europäischen Abteilung Vodafone wählen das nächste Opfer von aufdringlicher Werbung mit einem in Perl geschriebenen Programm ... Erwähnenswert ist natürlich auch DuckDuckGo , als ein Service, der vielen bekannt ist. Leider gibt es nichts zu erwähnen, so viel wurde in Perl erstellt, und das Web ist nur einer seiner Anwendungsbereiche. Perls freie Lizenz hat dazu geführt dass er oft in die Firmware von Routern gerät, und Gott weiß, welche anderen kommerziellen Produkte. Es ist schwer zu sagen, wie stark Perl in der Bioinformatik ist, da Python in den letzten zehn Jahren in diesem Bereich stark expandiert hat, aber es wird dort definitiv aktiv eingesetzt.

        Perl ist auch eine riesige Menge Klebstoff zwischen Werkzeugen, die in verschiedenen Sprachen geschrieben sind, nein, nur eine ungeheure Menge Klebstoff. Es wird so oft darauf geschrieben, um neue Daten in kompilierte Sprachen in alte Programme zu importieren, deren Code nicht mehr gefunden wird. Für sie werden Wrapper-Skripte und allgemein grafische Oberflächen erstellt, die nicht auf einmal bereitgestellt wurden. Im Jahr 2011 stieß ich auf eine freie Stelle im Bereich Gerste, um das Montagesystem eines großen Java-Projekts zu unterstützen. Das kann uns sowohl über die Nützlichkeit von Perl als auch über die Tatsache informieren, dass das Java-Ökosystem so überkompliziert ist, dass es manchmal einfacher ist, denselben Hexenmeister mit Perl zu führen als mit zwei Maven-Experten ...

        Dies wird häufig in Perl für Automatisierungsskripte geschrieben, wenn kein Urin mehr vorhanden ist, um sh auszuhalten, oder Powershell eine zweifelhafte Option darstellt. Die Anzahl der einzeiligen Systeme, die Systemadministratoren auf der ganzen Welt täglich an Perl schreiben, um die Unvollkommenheit der von ihnen verwendeten Tools auszugleichen, kann einfach nicht berechnet werden. Zweifellos leistet Perl einen wichtigen Beitrag zur Entwicklung einer Branche wie der Türkonstruktion, die ein wichtiges Werkzeug für schwarze Seoshniks darstellt. Betrachten Sie es als ein Schlafzimmerthema.

        Wenn man sich die Stellenangebote im Zusammenhang mit der Webentwicklung ansieht, insbesondere die Stellen, die auf freiberuflichen Websites zu finden sind, scheint es, als ob Perl nur von Grabbern mit Parsern geschrieben wurde. Ein etwas vollständigeres Verständnis dessen, was und wer in Perl auf dem Gebiet der Webentwicklung geschrieben ist, kann hier und hier erlangt werden.und ein bisschen hier . Nicht so beim freiberuflichen Austausch.

        Viele kleine Projekte in Perl werden hauptsächlich von Enthusiasten geschrieben. Wenn sie während eines kreativen Fiebers einen Knoten verschoben hätten - glauben Sie mir, sie hätten auch ein Projekt auf einen Knoten geschrieben. Solche Projekte können also nicht berücksichtigt werden. Und mittlere und große Projekte existieren (und entstehen sogar!) Auf Perl aus mehreren Gründen, und Enthusiasten haben nichts damit zu tun:

    • so historisch. Bis 2005 gab es keine Alternative zu Perl, insbesondere in der Nische, in der PHP bereits fehlte und Java bereits übertrieben war.

    • Ab einer bestimmten Komplexität wird ein Webprojekt so groß, dass es den Rahmen einer einfachen Anfrage-Antwort sprengt. Es erscheint ein kompliziertes und verwirrendes Backend, in dem es verschiedene Verfahren zum Zwischenspeichern, zur Inhaltsregenerierung und zur Integration in Systemtools geben kann. Und im Backend gibt es verschiedene Dämonen, die das alles tun. Und bei all der Dämonisierung von PHP durch Programmierer in anderen Sprachen können nicht alle Dämonen darauf geschrieben werden, und nicht jeder kann. Ein ähnlicher Grund erklärt, warum einige Projekte mit viel besseren Web-Frameworks in Perl und Python geschrieben wurden.

    • Sie haben jede Menge Geschäftslogik, die bis in die verrückten 90er Jahre zurückreicht. Sie rippen Codeteile aus einem alten Tk-Programm ab, formen sie auf einem REST-Server, und der Perlcode wird wiedergeboren. Das Schöne an diesem Ansatz ist, dass aufgrund der hohen Stabilität der Sprache Änderungen im Code in der Regel so gering sind, dass Sie selbst vielleicht glauben, Perl sei bereits tot.

    • Eine Untergruppe des vorherigen Abschnitts - Perl ist eine zu gute Sprache für das Prototyping, nicht nur aufgrund der Sprache selbst, sondern auch aufgrund einer Reihe von Modulen in CPAN. Daher kann der darauf geschriebene Prototyp ab einem bestimmten Moment tief durchatmen und knarrend in das Server-Rack des nächstgelegenen Rechenzentrums klettern.

    • Der Kunde gab die Hälfte des Projektbudgets für Validol aus, nachdem er erfahren hatte, wie viel die Javisten für das angegebene Projekt einnehmen würden. Ich weiß nicht warum, aber ausländische Kunden haben eine seltsame Ehrfurcht vor dieser Sprache und sind oft bereit, sie als Alternative zu Java zu betrachten. Nicht unter dem Gesichtspunkt der Funktionalität, in der sie aus offensichtlichen Gründen nicht verstehen, sondern unter dem Gesichtspunkt der Reputation.

    • Am Ende ist Perl eine vollwertige Programmiersprache, die ständig das Beste aus anderen Sprachen bringt und über alles verfügt, was Sie für die Umsetzung fast aller dringenden Aufgaben benötigen.

    Wiederbelebung


        Perl hat in der Webentwicklung längst an Boden verloren, nicht zuletzt unter dem Druck von PHP. Die Nische war beträchtlich, aber es war logisch, die Sprache zu verlieren, die absichtlich für die Webentwicklung entwickelt wurde (zumindest genauso wie damals). Am Ende wurde Perl etwas für den anderen erstellt. Trotzdem häuften sich Probleme in der Sprache: Nicht-Standard-OOP erschreckte immer noch viele Menschen, Webentwicklungs-Frameworks gingen objektiv an Konkurrenten in anderen Sprachen verloren, es gab einfach keine vergleichbare IDE (und sogar jetzt im Grunde sind die Kosten für Perl-Programmierer häufig Es war höher als PHP-Schnikov mit einer vergleichbaren Komplexität von Projekten. Ich selbst habe dann zugegebenermaßen geglaubt, Perl könne sich nicht anpassen, würde irgendwann überall überlaufen und als Systemverwaltungswerkzeug an seinen historischen Platz zurückkehren.

        Diese Situation dauerte bis ungefähr 2008, obwohl dies meine subjektive Einschätzung ist. Dann ging Hype in Python. Diese Sprache könnte Perl in der Nische der Bioinformatik, der komplexen Websysteme und der Systemprogrammierung für Unixe vollständig ersetzen (für mich war es übrigens immer ein Rätsel, warum sich der Begriff "Systemprogrammierung" in der Windows-Welt auf die Kernel-Kommunikation und das Schreiben von Treibern bezieht, und in der Unix-Welt Dies bedeutet normalerweise alle Arten von Service-Skripten. Und mit dieser starken Unterstützung und Begeisterung, die rund um die Python entstand, wenn Cobol an seiner Stelle war und es gerade noch rechtzeitig in den Arm von Google fiel, würde das Ergebnis dasselbe sein. Diese Freigabe von Google ermöglichte außerdem allen Fans kompilierter Sprachen, die bisher davon ausgegangen waren, dass das Berühren von Skripten ihrer Würde überlegen ist (anderen Quellen zufolge - Verständnis), die Verwendung von Skriptsprachen. Und dann stellte sich heraus dass Python das wichtige Problem aus der Informatik löst, das besagt: "Auch deine Mutter verarbeitet Zeichenfolgen besser als deine kompilierte Sprache". Die Bedeutung dieses Problems ist schwer zu überschätzen, und deshalb sollten Sie nicht diejenigen, die Python entdeckt haben, für übermäßige Begeisterung verantwortlich machen und versuchen, es anderen in jeder Hinsicht aufzuzwingen.

        Ironischerweise war es Python, das Perl die Chance gab, sich zu entwickeln. Zusätzlich zu Django verfügte Python nicht über Full-Stack-Frameworks, und Django war so gut darin, Nachrichtenseiten zu erstellen, dass bald mehr Nachrichtenseiten von ihm geschrieben wurden, als es täglich bedeutende Nachrichten in der Welt gab. Und dann stellte sich heraus, dass nicht alle Websites mit Django neu und geschrieben sein sollten. Gesagt, getan. Es gibt einen Trend für Microframes wie Flask, Pyrmaid, Bottle.py (verzeihen Sie mir eine so freie Interpretation des Begriffs "Microframework"). Vielleicht lag der Grund auch darin, dass die Popularität von REST-Diensten zunahm und Python überhaupt nichts damit zu tun hatte, sondern Mikroframes in Umlauf kamen.

        In Perl erschienen zusätzlich zu Catalyst die Frameworks der zweiten Welle: Mojolicious, Dancer und Jifty. Im Hinblick auf den vollen Stack erreichten sie immer noch nicht den vollwertigen PHP-schüchternen Zend oder CodeIgniter, aber vor dem Hintergrund der Python-Mikro-Frameworks sahen sie recht anständig aus. Und vor allem war es ein Indikator dafür, dass die Gemeinde immer noch auf die Herausforderungen unserer Zeit reagiert.

        Gleichzeitig stürzte sich ein Teil der Community aktiv zwischen Perl, Ruby und Python hin und her und zog Features von dort weg. Und nicht nur Funktionen, sondern auch allgemeiner Stil und bewährte Methoden. Zu dieser Zeit war die Aufteilung der Perl-Community in zwei Gruppen besonders deutlich: diejenigen, die Perl aus diesem Sumpf herausholen wollen, und diejenigen, die es gewohnt sind, die beste Perl 5-Tradition zu schreiben (Perl 5.0 wurde im Oktober 1994 veröffentlicht). Und letzteres kann man nicht einmal vorwerfen - es gibt eine ganze Reihe von Systemadministratoren, für die Perl in der Form ideal war, in der es 1994 existierte. Ein solches Bündel wird häufig auf Konferenzen gesehen, auf denen nach einem Bericht darüber, wie jemand in Perl geschrieben hat, praktisch Ein Skript, das ihm neue SMS mit eBay per SMS schickt, gibt einen Bericht über die Probleme der komplexen Infrastruktur mit Corona, Nachrichtenwarteschlangen, eigenem CPAN-Repository und anderen beängstigenden Dingen.

        Insgesamt verbessert sich jedoch die Situation, und Perl hat bereits den Punkt überwunden, an dem ein endgültiger Zusammenbruch der Stagnation möglich war. Die Community erkennt immer noch ihre Probleme und die Möglichkeiten, sie zu lösen, sind sichtbar. Natürlich gibt es nicht genügend Ressourcen - in einem Bericht des letzten Jahres über einen der YAPCs gab es Informationen, nach denen buchstäblich ein paar Leute den gesamten C-Code-Interpreter verstanden haben, und weitere 15 konnten ihre Subsysteme verstehen. Es ist nicht notwendig, diese Zahlen zu dramatisieren - sie tun es fast kostenlos, aber wie viele Menschen möchten sich mit dem alten C-Code und insbesondere mit dem Gedächtnis des Interpreten einer ganzen gesunden Sprache befassen, wenn eine der Hauptanforderungen darin besteht, die Kompatibilität nicht zu brechen?

        Natürlich wird Perl keine so gute IDE wie PHP oder Python haben, da es einerseits nicht so viel kommerzielle Unterstützung gibt und es keine einfache Syntax gibt, mit der Sie leicht Perl-Parser erstellen können, die in jeder etwas ernsthaften IDE erforderlich sind. Und selbst wenn, werden sie noch lange aufholen müssen - IDEA und Microsoft sind Monopolisten auf dem IDE-Markt. Sie haben einen solchen Standard für die Qualität der Sprachunterstützung festgelegt, dass selbst Eclipse, das eine riesige Community hat, an Boden verliert. Aufgrund der Tatsache, dass Perl keine rein weborientierte Sprache ist, ist die Konzentration des Aufwands auf Webframeworks, die im Fall von PHP auftritt, einfach unmöglich. Aber angesichts der Tatsache, dass das dicke Frontend überall an Popularität gewinnt, ist dies nicht so beängstigend.

        Perl6 kann der Sprache einen zweiten Wind geben und einen Streich spielen, wie der dritte Python-Zweig, der lange Zeit von der Community ignoriert wurde, da viele Autoren nicht bereit waren, Python-Bibliotheken für die neue Version umzuschreiben. Auf der anderen Seite löst Perl6 das wichtige Problem des fünften Zweigs - schließlich gibt es eine Sprachspezifikation, nach der jeder einen Compiler schreiben kann, der zum einen das Leben der IDE-Entwickler vereinfacht und zum anderen das Ausführen von Perl6-Programmen auf mehreren heutigen Backends ermöglicht einschließlich JVM.

        Jetzt sind die Aussichten für Perl stabil positiv. Vergessen Sie nicht, dass vor Perl sowohl Python als auch Ruby Ups erlebten, was dazu führte, dass der Lärm nachließ und die Sprachen die Nische besetzten, in der sie wirklich anwendbar waren. Es bleibt abzuwarten, bis mit Javascript dasselbe passiert ...

    Mythologie


        Perl wird von Außenstehenden lange Zeit nicht in Bezug auf die aktuelle Situation gesehen, sondern in Bezug auf Mythen darüber, die ins Netz gehen. Typischerweise beeinflussen diese Mythen die Unlesbarkeit des Codes, die Bedeutung regulärer Ausdrücke, die Veralterung der Sprache CPAN, Perl6, die offensichtlich der Nullreiter der Apokalypse sein wird. Und das Wichtigste ist natürlich, dass die Sprache tot ist.

    Die Unlesbarkeit seiner Majestät


        Laut Aussage derjenigen, die sich über die Unlesbarkeit von Perl beschwert haben, gibt es mehrere Hauptprobleme:

    • Missverständnis, warum, es sei denn, dies wird benötigt, wenn eine umgekehrte Bedingung vorliegt.

    • Missverständnis von regulären Ausdrücken. Leider werden diejenigen, die zu faul sind, um herauszufinden, wie reguläre Ausdrücke funktionieren, mit ihnen in keiner Sprache zufrieden sein.

    • Doppelte Siegel der Form $, @,% in Konstrukten der Form% {$ self -> {'posts'}} oder @ $ posts, in denen Beschwerdeführer nicht nur einfache Typumwandlungen sehen.

    • Hier ist dieser Code: echo "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|\`{;;y;-/:-@\-`{-};\`-{/" -;;s;;$_;see'Aber warum sollte man sich über verschleierten Code beschweren, wenn andere Sprachen die Verschleierung von Code zu einer nützlichen, wenn nicht sogar obligatorischen Technologie machen?

    • Fehlende Dokumentation im Code. Tatsache ist, dass es häufig nicht üblich ist, Funktionsdokumentation im Javadoc-Stil zu schreiben - vor jeder Funktion. Infolgedessen wird das gesamte schön gestaltete Fußtuch, das das Modul dokumentiert, entweder am Anfang oder am Ende des Moduls herausgenommen. Perl gibt solche Freiheit. Einige Programmierer fühlen sich so frei, dass sie überhaupt keine Dokumentation schreiben.

    • Eine Reihe von speziellen Anführungszeichen und impliziten Variablen. Es gibt eine feine Sache: Anstelle einer Tabelle mit Variablenwerten sollten Sie eine Tabelle mit Variablennamen erstellen, damit alles zusammenpasst.


        Trotz der ungewöhnlichen Syntax in Bezug auf viele andere Sprachen scheint mir der Hauptgrund für die Ablehnung in den dunklen Zeiten, als Perl populär war, verborgen zu sein, aber die Regeln guter Form beim Schreiben von Code waren nicht populär. In jenen Tagen gab es viele Sprachen, in denen Code erstellt wurde, der schwer zu lesen war. Aber auf Perl wurde dieser Code mehr erstellt. Betrachten Sie diesen Absatz, es ist nicht "schlechter Code kann in jeder Sprache geschrieben werden." Stellen Sie sich die Frage, ob die Branche den Bedarf an guten Web-Programmierern in den 1990er oder frühen 2000er Jahren befriedigen konnte. Oder haben dann im Web (und als Folge davon in Perl) alle nach Geld gesucht, als sie jetzt in die mobile Entwicklung, den Garbage AppStore und den PlayMarket einsteigen?

        Mit Ruby können Sie auf der Grundlage Ihrer eigenen Daten eine neue Sprache (DSL) erstellen, die funktioniert. Perl hat diesbezüglich einen etwas anderen Pfad gewählt - während Sie in einer beliebigen Sprache schreiben, geht der Interpreter davon aus, dass Sie in Perl schreiben. Einerseits müssen Sie Ihr DSL nicht wie im Fall von Ruby beschreiben, andererseits kann der Interpreter in Ihrem Code sinnvoller sein als andere Programmierer, die diesen Code in Zukunft unterstützen sollen. Um dem entgegenzuwirken, gibt es Codestandards, die die Kreativität von Perl-Autoren in jeder Hinsicht unterdrücken sollen. Und egal wie schwierig es für mich ist, es zuzugeben, aber sie arbeiten, obwohl sie meistens in kommerziellen Unternehmen arbeiten. Dies ist überraschend, aber der Code eines durchschnittlichen Perl-Projekts auf einem Github sieht schlechter aus als der Code eines kommerziellen Projekts mit geschlossenem Quellcode.

        Wie stark die Abwärtskompatibilität in der Sprache ist, lässt vermuten, dass der im Jahr 2004 geschriebene Code 2024 nicht mehr so ​​funktioniert und veröffentlicht wird. Zur Freude der Archäologen und Perlenhasser.

    OOP


        Perl hat 3 OOP-bezogene Probleme:

    • Mangel an Standard-OOP-Syntax, wie es für viele üblich ist

    • Unverständnis darüber, welches Modul ausgewählt werden muss, um die OOP-Syntax zu unterstützen, die vielen gemeinsam ist

    • das Fehlen eines allgemein akzeptierten Trainingshandbuchs (wie im Fall von Javascript) mit einem Algorithmus, der den Gegnern erklärt, warum die ersten beiden Probleme überhaupt keine Probleme sind


        Aber dieses Jahr wurden endlich einige Fortschritte erzielt - die Community war sich einig, dass ein einheitliches OOP-System in Standardsprache bereitgestellt werden muss, das nicht erstens Anfänger in Erstaunen versetzt und zweitens mit allen vorhandenen OOP-Implementierungen kompatibel ist. Lesen Sie hier mehr .

        In gewisser Hinsicht ähnelt die Situation Javascript - nur in diesem Fall modellieren wir Krücken für den Funktionsprototyp, um das Objekt darzustellen. Und im Fall von Perl formen wir den Konstruktor für das Paket (oder Modul, wenn Sie es vorziehen) und wandeln ihn in eine Klasse um. Es gibt nur ein letztes - Unterstützer des traditionellen OOP beobachten keine Standardverkapselung und keinen Polymorphismus, aber wir beobachten eine Erschütterung und einen Phallomorphismus der Unterstützer. Aber es ist für niemanden einfacher. Perl hat im Gegensatz zu Javascript nicht die Forderung, kleinere Mängel zu verzeihen. Aber wir vergeben - in fast allen größeren Projekten, auf die ich gestoßen bin, wird das standardmäßige paketbasierte OOP für Perl verwendet und nicht eine der Bibliotheken.

        Im Allgemeinen ist OOP in Perl Standard - und aus diesem Grund sehen viele Interpreter-Betreuer nicht den Sinn, eine Implementierung mit der üblichen Syntax durchzuführen. Damit Sie sich den Unterschied zu Javascript vorstellen können, überschreiben wir die unglückliche Funktion nicht mit anderen Funktionen, um die Klasse sichtbar zu machen. Wir patchen keinen Funktionsprototyp mit einer anderen Funktion, um die Vererbung zu erhalten. In Perl erstellen wir ein Paket (Modul) und haben dann die Möglichkeit, Funktionen wie aus einem Modul zu importieren oder dem Modul einen Konstruktor hinzuzufügen und als Klasse zu verwenden. Wenn wir eine Vererbung benötigen, gibt es dafür integrierte Sprachtools, die speziell dafür entwickelt wurden. Auf der anderen Seite ist die Deklaration von Klassen in Perl die ausführlichste aller Sprachen, auf der dritten Seite wird es immer schwieriger, 2014 einen Editor ohne Snippets zu finden.

        Apropos Objekte - Perl ist eine der wenigen verbliebenen allgemeinen Skriptsprachen, in denen einfache Datentypen wie Zeichenfolgen, Zahlen, Arrays und Hashes nicht erstellt werden (wenn Sie glauben, dass PHP auch eine universelle Sprache ist, dann nicht eine, aber Gott sei Ihr Richter) als Standardobjekte, aber als eingebaute Typen. Und das ist einerseits angenehm für diejenigen, die Einfachheit lieben, andererseits erschwert es Kettenaufrufe von Funktionen.

    CPAN


        Einst der wichtigste Vorteil von Perl, und jetzt ist es nur ein notwendiges Attribut, nicht schlechter als andere Sprachen zu sein. Das Attribut ist jedoch nicht das schlechteste. Im Vergleich zu Python, Ruby, Javascript gibt es weniger ... Hipster. Ja, ja, die gleichen Leute, die so sehr darauf bedacht sind, sich auf dem Github zu verherrlichen. Und dann festigen Sie ihren Ruhm in den Paket-Repositories der von Ihnen gewählten Sprache. Es gibt viel weniger solcher in CPAN, denn wozu dient PR und das Eintippen in den Lebenslauf für eine unpopuläre Sprache. Vielleicht irre ich mich, aber glaubst du wirklich, dass alle 110.000 Pakete in npm sind?für eine weborientierte Sprache sind nützlich und Qualität? Auch wenn wir davon ausgehen, dass es sich aufgrund des Javascript-Knotens nicht nur um das Web handelt und alle diese Module wirklich nützliche Dinge oder schlimmstenfalls Bindungen an vorhandene Bibliotheken sind, ist dies nur ein Minenfeld. Es ist physisch unmöglich, in so kurzer Zeit eine so große Menge an Code von verschiedenen Personen zu lecken.

        Spezifische Statistiken zur Anzahl der Module für verschiedene Sprachen finden Sie unter http://www.modulecounts.com/ . Und da Perl unter anderen Sprachen ganz unten steht, werde ich als interessierte Person versuchen, diesbezüglich tröstliche Erklärungen zu finden. Erstens, wenn Sie sich CPAN selbst ansehenDann gibt es immer noch mehr als 140.000 Module, aber Distributions-Kits (eine Sammlung von Modulen, die oft, aber nicht immer, voneinander abhängen) sind wirklich ungefähr 30.000. in Bezug auf die Anzahl der Module ist CPAN weiterhin führend. Module im Sinne von Codeeinheiten, die einzeln angeschlossen und verwendet werden können. Zum Beispiel gibt es 2 Module LWP und LWP :: Simple - beide sind in der libwww-perl-Distribution enthalten. Darüber hinaus kann jedes Modul für sich verwendet werden und bietet eine andere Schnittstelle für die Arbeit damit. Die Module können zwar gemeinsame Abhängigkeiten haben oder voneinander abhängen. Angenommen, es sind Module außerhalb von Distributionen, die als schlechte Idee angesehen werden (obwohl ich nur vermuten kann, wie ich in Repositorys anderer Sprachen zählen kann und ich den Verdacht habe, dass dort sogar Gabeln gezählt werden können), und andere Sprachen berücksichtigen.

        Wir haben Javascript herausgefunden. Bei Go kann es mehrere Versionen eines Pakets geben, gemessen am Index, sowie * -dev-Versionen. In Python ist es häufig üblich, nicht nur Bibliotheken als Paket, sondern auch viele Anwendungen und Skripte zu entwerfen. Ja, das ist in allen Repositories der Fall, aber in Python finde ich das öfter. Trotzdem denke ich, dass die Zahlen für Python der Realität sehr nahe kommen, besonders wenn man bedenkt, dass Python eine Allzwecksprache ist und auch einen guten Ruf genießt. Obwohl der Moment nicht verstanden ist, wie Pakete für die 2. und 3. Version berücksichtigt werden. Was Ruby betrifft, so ist bereits alles umrissen . Auf dieser Website wird auch nicht die Anzahl der Änderungen und Aktualisierungen vorhandener Pakete angezeigt. Auch ohne Rücksicht auf die Situation anderer Sprachen, bei CPAN- Updatesviele, oft mehr als hundert pro Tag. Für 5. - 194 Dezember aktualisierte Module pro Tag. Tote Sprachen verhalten sich nicht so.

        Im Allgemeinen ist CPAN immer noch gut. Es ist so gut, dass es das einzige Repository ist, in dem Pakete installiert werden, von denen ich nicht nervös werde, weil ich denke, dass dabei etwas kaputt geht.

    Jobs


        Obwohl allgemein anerkannt ist, dass alle Perl-Programmierer untätig sind, wird daran gearbeitet. Es gibt jedoch zwei „Aber“: Erstens brauchen nur wenige Leute Junior-Perlgraupen, und zweitens müssen die meisten Arbeiten an Perl im Büro ausgeführt werden. Das heißt Bei freiberuflichen Projekten gibt es nur wenige und in der Regel (insbesondere bei RuNet) handelt es sich um einen Niedriglohn-Eimer. Ja, das stimmt, mit dem Wort "Niedriglohn" meine ich seltene Akkordprojekte im Wert von 10 bis 200 Dollar. Mit dem Wort "Bucket" meine ich, dass Sie hauptsächlich mit Personen zusammenarbeiten müssen, die entweder den Parser für die Websites einer anderen Person verwenden möchten, während der Parser in der Regel intelligenter als der Kunde ist, oder Sie Änderungen am benutzerdefinierten CMS (oder Webshop) vornehmen ), das seit Jahren und Jahrzehnten Verstecken spielt. Und glauben Sie mir, es wäre besser, wenn sie die Gewinnerin in diesem Spiel und mit Ihnen wäre.

        Es gibt einige Unternehmen, die bereit sind, Ihnen Perlocode per Fernzugriff zu zahlen. Zumindest ist es oDesk und Buzzfeed. Aber im Allgemeinen sind es nur wenige. Und die Stundensätze dort sind nicht die höchsten - meistens 15-20 USD / Stunde. Projekte über 30 US-Dollar pro Stunde sind schwer zu finden. Sie werden gezwungen, sie ins Büro zu ziehen oder Ihre Dienste abzulehnen. Zur gleichen Zeit ist es real, sich für 50 USD / Stunde auf demselben oDesk zu verkaufen, aber es wird eine episodische Arbeit sein. Sehr episodisch. Wahrscheinlich gilt dieser Absatz für fast jede Sprache ... Es ist nicht so schwierig, einen Remote-Job mit einer Zahlung von bis zu 2500 US-Dollar zu finden. Wenn Sie mehr wollen, treten Schwierigkeiten auf. In der GUS konnte ich mit einer Zahlung von mehr als 1.500 US-Dollar keine Fernarbeit bekommen, vielleicht klappt es mit Ihnen.

        Aber nicht alles ist so traurig, wenn Sie Ihren Arsch von Ihrem Lieblingsstuhl abreißen, um ihn gegen einen Bürostuhl auszutauschen. Offline-Arbeiten mit Perl sind im In- und Ausland möglich. Übrigens, viele von ihr sind im Ausland, aber hoffen Sie nicht, dass Sie ins Zahnfleisch geküsst werden und ein H1-B-Visum beantragen. Obwohl solche Arbeitgeber gefunden werden. Überzeugen Sie sich selbst. Es wird interessant sein, wenn einer der Leser in den Kommentaren mitteilt, ob mit ausländischen Unternehmen und Perl gleichzeitig alles gut geklappt hat.

        Wenn Sie der verrottende Westen ärgert, können wir auch mit Gerste arbeiten. Manchmal sogar in den Regionen. Erinnern Sie sich an das CMS, das Verstecken spielt? So können Sie nicht nur herausfinden, wann sie sich versteckt hat, sondern auch, wo sich ihr Versteck befindet, und vielleicht sogar ein Wort mit ihrem reuigen Schöpfer verbreiten. Und natürlich gibt es in den Regionen Karosseriewerkstätten, in denen manchmal Gerste benötigt wird.

        In den Hauptstädten ist unser ewiges Alles - mail.ru, yandex, reg.ru. Unsere Hoffnung und Unterstützung, eine lebende Erinnerung daran, dass Perl immer noch gebraucht wird. Wenn Sie jemanden auf YAPC oder Perl Workshop sehen und er Russisch spricht, dann arbeitet dieser Sprecher mit einer Wahrscheinlichkeit von 90% irgendwo in diesen drei. Von mir selbst empfehle ich reg.ru - ein angenehmes Interview, professionelle Programmierer, die wenige sind, und anstelle von blasphemischem Skype wird SIP verwendet.

        Natürlich ist Perl jetzt keine Gehaltsobergrenze, aber im Vergleich zu anderen Sprachen beginnen die Gehälter auf einem durchschnittlichen Niveau. Das heißt Sie können für 500 US-Dollar einen Junior-PHP-shnik oder ein RoR-Schaf bekommen (Moskauer, schweigen Sie!), und für Perl gibt es höchstwahrscheinlich keine solche Stelle, und andererseits sind die Anforderungen an Middle-Pearl niedriger als für die genannten Sprachen. Zusammenfassend gibt es auf Perl weniger Jobs als in vielen anderen Sprachen, aber dieser Job wird im Zusammenhang mit weniger Aufwand gesucht - Sie werden sofort normale Jobs haben. Und Wetten auf Perl mögen, aber das Hauptwerkzeug für Ferneinnahmen ist es wahrscheinlich nicht wert, zumindest auf den ersten Blick.

    Web-Entwicklung


        Heutzutage Websites in Perl zu schreiben, wenn auch nicht sündig, dann ist das mit Sicherheit absurd. So viele Leute denken. Und das ist zum Teil richtig: Selbst die ganze Schönheit von Perl kann die Vielzahl von Arbeitsstunden nicht kompensieren, die Sie in ein Webframework investieren müssen, um produktiv mit etwas arbeiten zu können. Und ich stelle fest, dass alle Sprachen marginaler sind als PHP, und zwar haben Ruby und Python nur ein solches Monster.

        Mojolicious, Dancer (?) Und Catalyst sind die drei Säulen, auf denen die moderne Perl-Webentwicklung beruht. Sogar in den dunklen Tiefen des Ozeans verstecken sich Monster wie Maypole und Mason, aber man kann ihnen selten begegnen. Und wenn man mit ihnen zusammenarbeitet, besteht die Gefahr, reich zu werden oder den Verstand zu verlieren. Und oft beides. Aber all dies unterscheidet sich ein wenig von dem, was Sie in anderen Sprachen gewohnt sind, die die Gunst des Gottes der Webprogrammierung erlangt haben.

        Perl bietet keine integrierten Lösungen auf einem Niveau wie Django, Symfony, RoR. Es gibt entweder Mikroframes, die grundsätzlich in allen Sprachen gleich sind, oder Catalyst, ein schweres Framework, das mehr oder weniger der Vorstellung entspricht, wie ein typisches Fullstack-MVC-Framework für das Web aussehen sollte. Sie selbst wählen jedoch die Methode zum Senden von E-Mails, ORM, Testframework usw. aus. Selbst wenn Sie im Fall von Catalyst das empfohlene ORM, die Vorlagen-Engine, haben, hängen Sie es am Ende höchstwahrscheinlich mit einer Reihe von Dingen aller Art auf, um etwas Eigenes zu erstellen. Es gibt keine zwei ähnlichen Projekte in verschiedenen Unternehmen, die über Catalyst geschrieben würden. Und Sie werden nicht die Menge an Edelsteinen oder Bündeln haben, die RoR und Symfony haben.

        Integration mit Client-Code, Arbeiten mit Assets - in der Perl-Welt unterliegen all dies auch keinen modischen Trends. Sie tun dies, wie Sie möchten - es gibt diejenigen, die Rechen mit den richtigen Edelsteinen in Mojolicious-Projekten verwenden. Eine andere Sache ist, dass, wenn Sie yui-compressor durch eine Make-Datei ziehen, dies in der Perl-Welt die Norm ist und im Falle eines RoR Sie es in Ihre Hände bekommen können.

        Dies alles gibt auf der einen Seite das Recht, über die Rückständigkeit von Perl zu sprechen. Andererseits bin ich mir nach dreijähriger Zusammenarbeit mit Symfony und seinen Procrustean-Guides nicht mehr sicher, welcher Ansatz zur Webentwicklung ein geringeres Übel ist. Ein guter Rahmen wird früher oder später über Ihre Arbeit hinwegkommen. Er hat zwei Möglichkeiten, dies zu tun: zu unflexibel zu sein, als dass Sie versuchen könnten, hinein zu passen, oder flexibel genug zu sein, um von der schwachen Kohärenz und dem Verschmieren von Algorithmen durch Code zu heulen.

        Für diejenigen, die an PHP-Frameworks gewöhnt sind, besteht das Hauptproblem der Perl-Webentwicklung darin, dass Sie das Archiv nicht mit dem Framework herunterladen, entpacken und Ihren Code in den Ordner src kopieren können. Sie müssen festlegen, wie Sie mit der Datenbank arbeiten möchten - über ORM oder Abfragen, wie Formulare generiert werden sollen -, entweder per Hand oder mithilfe von FormFu. Auf diese Weise wird festgelegt, wie Ihre Webanwendung aussehen soll. Es ist nicht so beängstigend, die Projekte anderer Leute auf demselben Catalyst oder Mojolicious zu verstehen, ist nicht schwierig, unabhängig davon, welche Module dorthin verschoben werden. Für Programmierer in anderen Sprachen ist dieser Ansatz jedoch ungewöhnlich.

        Heutzutage ist die meiste Webentwicklung ein Konstruktor. Um die Registrierung über soziale Netzwerke (vorzugsweise über alle auf einmal) zu beschleunigen, fügen Sie Schaltflächen mit ähnlichen Merkmalen derselben sozialen Netzwerke hinzu. Netzwerke, Anbindung an Zahlungssysteme, Hinzufügen von Web-Chat usw. Natürlich ist hier nicht einmal die Sprache von Bedeutung, sondern die Verfügbarkeit von vorgefertigten SDKs, Modulen und Rezepten. Perl verliert hier definitiv und es ist nicht immer ratsam, viele Arten von Sites darauf zu erstellen. Noch einmal, wie würden Sie sich fühlen - Perl steht hinter PHP genauso wie das Framework hinter CMS. Das Framework kann sicherer, schneller und für die Programmierung angenehmer sein, aber ein Teil der Arbeit wurde bereits in CMS implementiert. Dies spart Arbeitszeit. Wenn das Projekt jedoch zumindest eine komplizierte Logik enthält und Sie nicht vorhaben, auf jeden Leistungsaufruf mit horizontaler Skalierung zu reagieren, zeigt sich Perl immer noch gut.

        Es stimmt, es ist möglich, dass Sie mit Perl in großen Mengen Geld verdienen - in RuNet gibt es viele Handwerker, die ihre eigenen Frameworks (normalerweise FatFree-Level) haben und bereit sind, typische Sites auf diesen in Stapeln zu veröffentlichen und diese automatisch auf dem am häufigsten gehosteten Shared Hosting bereitzustellen, das sich selbst befindet Es unterstützt sich nicht immer selbst, nicht wie die darauf befindliche Site.

    Perl 6


        Der Schöpfer der Sprache Larry Wall liebt es, Menschen mit der bevorstehenden Veröffentlichung der sechsten Version der Sprache zu begeistern. Fast jedes Jahr. Und es begann um das Jahr 2000. Perl6 wird zu Weihnachten veröffentlicht, sagte er gerne, aber nach Weihnachten verweist er auf die Tatsache, dass ihm kein bestimmtes Jahr gegeben wurde. Diesmal übertraf er sich jedoch selbst und wagte es, mehr als sonst zu sagen . Vielleicht wird im neuen Jahr alles neu sein.

        Und angesichts des GradesBerichterstattung über Sprachspezifikationen mit Implementierung, vielleicht werden wir 2015 wirklich Perl6 sehen. Dies wird auch durch die Tatsache gestützt, dass Perl6 neben Parrot lange Zeit keine anderen Backends mehr unterstützte und in den letzten Jahren C # - und JVM-Backends erschienen sind. Außerdem erschien ein auf MoarVM basierendes Backend, das die Mängel der virtuellen Parrot-Maschine zu berücksichtigen scheint. Und mit hoher Wahrscheinlichkeit wird das MoarVM-Backend zum Standard für Perl6.

        Perl6 ist nicht kompatibel mit Perl5. Die Syntax ist sehr ähnlich, Ideen auch, aber es ist eine andere Sprache. Und selbst wenn es nächstes Jahr in Produktion gehen wird und auch wenn es möglich ist, die fünfte Version der Leistungsstufe zu erreichen, wird die Verschmutzung mit Modulen langwierig sein. Es besteht jedoch die Hoffnung, dass Perl5-Module von Perl6 verwendet werden können. Vielmehr können Sie es jetzt tun:https://github.com/niner/Inline-Perl5/ . Diese Technologie wurde jedoch nicht in großen Stückzahlen getestet, sodass es schwierig ist, über ihre Anwendbarkeit unter realen Bedingungen zu sprechen.

        Aus der Sicht des Massen-Perl6-Programmierers ist die Wahrheit besser als die der Vorgängerversion - Sie müssen%, @ nicht formen, bevor verschiedene Variablentypen angezeigt werden, die übliche OOP wird angezeigt, und schließlich werden die Methodenaufrufe für einfache Typen verfügbar. Für den gleichen Massenprogrammierer wird sich im Falle der Veröffentlichung von Perl6 zwar wenig ändern - der fünfte Zweig wird nirgendwo hingehen, wie der Code darauf.

    Gemeinschaft


        Perl hat eine große Community. Eine zu große Community, unverzeihlich groß für eine tote Sprache. Darüber hinaus haben einige große Bibliotheken ihre eigenen Selbsthilfegruppen, ganz zu schweigen von Frameworks. In der Regel kann die Hilfe über die Mailinglisten oder auf dem IRC-Server irc.Perl.org abgerufen werden. Dies hebt natürlich nicht die Verfügbarkeit von Perl-Kanälen auf Freenode auf. Ja, in unserer Zeit sehen IRC- und Mailinglisten ziemlich veraltet aus, aber nein, dies sind großartige Möglichkeiten, um Massen von Menschen zu organisieren. Dank Mailinglisten ist es einfach, Lösungen für Probleme zu finden, die vor 10 Jahren gelöst wurden, und dank IRC können Sie mit Leuten chatten, die vor 20 Jahren über Perl geschrieben haben. Stellen Sie sich nur vor, dass der Löwenanteil der aktiven Mitglieder der Open Source-Communities immer noch im IRC sitzt.

        Es gibt so viele Leute in der Perl-Community, dass man sich fragt, wo sie alle beschäftigt sind, wenn es bei Perl keine Arbeit gibt. Wir schreiben dies unter dem Vorbehalt, dass Perl eine so gute Sprache ist, dass viele Leute es für die Seele schreiben. Oder aus Hoffnungslosigkeit - angesichts seiner Präsenz in vielen Legacy-Programmen und Komponenten von UNIX-Systemen. Es gibt eine spezielle Schicht von Leuten, die eher zur Perl-Kultur neigen als zur Programmierung in der Sprache selbst. Ja, wir haben auch Fanboys. Aber die Sprache wird sie nicht als Jungen bezeichnen.

        Perl-Programmierer zu finden ist übrigens ganz einfach. Es ist nicht so einfach, gute Perl-Programmierer (wie auch jede andere Sprache) zu finden. Gute Perl-Programmierer auf irc.perl.org zu finden und Hilfe von ihnen zu bekommen ist einfach. Wir haben immer noch (zumindest in den GUS-Staaten) einen großen Prozentsatz von Leuten, die vor 10 Jahren mit Perl angefangen haben und es bis jetzt noch verwenden, und sie schreiben immer noch so, wie es vor 10 Jahren war. In der Regel sitzen sie freiberuflich und schreiben die Grabber und Parser oder Sites mit dem guten alten CGI. Und diese Leute können auch Ratschläge geben, und diese Tipps werden funktionieren! Was können Sie tun, wenn die Sprache stabil ist? Und der Rat von Runet-Gerste (zum Beispiel meiner) sollte sehr skeptisch behandelt werden - ein solcher Rat kann, wenn er rechtzeitig angewendet wird, nicht nur zur Lösung des Problems beitragen,

        Es gibt auch perlmonks.org . Wenn der Stackoverflow aus irgendeinem Grund von Roskomnadzor blockiert wird, können Sie dort nach der Antwort auf Ihre Frage suchen. Nein, dies ist keine schlechte Seite, es ist nur so, dass es normalerweise wenig Informationen über die Webentwicklung gibt.

        Die Perl-Community ist in mancher Hinsicht attraktiv, obwohl es noch wenige Neulinge gibt, aber es gibt viele gute Leute. Das System der Tagungen und Konferenzen ist gut etabliert, viele von ihnen finden auf der ganzen Welt statt. Viele Redner haben einen guten Sinn für Humor, normalerweise freundlich und inoffiziell (und der Humor im Büro ist entmannt und bedingt ungeplant), so dass man während einer Rede nicht aufstehen und hinausgehen oder den Player ausschalten möchte. Ein anderer, wenn auch technisch uninteressanter Bericht passt gut zu einem Teller Pasta an einem Samstagabend. Die Community hat nur wenige leere Argumente und Aggressionen gegenüber Communities anderer Sprachen. Aufgrund der Tatsache, dass es nicht genug gute Gerste gibt, werden Sie bald feststellen, dass bei allen Konferenzen in der GUS dieselben Gesichter ständig aufblitzen, zum Beispiel wurde im August sogar Larry Wall selbst in der Ukraine bemerkt.

    Soll ich Perl lernen?


        Wenn Sie bereits eine Sprache kennen, in der Sie Skripts schreiben können, um Daten zu verarbeiten, Testdatenbanken zu erstellen, Daten zu analysieren und zu konvertieren, benötigen Sie Perl nicht. Obwohl, um ehrlich zu sein, einige Module für grundlegende Dinge in Perl, wie die Arbeit mit Mail und FTP, immer noch stabiler sind als in derselben Python-Version.

        Wenn Sie viele Skripte in sh schreiben, sollten Sie versuchen, sich dazu zu zwingen, die üblichen Dinge in Perl zu tun. Tatsache ist, dass Sie bei einzeiligem Perl mehr Funktionen in ein Skript einfügen können, das Sie weiterhin direkt in der Konsole bearbeiten können, anstatt eine Datei dafür zu erstellen.

        Wenn Sie schnell und einfach Geld haben möchten, brauchen Sie Perl nicht. Obwohl es in Moskau Menschen geben kann, die den Nachwuchs ernähren werden. Wenn Sie bereit sind, ein paar Jahre zu verbringen und viel Geld wollen, dann ist es einen Versuch wert. Die Menge an altem Code in Perl ist enorm, insbesondere im Westen.

        Wenn Sie sich professionell mit Web-Scraping beschäftigen möchten, müssen Sie alles außer Javascript und Phantombildern außer Acht lassen. In der Werft im Jahr 2014 und das Herunterladen mit anschließender Analyse von HTML gibt nicht das gewünschte Ergebnis. Oder verwenden Sie Perl-Bindungen für Phantome.

        Wenn Sie gerade erst anfangen, Programmieren zu lernen, empfehle ich Ihnen, sich mit Perl als einer Sprache vertraut zu machen, die mehrere Paradigmen kombiniert. Auch wenn Sie sich von der Syntax von Perl selbst abwenden, empfehle ich Ihnen, Programming Perl zu lesen, auch in Russisch: Programming in Perl, 4. Ausgabe. Nur weil das Buch eine Reihe anderer Dinge berührt, wie die Unix-Philosophie, die Netzwerkprogrammierung, die gleichzeitige Programmierung und das Konzept der regulären Ausdrücke. Dieses Buch ist eine Einführung in alles, was Ihnen in Zukunft begegnen wird, auch in anderen Sprachen. Es ist im gleichen Stil wie dieser Artikel verfasst.

        Wenn Sie ein Programmierer in einer kompilierten Sprache sind oder mit Mikrocontrollern arbeiten, aber nicht im Internet surfen möchten, sollten Sie sich auf jeden Fall mit Perl befassen - selbst bei einem Mindestmaß an Kenntnissen verfügen Sie über ein leistungsstarkes Tool für die Codegenerierung und alle Arten von kleinen Assemblerskripten. If / switch-Fußbekleidung für Fahrer anhand von Tabellen aus Dokumentationen, Tabellen von Zustandsautomaten usw. generieren

        Wenn Sie sich ernsthaft mit Netzwerkprogrammierung beschäftigen möchten, kann Perl für Sie zumindest für das Prototyping, das Erstellen von Testdatenverkehr und für Stub-Server nützlich sein.

        Wenn Sie Code in Ihrem bevorzugten Texteditor schreiben möchten und IDE-Liebhaber Ihnen unangemessene Rückschritte vorwerfen, ist Perl eine sehr gute Wahl. Wenn Sie eine Sprache verwenden, für die es keine geeignete IDE gibt, haben Sie eine gute Entschuldigung, warum Sie sie nicht verwenden.

    Also warum Perl und nicht noch etwas?


        Jeder entscheidet für sich. Was ich persönlich an Perl mag, unter anderem:

    • Separate Operatoren zum Vergleichen und Verketten von Zeichenfolgen und Zahlen

    • Umfassende Interpretation von false: "", 0, undef, () sind ohne drakonische Vergleiche mit === sowohl in Javascript als auch in PHP in vernünftigem Maße austauschbar

    • Strenge Syntax: In realen Projekten ist sie sehr streng und Sie werden dort nicht die Schrecken finden, von denen allgemein angenommen wird, dass sie in jedem Perl-Programm auftreten.

    • Deklaration von Variablen, die den Gültigkeitsbereich sowie die Lokalisierung externer Variablen innerhalb des Blocks angeben.

    • Vorgehensweise zum Dokumentieren von CPAN-Modulen - Um ein Modul zu verwenden, lesen Sie in der Regel den Abschnitt "Übersicht".

    • Komfortable Zuordnung im Listenkontext.

    • Arbeiten mit Unicode - manchmal scheint es mir, dass Perl-Betreuer es in erster Linie lecken und alles andere auf Restbasis tun.

    • Die implizite Variable $ _, wie diese aus Javascript, ist nur praktischer. Da $ _ im Gegensatz dazu , können Sie nicht verwenden.

    • Eine ideale Auswahl an Funktionen, die nicht importiert werden müssen, Dateiverwaltung, Stammdaten, Datum, Zufall, Verzeichnisüberquerung, Ruhezustand, Druck ...

    • Die Einfachheit der Sprache - Sie können auf eine kleine Teilmenge der Syntax schreiben.

    • Sie können in einem PHP-ähnlichen Stil schreiben, und der Code entspricht den allgemein akzeptierten Vorstellungen von heute, wie der Code aussehen sollte.

    • Einzelne Zeile in der Befehlszeile. Ja, fast alle Dolmetscher anderer Sprachen haben diese Möglichkeit, aber hier ist alles durchdacht und bequem.

    • POD, es sieht wunderschön aus, es sieht aus wie Dokumentation. Und nicht als Javadoc-Annotation.

    • Es ist praktisch, darauf Dienstskripte zu schreiben, die früher oder später für eine große Webanwendung erforderlich sind.

    • Das Fehlen von Argumentsignaturen ermöglicht es uns, nicht alle Aufrufe des Unterprogramms umzugestalten, sondern lediglich zu überprüfen, ob das Argument im Unterprogramm übergeben wurde.

    • Perl ist auf fast jedem Unix von jedem Hoster verfügbar. Ja, Python auch, aber es kann einen Zwei geben, einen Dreifachen, und es ist unklar, welche Bibliotheken.

    • Konferenzen, viele Konferenzen. Eine Geschichte ist überraschender als eine andere.

    • Wir haben eine Monatszeitschrift auf Russisch Perl gewidmet

    • Legacy auf Perl ist interessant, es gibt etwas zu sehen, insbesondere was die Skalierung der Vor-Cloud-Ära betrifft.

    • Die Stabilität der Sprache ist nur mit C und Java vergleichbar.

    • Eine einfache Bereitstellung durch Kopieren von Code über den Explorer. Komplexe Bereitstellung über das CPAN-Repository. Neuanfangsbereitstellung durch Karton. Senile Bereitstellung durch das Makefile. Und alles ist von der Community akzeptabel.

    • Angenehme Interviews. Meist bieten sie Testaufgaben an oder führen allgemeine Gespräche. Keine wilde Botanik.

    • Unter den Kollegen gibt es nur wenige junge und begeisterte. Meistens machen die Leute nur ihre Arbeit.

    • Eine Kultur, die viele Wege predigt, um dasselbe zu tun, beseitigt viele Konflikte in einem Team.


        Und was am wichtigsten ist: Perl stört das Denken im Gegensatz zu vielen anderen Sprachen nicht. Es gibt kein Konzept von richtig und falsch, Sie können sich auf die Lösung des Problems konzentrieren und nicht auf alles, was mit der hohen Ruhe übereinstimmt. Natürlich gibt es einige Normen, Kodierungsstandards - aber dies ist nicht diese Ebene, dies ist die Ebene der regulierten Regeln. Hier müssen Sie nicht jemanden verfolgen, Sie müssen nicht auf die Meinungen von Superstars hören, Sie müssen nicht versuchen, sich an eine Norm zu halten. Sie müssen nicht die richtige Bibliothek verwenden, die jetzt in Mode ist. Sie können tun, was Sie möchten, und dies ist für viele gängige Sprachen ein inakzeptabler Luxus.

        Außerhalb der Arbeit haben Sie das Recht, Thrashy Govnokod aus den 90ern zu schreiben, und wenn Sie diesen Code als Lösung im Forum posten, werden sie sich nicht darüber lustig machen. Die Community hat keine billige Selbstbestätigung akzeptiert, aber jeder versteht, dass jeder ein unterschiedliches Niveau an Sprachkenntnissen hat. Sie suchen nicht nach dem perfekten Code, denn sie sehen jeden Tag nicht nur komplexe Systeme, sondern auch Skripte, die auf den Knien geschrieben sind. Dies ist eine Art Impfstoff gegen die Panikangst von Govnokod, die so von vielen Gemeinschaften anderer Sprachen durchdrungen ist.

    Abschließend


        Egal wie sehr die Katze die Nase nicht küsst, sie tanzt immer noch.


    Jetzt auch beliebt: