Как стать автором
Обновить

Комментарии 101

Видимо, самостоятельно выращивать новых специалистов оказалось дешевле и проще, чем портировать проекты на какой-нибудь более современный стек…
Это мэйл выращивает специалистов для букинга
Букинг вроде на Java переползает?
Не могу ни подвердить, ни опровергнуть это
Что «современный стек» умеет из того, чего не умеет Perl? И какой смысл портировать то что и так прекрасно работает — просто «чтобы было»?

К тому же, «современные стеки» имеют свойство устаревать очень быстро и часто несовместимы между своими мажорными версиями, и то что супер-пупер-круто сейчас, может стать несовременным уже через три-четыре года, а Perl как был так и будет есть ещё лет 30.

Разумеется, у Perl есть свои недостатки, но они есть у любого языка и любого фреймворка, но тот факт что Perl создан не один десяток лет назад не делает его устаревшим (к тому же он развивался всё это время), а наличие просто невероятного количества модулей и фреймворков действительно делает его вполне жизнеспособным и в наше время, и действительно для любых задач (кроме, разве что, чисто вычислительных, а также требующих нативной многопоточности).

Что «современный стек» умеет из того, чего не умеет Perl? И какой смысл портировать то что и так прекрасно работает — просто «чтобы было»?

Находить разработчиков под него
Хороший разработчик на C/C++/Java/C#/JS/PHP без труда обучится Perl максимум за месяц — и это будет явно быстрее и дешевле чем портировать всё на новый стек.
Хороший разработчик на перечисленных языках никогда не пойдёт на такую вакансию. Поэтому и надо переходить на актуальные инструменты.
А каким образом возраст языка определяет его актуальность?

PHP всего на 7 лет младше Perl, но ведь ещё актуален? И это несмотря на то что его ругают все кому не лень (причём за дело).

Си вообще почти древний (аж на 15 лет старше Perl) — и что, он уже неактуален?

Что касается «не пойдёт на вакансию» — это зависит от задачи и оплаты. Уверен, что если будет выбор между «CMS для порносайта» на C# за $50/час или «AI для робомобиля» на Perl за $75/час — то вряд ли многие выберут порносайты, даже если не знают Perl. Хотя, если это простые банальные кодеры — то да, выберут. А хорошие разработчики все же выберут второе.

Актуальные — те, которые востребованы и на которые имеются разработчики без необходимости переучиваться.

Количество вакансий под Perl видели? Теже Python и Go выглядят намного перспективней.
НЛО прилетело и опубликовало эту надпись здесь
Назову две — интересная задача и хорошая оплата. Интересность задачи с языком программирования редко коррелирует.

Хотя вообще-то хороший разработчик должен знать (т.е. уметь практически применять) несколько языков, и понимать намного больше (хотя бы со словарём), а также легко осваивать новые, иначе он просто узкоспециализированный кодер.

К несчастью, многие современные разработчики знают только один, любой другой (даже похожий) идёт с трудом, и шаг влево или вправо выбивает их из колеи. Печально.
НЛО прилетело и опубликовало эту надпись здесь
Насколько хорошая оплата?
Perl не «плохой» и не «устаревший» язык. Однако у него есть определенная философия: динамическая типизация, TIMTOWTDI, краткость за счет неявных эффектов. Он не только позволяет, но поощряет всевозможную магию, благодаря чему хорошо подходит для одного круга задач, но плохо для другого. Например, писать однострочники для обработки всяких данных — сплошное удовольствие. Однако понимать код на Perl, написанный кем-то другим, а уж тем более его рефакторить — дело сложное и опасное.

Я также не сомневаюсь, что на Perl написано много полезных модулей и, возможно, даже качественных приложений. Авторы обычно отвечают — «просто нужно писать аккуратно, не использовать всякий сомнительный функционал, и все получится». Однако это говорит лишь о силе воли и навыке разработчика, а не о пригодности технологии.

Java и C++ существуют уже не меньше лет, устаревать не собираются, и о кардинальных несовместимостях между версиями я также не слышал. Сообщества крупнее и активнее, сил и денег вкладывается на порядок больше, сотрудников искать легче, инструменты совершеннее. Разве это не достаточная мотивация?
Java и C++ существуют уже не меньше лет

С++ лет 7 существовал к моменту начала разработки perl
В статье упомянуто несколько новых проектов, сделанных на perl. Это только самые крупные и/или известные. На самом деле таких проектов больше. Есть и примеры, когда сишные демоны спиливались и заменялись на асинхронную перловку с близкой производительностью (но более дешевой стоимостью поддержки). Так что не легаси единым.
Тогда почему почту на go стали переводить?
Потому, что это был их выбор. Но говорить о правильности/целесообразности и прочих аспектах такого выбора я бы не стал. Для таких решений взвешивается очень много за/против. И язык, как инструмент, это один из факторов, и как правило он не является решающим.

А что вы скрываете за понятием "современный стек"? Вот конкретно? JavaScript/Python? Приложения на Electron нынче с успехом питаются гигабайтами RAM, простой скрипт на Python легко заставляет свою виртуальную машину съесть до 70МиБ "с порога", а рядовой Perl-процесс укладывается до 10МиБ, стартует быстрее, и это при том, что выразительность языка гораздо выше, чем у тех обоих вместе взятых.


Я вот прямо сейчас на коленке провёл эксперимент:


  • perl -E 'say "foo" while 1' — 508КиБ`
  • python2 -c 'while True: print("foo")' — 2.5МиБ
  • python3 -c 'while True: print("foo")' — 3.6МиБ
  • node -e 'while (1) {console.log("foo")}' — В секунду течёт где-то по 100МиБ, за несколько секунд дошло до 1ГиБ и я решил убить процесс, этого достаточно (node --version = 8.12.0)

И эти объёмы потребляемой RAM растут пропорционально. Основные его конкуренты (если я правильно интерпретировал ваш "современный стек") дают ощутимо менее выразительный синтаксис и при этом ощутимо расточительнее по отношению к ресурсам.


Итак, вопрос: зачем вообще портировать проекты на "современный стек"?

Подозреваю, что вы не прочитали остальной тред, прежде чем писать комментарий, поэтому резюмирую одной строкой: поддерживаемость важнее потребления ресурсов. Под поддерживаемостью подразумевается


  1. В языке должны быть гарантии надежности (строгая статическая типизация)
  2. IDE для языка должна предоставлять умные рефакторинг и автодополнение
  3. На рынке должно быть достаточно специалистов

Perl, к сожалению, не удовлетворяет ни одному из данных пунктов, поэтому его производительность и выразительность ничего не значат. JS и Python — только пункт 3 (пункт 2 под вопросом). Примеры языков, удовлетворяющих всем трем пунктам — Java, C# или Go.

Ну я и отвечал на конкретное верхнее сообщение, а не на ветку треда.


поддерживаемость важнее потребления ресурсов

Только если ты большая компания — у которой неограниченные железные ресурсы, на которые в любой момент всегда есть деньги. Для конечного пользователя такой подход заканчивается печально и уныло (см. Electron-приложения, и всякие веб-сайтики, которые едят как не в себя, да ещё обвешаны кучей счётчиков, рекламных сетей и прочими зондами).


Пт. 1 удовлетворяет Haskell лучше всех перечисленных вместе взятых.
Пт. 2: JS и Python могут удовлетворять в отдельных случаях только если код очень "тупой", если не используются никакие хелперы для генерации функций, исключений, а всё развёрнуто набито копипастой/руками.


С пт. 3 вообще интересная ситуация. Есть хорошие инструменты, но изучать которые и работать с которыми люди не берутся в свободное время, т.к. им непонятны перспективы с точки зрения последующего поиска работы, т.к. вакансий не предлагают. А вакансий не предлагают, т.к. сложно найти таких специалистов на рынке, а специалистов мало, потому что им не предлагают вакансий, мотивации недостаточно для выделения большего кол-ва времени/сил на обучение. Ну вы поняли рекурсию.

Только если ты большая компания — у которой неограниченные железные ресурсы, на которые в любой момент всегда есть деньги. Для конечного пользователя такой подход заканчивается печально и уныло (см. Electron-приложения, и всякие веб-сайтики, которые едят как не в себя, да ещё обвешаны кучей счётчиков, рекламных сетей и прочими зондами).

И пользователя выбирают эти сайты и приложение и рассказывают друг другу, какие они офигенные. Так что пользователям поддерживаемость тоже важнее.

Не знаю что это за пользователи, я давно поудалял все electron-приложения к чертям, как и все питоновые стараюсь также заменить теми, что на компилируемых языках. И слышу как куча людей жалуются на electron-приложения, slack к примеру и ещё ряд других, что-то восторженных отзывов пока не особо, кто-то молча терпит, кто-то негодует. Наши реальности видимо как-то в корне отличаются.
Полностью поддерживаю. Эти поделки терпят либо от незнания что можно лучше, либо по причине отсутствия альтернатив. Есть исключения в виде тех кто искренне считает что пользователи все железом должны заливать, но их не сказать что большинство.
Эти поделки терпят либо от незнания что можно лучше, либо по причине отсутствия альтернатив.

Вот именно. Альтернатив нет, потому что их не смогли написать, а то, что по вашим критериям лучше либо не пилит модные фичи, либо пилит их очень медленно.

Нет, просто на первое много вакансий, и труд людей, которые это делают — оплачивается, они мотивированны, а вторые если и делают, то как правило исключительно на тяге собственного энтузиазма, приходя домой с работы и находя для этого силы, волю и ментальные ресурсы.
Добавлю так же ещё и Ruby 2.5.3 для примера:
ruby -e 'while true; puts "foo" end' — 12.1МиБ

Если убрать Node.JS, — т.к. это вообще что-то невменяемое, и использовать это для скриптинга нельзя, если не хотите случайно запнуться об гигабайтную течь по памяти, то Ruby — пока чемпион по жиру.
Месяца два назад натыкался на предыдущий курс от этих же ребят. Несмотря на то, что лет 15 тому назад интересовался этим языком, забуксовал очень быстро. Все-таки знать язык и уметь его преподавать — очень разные вещи.
Отдельная проблема — настройка окружения (интерпретатор, ide, кодировки и пр.) надеюсь, в новом курсе уделили этому внимание. У меня, например, возникла странная проблема с кавычками, которая проявлялась только в винде, и только в консоли. Гуглил с полчаса — без толку. Как раз таким вещам стоит посвятить часик во вводной лекции, а не лить воду про историю и философию.
Попробую ответить по порядку.
Курс на Stepik, который анонсирован в этом посте, и «предыдущий курс» из Вашей ссылки действительно имеют общие корни. Изначально был создан живой курс для обучения студентов в рамках образовательных проектов mail.ru (Технопарк и другие). Фрагментарная видеозапись одного из первых выпусков этого материала и была выложена на youtube с достаточно прагматической целью: чтобы дать возможность студентам пересматривать лекционный материал в процессе работы над домашками. Видео достаточно сильно сокращено, там нет ответов на вопросы студентов и многих других вещей, и стартовать, имея только это видео, действительно может быть достаточно тяжело. Впрочем, «живой» курс не оставался неизменным и видоизменялся от семестра к семестру, учитывая успехи и неудачи предыдущих прогонов, так что есть надежда, что мы сумели с тех пор сделать его лучше. Из этого материала и родился курс для Stepik'а. В его названии есть слово «введение». Мы отобрали только те темы, которые действительно необходимы для знакомства с языком, и позволят изучить его синтаксис и начать писать на нем небольшие программы. Сложные разделы, требующие дополнительных знаний и опыта разработки, мы постарались в эту версию курса не включать. Получилось у нас сделать курс доступнее или нет — не знаю, время покажет. В том, что там найдется определенное количество косяков, которые придется исправлять — не сомневаюсь, но мы к этому готовы.
Исторический экскурс в новом видео предельно сокращен, на него отводится менее двух минут в стартовой лекции, и еще меньше приходится на философию. Второй видеофрагмент как раз касается работы под Windows: там предупреждение о том, что по мере закапывания вглубь проблем под виндами будет все больше и больше и в целом этот путь не рекомендуется. Кавычки не имеют прямого отношения к перлу, это связано с работой консоли, но об этом мы тоже предупреждаем. Чтобы облегчить старт и не собирать все эти грабли, можно, например, воспользоваться приготовленной для вас виртуалкой.
Можете ещё посмотреть вторую версию, с упором на системщину и асинк
Некоторые считают, что язык Perl мертв, поэтому одной из задач курса является развенчание этого мифа.

Вот отсюда поподробнее можно пожалуйста?

Учитывая современные модули и функциональность языка, сегодня Perl способен решать любые задачи.

Наконец появился язык, на котором все можно писать! А то вечно как ни начнешь модуль ядра писать, так приходится с петона на си прыгать. Теперь муки позади.
Ловите хабра-суицид по имя правды.

Прошу обратить внимание на интересный факт: я получил гору минусов в карму и в сам коммент, но развенчание мифа не последовало.
Это говорит многое о «религиозности» отношения к языку. Не о логичном выборе, который есть чем защищать. Можно подвергнуть сомнению Аллаха, а можно подвергнуть сомнению статус Перла — отношение адептов будет одинаковым.

Вывод: вместо опровержения мифа сами же его и подтвердили, продемонстрировал отсутствие конструктива.

Выведение обещать не могу, но в офисе мейла есть Служба Вынимания. Приходите, если сможем — поможем :)

Вы как будто про запой пишете! :))) Не такой уж Perl затягивающий!
Мне пришлось изучать Ruby, чтобы избавиться от Perl-зависимости :)
А почему не питон?
По религиозным соображениям: у меня всегда аккуратные отступы, гораздо аккуратнее самого кода, но я не могу представить язык, где отступы являются неотъемлемой частью синтаксиса — это аргумент против Python, а вот мой личный аргумент аргумент за Ruby: автор Ruby, как я понял, хотел создать язык «как Perl, но без его тяжёлого наследия»;
Ruby родился 23 февраля 1993 года. В тот день я беседовал со своим коллегой о возможности существования объектно-ориентированного сценарного языка. Я знал Perl (Perl4, а не Perl5), но он мне не нравился — был в нём некий привкус игрушечного языка (да и поныне есть). А объектно-ориентированный интерпретируемый язык казался многообещающим. В то время я знал Python. Но он мне не нравился потому, что я не считал его настоящим объектно-ориентированным языком. Его OO свойства казались надстройкой над языком. Мне, как языковому маньяку и фанату объектно-ориентированного программирования с пятнадцатилетним стажем, очень, очень хотелось, чтобы был истинно объектно-ориентированный, простой в использовании язык. Я пытался найти такой язык, но его не было.
— это цитата автора по Википедии, именно по ней много лет назад я понял, что хочу знать Ruby и забыть Perl
Вы не могли бы привести два примера: отступы в Питоне и более аккуратные отступы. Прямо заинтриговали.
  1. отступы в Питоне
    любой код на Python
  2. более аккуратные отступы
    ???
Курсы COBOL, PL/I и PERL от MAIL.RU

Запустите обозреватель интернета версии 5.5 и введите в адресной строке адрес myspace.com/mail.ru…
Сравнивать Perl и Cobol это примерно как сравнивать C# и Basic.

На С# никогда не писали банковский софт, а на Basic его навалом, только никто уже не знает, как он работает?

Да банковский софт сейчас только на джаве с дотнетом и пишут.
В контексте всяких дотнетов — вполне себе сравнимы. VB vs C#. Оба унылы и завязаны на MS по самое немогу.

Сравнил. В чём-то похожи.

А что у нас общего между perl и cobol? Ужасные языки программирования, на которых написаны куски старого кода, за сопровождение которого платят всё больше и больше умирающим от альцгеймера старикам. Да?

Насчёт «ужасного», цитирую:

Theorem: Parsing Perl 5 is Undecidable

We first establish Adam Kennedy's conjecture as a lemma. The proof will follow immediately from that and the Halting Theorem.

Kennedy's Lemma: If you can parse Perl, you can solve the Halting Problem.

To prove Kennedy's Lemma, we assume that we can parse Perl. In particular this means we can take the following devilish snippet of code, concocted by Randal Schwartz, and determine the correct parse for it:

    whatever  / 25 ; # / ; die "this dies!"; 


Schwartz's Snippet can parse two different ways: if whatever is nullary (that is, takes no arguments), the first statement is a division in void context, and the rest of the line is a comment. If whatever takes an argument, Schwartz's Snippet parses as a call to the whatever function with the result of a match operator, then a call to the die() function.


www.perlmonks.org/?node_id=663393
Ужасные языки — это brainfuck & co, а в остальных бывает только ужасный код, причём в любых. Ужасно могут выглядеть и Python и Go, в зависимости от уровня кодера (или его желания выпендриться), и куча кода на PHP (некоторые популярные плагины под WP, к примеру) просто за гранью добра.

Да, Perl позволяет создавать малочитаемый код, но это выбор разработчика, а не особенность языка. Если я пишу скрипт для себя из серии «написал и забыл» — это не проблема, а для проекта который уйдёт в свет и с которым будет работать команда можно писать чисто и понятно. Для этого, кстати, и нужно адекватное обучение.
Вы не поняли всей бездны этого примера. Вы не можете разобрать синтаксис перла в общем случае, не решив задачи остановки, а она нерешаемая.

Другими словами, сам язык допускает конструкции на уровне парсера (!), которые невозможно разобрать не разобрав, что делает программа.

На этом месте его можно закапывать, потому что такого даже ассемблер (без полиморфизма) себе не позволяет.
В приведенном примере задача остановки может быть притянута за уши только если речь идёт о статическом парсинге (без выполнения). Неудивительно, что статический парсинг невозможен — но его никто не делает (и не собирается), соответственно, пример «дьявольского кода» с сопуствующим текстом — это всего лишь мысленные упражнения.

Да, язык это позволяет (потому что это фича), но не навязывает — не вижу проблемы. Вы же не запрещаете производство кухонных ножей просто потому что ими можно кого-то убить или порезаться? Да и лицензий или курсов обучения для пользования бытовыми ножами я что-то не встречал — но вот удивительное дело, это не приводит к проблемам, кроме изолированных частных случаев.

Как я уже говорил раньше, никакой язык не обеспечит идеальности кода без желания разработчика (или его начальника) — на любом, даже самом идеальном и зарегулированном донельзя языке можно написать полную хрень, никем кроме автора не читаемую и непонимаемую (но вполне работоспособную), но это само по себе не делает язык плохим или хорошим.

Не надо ограничивать творчество на уровне языка — злые гении всё равно найдут выход, а добрые обидятся и не сделают чего-то великого в момент озарения.
Не надо ограничивать творчество на уровне языка
В энтерпрайзной разработке не должно быть никакого «творчества на уровне языка». Вместо этого должны быть разумные ограничения, которые максимально усложняют жизнь «злым гениям», но не мешают нормальным разработчикам. А если язык заставляет человека вручную контролировать то, что компилятор мог бы сделать автоматически — это не фича, а огромный недостаток.
Тогда понятно из чего идеология 1с выросла. Держите процедурный язык почти без ООП и радуйтесь что нихрена не можете)
Я специально выделил фразу «разумные ограничения». И контроль, и вседозволенность могут быть излишними. К счастью, уже существуют достаточно продвинутые системы типов, которые с одной стороны обеспечивают всевозможные проверки (вплоть до доказательства корректности программы), а с другой стороны не лишают язык гибкости.
Так и в Perl'e ООП был добавлен сбоку.
Не видел перл, но подозреваю там все же есть возможность свои объекты определять. В отличие от 1с где можешь наследоваться от набора из нескольких типов объектов, и почти все они по сути к схеме БД привязаны, за исключением некоторых. Структуры в коде определять можно, а вот совмещать в одном своем объекте данные с методами уже никак.

Любая благословленная ссылка в Perl'е — это объект. И привычных вещей(наследование, инкапсуляция и т.д.) туда не завезли. Поэтому сообщество напридумало хелперы Moose, Moo и т.д.

Наследование есть. Инкапсуляция (если не путать её с сокрытием реализации) — тоже есть. Сообщество напридумало хелперы, чтобы получить отсутствующую «в коробке» функциональность типа триггеров или ленивых аксессоров. Модель ООП в перле довольно своеобразная и пристегнутая сбоку, но как ни странно, довольно гибкая.
Вообще говоря, из новых языков наследование выпиливают, потому что очень плохая идиома.

Тот же раст прекрасно живёт на структурах, функциях и типажах, без ООП, и его никто за это не ругает.
Я больше не про наследование, а про плюшки интерфейсов и инкапсуляции данных и методов. Ибо в 1с можно свои структуры делать, но например замыкания отсутствуют, и из за динамической типизации получается что структура используется в куче мест, и вся эта куча мест должна знать о том какие у структуры есть поля, каких могут быть типов и т.д. Никакой блин абстракции. В некоторых случаях конечно можно расположить функции со структурой работающие локально в том же модуле где определяем структуру, но это возможно не всегда к сожалению, и уж тем более не всегда удобно.
А насчет раста есть подозрения что он прекрасно живет из за хорошей системы типов.
В энтерпрайзной разработке не должно быть никакого «творчества на уровне языка».

Я вас сильно удивлю, если скажу что есть и другие виды разработок?

Ограничения должны быть административными — как и в ПДД. Представьте что автомобили физически ограничены двигаться не более 50 км/ч в городе, или принудительно останавливаются на знаке STOP — это нормально будет?
Если вам кажется, что ограничение в 50 км\ч — это страшно, то представьте себе город, в котором ПДД вообще отсутствуют, и разрешено все, что позволяют законы физики. Вот это будет действительно страшно.
Мне кажется, он пишет про стайлгайд как альтернативу ограничениям языка, а не про анархию.
Продолжая автомобильную аналогию, статическая типизация = ПДД, стайлгайд = здравый смысл. Только на чем-то одном из них далеко не уедешь.
Мне кажется страшным не само ограничение, а его принудительность — потому что бывают ситуации когда оно мешает (маневр для ухода от столкновения, к примеру, экстренный обгон etc). Я имел в виду именно физическое ограничение — т.е. случай когда автомобиль «залочен» на скорости до 50 или сам останавливается на знаке STOP, или даже ещё хуже — тупо останавливается на красный и начинает ехать на зеленый (тоже сам).

Есть языки которые позволяют делать operator overloading, а есть которые не позволяют — причиной называется то что это «может запутать» и «ухудшает читабельность» — хотя в ряде случаев как раз наоборот, то же самое относится к goto — это вопрос вкуса, если угодно.

Точно также и с Perl — может в ряде случаев это и ухудшит ситуацию, но может и улучшить. В конкретном проекте легко выставить условие — «никаких сомнительных конструкций» — и всё, вопрос закрыт, а для внутренних скриптов-однодневок, экспериментов или кода который ограничен по времени или памяти это может быть только плюсом.

Лучше иметь в баре бутылку виски и не пить его, чем не иметь и вдруг обнаружить что хочется выпить (опасность тут только для алкоголиков).
Вас не затруднит показать примеры такого же ужаса на других языках? Чтобы синтаксис языка был неанализируем LR-парсером? Для меня этот «динамический синтаксис» означает одно — закапывать.

Для любого другого языка можно понять, что происходит, глядя в код. В перле его надо выполнять — в противном случае понять невозможно.
Погуглите codegolf %language% — найдете массу примеров, когда вы не сможете понять что происходит не выполняя код (а иногда и выполняя), практически на любом языке, несмотря на то что синтаксис легко разбирается.

Для меня, к примеру, являются практически нечитаемыми (= невозможно понять) навороченные многоуровневые темплейты в C++, их явно понимает только автор, но это ведь не проблема языка.
Если темплейты нельзя проанализировать статически, то да, это проблема языка.

Я посмотрел на codegolf для питона — там совершенно милые и забавные выкрутасы, которые заставляют задуматься «о как», но смысл которых понятен без исполнения кода.
Если темплейты (конкретный результат) не может понять любой человек, который знаком с языком — то это проблема этого человека.

Чтобы код был понятен всем, существуют style guide, никакой язык не заставит писать код который понятен всем (разве что там всего несколько строк).

Возьмите любой проект на js, пропустите через минимизатор (и оптимизатор) — и удачи в понимании его смысла, особенно если это библиотека типа jquery. И сейчас скажите что проблема в языке? Что примечательно, некоторые так пишут сами, на разных языках…
синтаксис js полностью анализируемый статически. Вы просто не хотите прочитать про эту perl drama. А она есть. perl — единственный из употребимых языков, который не может быть разобран лексером/парсером.

Никакие примеры «глупых сравнений» из js, или «wtf» для темплейтов с++ близко не подходят к необъятности ужаса языка, чей синтаксис является контекстно-зависимым.

UPD: Ближайшим аналогом могут быть макросы в Си, но они, всё-таки, не си, а препроцессор.
Я не вижу драмы — иначе бы не существовало кучи проектов на Perl и он бы не был популярен в принципе (никогда), а сам факт того что он использовался и используется говорит о том что невозможность статического парсинга вовсе не помеха.

Мне лично гораздо более неприятно то что в C/C++ неопределен порядок вычисления аргументов функций (да и вообще выражений) — вот это действительно драма, по сравнению с динамическим парсингом, потому что, в отличие от динамического парсинга, это вообще непредсказуемо, но это никого не смущает:
(a++)+(++a)+(a--)+(--a)

Такое выражение даст разные результаты в зависимости от платформы, компилятора, его версии или настроек оптимизации — но почему-то допускается, несмотря на возможность статического парсинга.

Вы можете возразить — «не надо такое использовать» — так что же мешает не использовать особенности Perl, в таком случае?
Я тоже не вижу драмы ни в Perl, ни в COBOL ни в PL/I. Языки как языки. Огромное количество софта написано на COBOL и прекрасно работает десятилетиями.

Но я не хочу иметь ни с одним из этих языков ничего общего.

Я понимаю, ваши наезды на Си, и полностью их поддерживаю — такого минного поля трудно себе представить. Однако, наличие ужаса в Си оправдывает его системный статус. У перла такого статуса нет — во всех мейнстримовых дистрибутивах перл и python идут нос-в-нос.

Я могу назвать сходу с десяток WTF для питона, но ни одно из них даже близко не подходит к выразительности и многоэтажности высказываний об идиоматичности перла.
Если критиковать язык только за то, что на нем можно вызвать Сатану, то Си тоже попадает под удар, но пока не слышно, чтобы ему пришел конец. Да, на перле Сатану можно вызвать. И можно сделать это гораздо интереснее, чем написано в Вашем примере. А можно не страдать фигнёй и вместо этого написать что-то работающее.

Для приведенного Вами фрагмента кода есть еще третий вариант: в дефолтном режиме whatever будет считаться просто строкой. Остальные два варианта, рассмотренные в цитате, полагаются на то, что где-то выше по коду есть объявление функции. Если дополнить фрагмент этим объявлением, неоднозначность исчезнет. Randal Schwartz был хитёр.
Да, на перле Сатану можно вызвать.

На Перле — Сатана появится мгновенно
На С — Сатана появится по частям
На Java чтобы призвать Сатану нужно прочитать длинную молитву
На Javascript Сатана появится, но возможно не тот…
На Перле — Сатана появится мгновенно
nuff said
На С — Сатана появится по частям
С простреленной ногой, точнее. А ещё и вам прострелит
На Java чтобы призвать Сатану нужно прочитать длинную молитву
С перерывами на уборку мусора (эта шутка, возможно, несколько устарела)
На Javascript Сатана появится, но возможно не тот…
точно не тот
Отличные системы, от которых впадает в ужас молодёжь. Сопляки, для них это слишком сильная магия.
Фон Нейман утверждал, что ассемблер для слабаков и waste машинного времени (ибо надо два прохода для обработки меток), а настоящие мужики сами способны адреса переходов в машинных инструкциях поставить.

Я даже не шучу. www.youtube.com/watch?v=nc2q4OOK6K8
Я джва года ждал такого курса!
Без шуток, два года назад попалась мне задача, реализованная на перле, а я ни бум-бум. Пришлось учить питон и пилить свой велосипед.
В общем хорошая новость, может после этого курса я смогу понять что там было «накОдено»
Я год переписывал легаси-тесты с Perl на Java, читать научился на Perl довольно быстро. Сначала, конечно, гуглил много, а потом само пошло. :)

Perl — хороший язык, мощный и выразительный, по-своему прекрасный, но он мало где нужен, если быть честным. Вот только уж если нужен, то за большую зарплату (и придется работать, как правило, с авгиевыми конюшнями легаси).
Конечно, вы по большей части правы, но есть и новые проекты.
Есть такой Perl, который весьма похож на Golang (демоны на AnyEvent + Coro), только с удобной динамической типизацией и прочими удобствами скриптовых языков.
похож на Golang (демоны на AnyEvent + Coro)

В каком месте? AnyEvent построен на каллбеках. Соответственно привет callback hell.

Смотрите в сторону Coro

Если правильно понимаю coro, то это корутины и только одна корутина выполняется на CPU. Чем они похоже на Golang не понятно, там горутины могут выполнятся на разных ядрах.

js и dart тоже построены на callback, но, с другой стороны, для AnyEvent есть аналог await, так что не всё так плохо.

callback hell, впрочем, следствие непонимания или неправильного использования асинхронных фич, но всё можно делать правильно.
Код в студию)
Всё же цель, для которой изобретался язык оставляет отпечаток на нём. Ларри изобрёл Perl для ускорения создания отчетов — поэтому там встроенные в сам язык регекспы, прямое чтение из файлов через < > и прочие контекстные переменные ($_)

Perl по-своему прекрасен, особенно в нише работы с текстовыми данными, сам несколько лет на нём писал. Но новые проекты сейчас на нем начинать бы ни за что не стал.

А теперь попробуем найти вакансии ML с Perl...

Поиск вакансий может быть проблемой, но если человек уже знает Perl и у него появляется задача ML, то Perl окажется ничуть не хуже Python.
Жду когда Mail.ru откроет вакансии для Perl программистов в Минске. Жить, работать в РФ нет никакого желания.
Оооо, Perl! Свою первую программу на Perl я написал в 1999 году и занималась она тем, что преобразовывала дату рождения по квадрату Пифагора. Вывесил в общий доступ веб-морду (пришлось написать и обработчик шаблонов на Perl) и забыл до 2014 года. Разбирая файл со старыми паролями обнаружил, что сайтик все еще жив и имеет приличный поток посетителей (выбился на первое место и в гугл, и в яндекс, и в mail.ru по ключевому запросу). В среднем каждый пользователь делает расчет для четырех дат. Сайт все еще работает и все еще на первом месте в поисковиках. Приятно, когда, твоя первая программа оказывается таким долгожителем.
Когда предполагается запуск курса?
Внезапно, уже стартовал :)
Да, появилась ссылка в начале топика. Уже тренируюсь.
Спасибо, не бросили )
Курс уже пару дней как открыт.
Хотя вот начинающим я бы его не советовал. Объяснений мало, в задачах приходится разбираться копаясь в дополнительных материалах ибо решать надо используя то, чему еще не научили. В общем для начинающих будет слишком туго, а для тех, кто разбирается наверное слишком просто? В итоге казалось бы интересный курс, но непонятно на кого рассчитанный.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий