В ноябре на платформе Степик стартует курс «Введение в Perl» от разработчиков Mail.Ru Group, где слушатели будут иметь возможность изучить основы программирования на языке Perl и обозначить направления для дальнейшего развития.
В процессе обучения будут рассматриваться синтаксис языка, работа с модулями, ООП, регулярные выражения, однострочники, взаимодействие языка с операционной системой, основы ввода-вывода и параллелизм. Основной акцент сделан на базовых знаниях языка и системном программировании. Программа рассчитана на новичков: для освоения курса достаточно иметь представление об алгоритмах и знать базовые понятия (переменная, условный оператор и т.д.).
Актуальность курса
Некоторые считают, что язык Perl мертв, поэтому одной из задач курса является развенчание этого мифа. Учитывая современные модули и функциональность языка, сегодня Perl способен решать любые задачи.
В Mail.Ru Group Perl — часть большинства проектов: «Поиск», «Облака», «Почта», «Портал», «Мой Мир». Есть и новые большие проекты, стартовавшие именно на Perl: VK Pay, Music Mail.Ru, а также B2B-платформа Mail.Ru Cloud Solutions.
Николай Шуляковский, автор и преподаватель курса:
Наш курс — фундамент, на основе которого можно продолжать обучение. Мы не готовим специалистов, которые после курса смогут писать высоконагруженные приложения. Наша цель — обучить людей, которые будут знать, в какую сторону развиваться. Мы стремимся дать студентам базовое представление о Perl: что это за язык, в каком он состоянии, что на нем можно делать. Мы рассказываем обо всем понемногу и даем ссылки, куда двигаться дальше в зависимости от областей, интересных конкретному слушателю.
Курс «Введение в Perl» можно рассматривать как вступительную часть к нашим университетским курсам в рамках образовательных проектов Mail.Ru Group — Технопарк (МГТУ им. Н.Э. Баумана), Техносфера (МГУ), Техноатом (МИФИ), где готовят специалистов, которых мы берем на стажировку. Сейчас в нашем отделе восемь стажеров, пришедших после семестрового курса по Perl. Пятеро уже перешли в разряд младших разработчиков. Это успех!
Авторы курса
Николай Шуляковский, заместитель технического директора департамента adVentures, в ведении которого находятся такие проекты, как «Мой Мир», «Музыка Mail.ru», «VK Pay», «Дешевле вместе» и др. Опыт работы: Агава, MCG Network, Mail.Ru Group. Опыт разработки на Perl — 14 лет. Проекты на Perl: «Почта Mail.Ru», «Мой Мир», «VK Pay», «Музыка Mail.Ru».
Сергей Пантелеев, технический руководитель системной разработки в департаменте adVentures. Опыт работы: Web2000, издательство «Открытые системы», Intuit.ru, Acronis, Mail.Ru Group. Опыт разработки на Perl — 18 лет. Проекты на Perl: «Мой Мир», «Музыка Mail.Ru» и др.
Александр Матвеев, веб-разработчик в департаменте adVentures. Опыт работы: Мастерхост, Zenon, Mail.Ru Group. Опыт разработки на Perl — 13 лет. Проекты на Perl: «Мой Мир», «Музыка Mail.Ru», «Дешевле вместе» и др.
Владимир Перепелица, архитектор Mail.Ru Cloud Solutions. Опыт работы: Mail.Ru Group, Undercover Market, Рамблер, Агава, Опора России. Опыт разработки на Perl — 18 лет. Проекты на Perl: Платформа Mail.Ru Cloud Solutions, Hotbox Cloud Storage, Облако Mail.Ru, Рамблер Фото и др.
Длительность и формат
Курс бесплатный. Он состоит из шести разделов, в каждом из которых в среднем по четыре урока. Длительность каждого ролика — не более 15 минут. Уроки содержат небольшие проверочные задания на написание кода и тесты на усвоение материала. Домашние задания проверяются автоматически. Общаться с преподавателями и другими студентами можно с помощью комментариев внутри платформы Степик.
В «режиме маньяка» курс можно освоить за один день, но для более глубокого обучения (внимательный просмотр видеоматериалов, чтение документации, выполнение всех заданий) потребуется около двух месяцев.
Результаты курса
Слушатели, успешно завершившие курс, умеют:
- писать код на Perl;
- читать код на Perl — это очень важный навык, так как Perl предполагает, что один и тот же алгоритм можно написать по-разному. Каждый программист пишет так, как считает нужным, поэтому один из основных навыков работы с языком — чтение перлового кода;
- создавать модули на Perl и работать с библиотекой модулей;
- использовать синтаксический сахар языка Perl;
- работать с ОС и сетью из языка Perl;
- применять принципы ООП при написании программ на Perl.
Программа курса
1. Введение
- Perl, perldoc
- Особенности разработки под ОС Windows
- cpanm, metacpan, «local::lib»
2. Синтаксис и данные (основы)
- vars, interpolation, ifs
- Циклы
- Массивы, хеши и работа с ними
3. Регулярные выражения
- Простой поиск
- Квантификаторы
- Захваты
- Модификаторы
- Замена
- Однострочники
4. Модули
- Основы подключения модулей
- Пакеты
- Области видимости переменных
- Подключение модулей директивой use
- Стандартные модули Perl
5. ООП (основы)
- Реализация ООП в Perl
- Создание объектов
- Свойства и методы
- Наследование и композиция
6. Взаимодействие с ОС
- Работа с файлами
- Взаимодействие процессов
- Сериализация данных
- Работа с сетью
Преподаватели о курсе
Александр Матвеев, Николай Шуляковский:
Курс записывался в очень комфортной обстановке, в потрясающей студии, о которой мы узнали благодаря Степику. Студия полностью автоматизирована, поэтому ролики можно было перезаписывать сколько угодно раз: поправлять бабочку, переделывать текст…
Конечно, чтение перед публикой и запись на камеру — две разные вещи. Читая лекцию аудитории, видишь глаза учеников и чувствуешь, если они где-то застряли и перестали воспринимать материал. Камера такого фидбека не дает. Было сложно перестроиться и осознать, что ты рассказываешь не кому-то, а в стену.
К тому же у нас не было опыта работы на камеру, и первые 3-4 поездки в студию заканчивались пониманием, что нужно все перезаписывать.
Если курс будет интересен и соберется большая аудитория, мы запишем расширенную версию с более объемными домашними заданиями. И для нас, и для Степика курс по Perl — нечто новое, поэтому пока мы остановились на базовых вещах. В зависимости от отклика будем улучшать, изменять и дорабатывать.
Комментарии (89)
saag
07.11.2018 16:40-4знакомьтесь это Perl
Inine
07.11.2018 16:59Месяца два назад натыкался на предыдущий курс от этих же ребят. Несмотря на то, что лет 15 тому назад интересовался этим языком, забуксовал очень быстро. Все-таки знать язык и уметь его преподавать — очень разные вещи.
Отдельная проблема — настройка окружения (интерпретатор, ide, кодировки и пр.) надеюсь, в новом курсе уделили этому внимание. У меня, например, возникла странная проблема с кавычками, которая проявлялась только в винде, и только в консоли. Гуглил с полчаса — без толку. Как раз таким вещам стоит посвятить часик во вводной лекции, а не лить воду про историю и философию.Bambr
07.11.2018 18:03Попробую ответить по порядку.
Курс на Stepik, который анонсирован в этом посте, и «предыдущий курс» из Вашей ссылки действительно имеют общие корни. Изначально был создан живой курс для обучения студентов в рамках образовательных проектов mail.ru (Технопарк и другие). Фрагментарная видеозапись одного из первых выпусков этого материала и была выложена на youtube с достаточно прагматической целью: чтобы дать возможность студентам пересматривать лекционный материал в процессе работы над домашками. Видео достаточно сильно сокращено, там нет ответов на вопросы студентов и многих других вещей, и стартовать, имея только это видео, действительно может быть достаточно тяжело. Впрочем, «живой» курс не оставался неизменным и видоизменялся от семестра к семестру, учитывая успехи и неудачи предыдущих прогонов, так что есть надежда, что мы сумели с тех пор сделать его лучше. Из этого материала и родился курс для Stepik'а. В его названии есть слово «введение». Мы отобрали только те темы, которые действительно необходимы для знакомства с языком, и позволят изучить его синтаксис и начать писать на нем небольшие программы. Сложные разделы, требующие дополнительных знаний и опыта разработки, мы постарались в эту версию курса не включать. Получилось у нас сделать курс доступнее или нет — не знаю, время покажет. В том, что там найдется определенное количество косяков, которые придется исправлять — не сомневаюсь, но мы к этому готовы.
Исторический экскурс в новом видео предельно сокращен, на него отводится менее двух минут в стартовой лекции, и еще меньше приходится на философию. Второй видеофрагмент как раз касается работы под Windows: там предупреждение о том, что по мере закапывания вглубь проблем под виндами будет все больше и больше и в целом этот путь не рекомендуется. Кавычки не имеют прямого отношения к перлу, это связано с работой консоли, но об этом мы тоже предупреждаем. Чтобы облегчить старт и не собирать все эти грабли, можно, например, воспользоваться приготовленной для вас виртуалкой.
Singaporian
07.11.2018 17:11-4Некоторые считают, что язык Perl мертв, поэтому одной из задач курса является развенчание этого мифа.
Вот отсюда поподробнее можно пожалуйста?
Учитывая современные модули и функциональность языка, сегодня Perl способен решать любые задачи.
Наконец появился язык, на котором все можно писать! А то вечно как ни начнешь модуль ядра писать, так приходится с петона на си прыгать. Теперь муки позади.Singaporian
10.11.2018 10:09Ловите хабра-суицид по имя правды.
Прошу обратить внимание на интересный факт: я получил гору минусов в карму и в сам коммент, но развенчание мифа не последовало.
Это говорит многое о «религиозности» отношения к языку. Не о логичном выборе, который есть чем защищать. Можно подвергнуть сомнению Аллаха, а можно подвергнуть сомнению статус Перла — отношение адептов будет одинаковым.
Вывод: вместо опровержения мифа сами же его и подтвердили, продемонстрировал отсутствие конструктива.
maxzhurkin
07.11.2018 17:53А «Выведение из Perl» будет?
Bambr
07.11.2018 19:03Выведение обещать не могу, но в офисе мейла есть Служба Вынимания. Приходите, если сможем — поможем :)
g0rd1as
07.11.2018 22:11+1Вы как будто про запой пишете! :))) Не такой уж Perl затягивающий!
maxzhurkin
08.11.2018 08:54Мне пришлось изучать Ruby, чтобы избавиться от Perl-зависимости :)
g0rd1as
09.11.2018 16:12А почему не питон?
maxzhurkin
09.11.2018 16:29По религиозным соображениям: у меня всегда аккуратные отступы, гораздо аккуратнее самого кода, но я не могу представить язык, где отступы являются неотъемлемой частью синтаксиса — это аргумент против Python, а вот мой личный аргумент аргумент за Ruby: автор Ruby, как я понял, хотел создать язык «как Perl, но без его тяжёлого наследия»;
Ruby родился 23 февраля 1993 года. В тот день я беседовал со своим коллегой о возможности существования объектно-ориентированного сценарного языка. Я знал Perl (Perl4, а не Perl5), но он мне не нравился — был в нём некий привкус игрушечного языка (да и поныне есть). А объектно-ориентированный интерпретируемый язык казался многообещающим. В то время я знал Python. Но он мне не нравился потому, что я не считал его настоящим объектно-ориентированным языком. Его OO свойства казались надстройкой над языком. Мне, как языковому маньяку и фанату объектно-ориентированного программирования с пятнадцатилетним стажем, очень, очень хотелось, чтобы был истинно объектно-ориентированный, простой в использовании язык. Я пытался найти такой язык, но его не было.
— это цитата автора по Википедии, именно по ней много лет назад я понял, что хочу знать Ruby и забыть PerlSingaporian
10.11.2018 10:12Вы не могли бы привести два примера: отступы в Питоне и более аккуратные отступы. Прямо заинтриговали.
amarao
07.11.2018 18:01-3Курсы COBOL, PL/I и PERL от MAIL.RU
Запустите обозреватель интернета версии 5.5 и введите в адресной строке адрес myspace.com/mail.ru…Tangeman
07.11.2018 18:39+1Сравнивать Perl и Cobol это примерно как сравнивать C# и Basic.
amarao
07.11.2018 19:28-1В контексте всяких дотнетов — вполне себе сравнимы. 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=663393Tangeman
07.11.2018 19:46Ужасные языки — это brainfuck & co, а в остальных бывает только ужасный код, причём в любых. Ужасно могут выглядеть и Python и Go, в зависимости от уровня кодера (или его желания выпендриться), и куча кода на PHP (некоторые популярные плагины под WP, к примеру) просто за гранью добра.
Да, Perl позволяет создавать малочитаемый код, но это выбор разработчика, а не особенность языка. Если я пишу скрипт для себя из серии «написал и забыл» — это не проблема, а для проекта который уйдёт в свет и с которым будет работать команда можно писать чисто и понятно. Для этого, кстати, и нужно адекватное обучение.amarao
08.11.2018 13:53Вы не поняли всей бездны этого примера. Вы не можете разобрать синтаксис перла в общем случае, не решив задачи остановки, а она нерешаемая.
Другими словами, сам язык допускает конструкции на уровне парсера (!), которые невозможно разобрать не разобрав, что делает программа.
На этом месте его можно закапывать, потому что такого даже ассемблер (без полиморфизма) себе не позволяет.Tangeman
08.11.2018 19:08В приведенном примере задача остановки может быть притянута за уши только если речь идёт о статическом парсинге (без выполнения). Неудивительно, что статический парсинг невозможен — но его никто не делает (и не собирается), соответственно, пример «дьявольского кода» с сопуствующим текстом — это всего лишь мысленные упражнения.
Да, язык это позволяет (потому что это фича), но не навязывает — не вижу проблемы. Вы же не запрещаете производство кухонных ножей просто потому что ими можно кого-то убить или порезаться? Да и лицензий или курсов обучения для пользования бытовыми ножами я что-то не встречал — но вот удивительное дело, это не приводит к проблемам, кроме изолированных частных случаев.
Как я уже говорил раньше, никакой язык не обеспечит идеальности кода без желания разработчика (или его начальника) — на любом, даже самом идеальном и зарегулированном донельзя языке можно написать полную хрень, никем кроме автора не читаемую и непонимаемую (но вполне работоспособную), но это само по себе не делает язык плохим или хорошим.
Не надо ограничивать творчество на уровне языка — злые гении всё равно найдут выход, а добрые обидятся и не сделают чего-то великого в момент озарения.impwx
09.11.2018 10:40Не надо ограничивать творчество на уровне языка
В энтерпрайзной разработке не должно быть никакого «творчества на уровне языка». Вместо этого должны быть разумные ограничения, которые максимально усложняют жизнь «злым гениям», но не мешают нормальным разработчикам. А если язык заставляет человека вручную контролировать то, что компилятор мог бы сделать автоматически — это не фича, а огромный недостаток.Neikist
09.11.2018 10:47Тогда понятно из чего идеология 1с выросла. Держите процедурный язык почти без ООП и радуйтесь что нихрена не можете)
impwx
09.11.2018 11:07Я специально выделил фразу «разумные ограничения». И контроль, и вседозволенность могут быть излишними. К счастью, уже существуют достаточно продвинутые системы типов, которые с одной стороны обеспечивают всевозможные проверки (вплоть до доказательства корректности программы), а с другой стороны не лишают язык гибкости.
RPG18
09.11.2018 11:31Так и в Perl'e ООП был добавлен сбоку.
Neikist
09.11.2018 11:55Не видел перл, но подозреваю там все же есть возможность свои объекты определять. В отличие от 1с где можешь наследоваться от набора из нескольких типов объектов, и почти все они по сути к схеме БД привязаны, за исключением некоторых. Структуры в коде определять можно, а вот совмещать в одном своем объекте данные с методами уже никак.
RPG18
09.11.2018 12:12Любая благословленная ссылка в Perl'е — это объект. И привычных вещей(наследование, инкапсуляция и т.д.) туда не завезли. Поэтому сообщество напридумало хелперы Moose, Moo и т.д.
Bambr
09.11.2018 12:43Наследование есть. Инкапсуляция (если не путать её с сокрытием реализации) — тоже есть. Сообщество напридумало хелперы, чтобы получить отсутствующую «в коробке» функциональность типа триггеров или ленивых аксессоров. Модель ООП в перле довольно своеобразная и пристегнутая сбоку, но как ни странно, довольно гибкая.
amarao
09.11.2018 13:45Вообще говоря, из новых языков наследование выпиливают, потому что очень плохая идиома.
Тот же раст прекрасно живёт на структурах, функциях и типажах, без ООП, и его никто за это не ругает.Neikist
09.11.2018 14:26Я больше не про наследование, а про плюшки интерфейсов и инкапсуляции данных и методов. Ибо в 1с можно свои структуры делать, но например замыкания отсутствуют, и из за динамической типизации получается что структура используется в куче мест, и вся эта куча мест должна знать о том какие у структуры есть поля, каких могут быть типов и т.д. Никакой блин абстракции. В некоторых случаях конечно можно расположить функции со структурой работающие локально в том же модуле где определяем структуру, но это возможно не всегда к сожалению, и уж тем более не всегда удобно.
А насчет раста есть подозрения что он прекрасно живет из за хорошей системы типов.
Tangeman
09.11.2018 13:59+1В энтерпрайзной разработке не должно быть никакого «творчества на уровне языка».
Я вас сильно удивлю, если скажу что есть и другие виды разработок?
Ограничения должны быть административными — как и в ПДД. Представьте что автомобили физически ограничены двигаться не более 50 км/ч в городе, или принудительно останавливаются на знаке STOP — это нормально будет?impwx
09.11.2018 14:40Если вам кажется, что ограничение в 50 км\ч — это страшно, то представьте себе город, в котором ПДД вообще отсутствуют, и разрешено все, что позволяют законы физики. Вот это будет действительно страшно.
Tangeman
09.11.2018 15:59Мне кажется страшным не само ограничение, а его принудительность — потому что бывают ситуации когда оно мешает (маневр для ухода от столкновения, к примеру, экстренный обгон etc). Я имел в виду именно физическое ограничение — т.е. случай когда автомобиль «залочен» на скорости до 50 или сам останавливается на знаке STOP, или даже ещё хуже — тупо останавливается на красный и начинает ехать на зеленый (тоже сам).
Есть языки которые позволяют делать operator overloading, а есть которые не позволяют — причиной называется то что это «может запутать» и «ухудшает читабельность» — хотя в ряде случаев как раз наоборот, то же самое относится к goto — это вопрос вкуса, если угодно.
Точно также и с Perl — может в ряде случаев это и ухудшит ситуацию, но может и улучшить. В конкретном проекте легко выставить условие — «никаких сомнительных конструкций» — и всё, вопрос закрыт, а для внутренних скриптов-однодневок, экспериментов или кода который ограничен по времени или памяти это может быть только плюсом.
Лучше иметь в баре бутылку виски и не пить его, чем не иметь и вдруг обнаружить что хочется выпить (опасность тут только для алкоголиков).
amarao
09.11.2018 13:44Вас не затруднит показать примеры такого же ужаса на других языках? Чтобы синтаксис языка был неанализируем LR-парсером? Для меня этот «динамический синтаксис» означает одно — закапывать.
Для любого другого языка можно понять, что происходит, глядя в код. В перле его надо выполнять — в противном случае понять невозможно.Tangeman
09.11.2018 14:05+1Погуглите codegolf %language% — найдете массу примеров, когда вы не сможете понять что происходит не выполняя код (а иногда и выполняя), практически на любом языке, несмотря на то что синтаксис легко разбирается.
Для меня, к примеру, являются практически нечитаемыми (= невозможно понять) навороченные многоуровневые темплейты в C++, их явно понимает только автор, но это ведь не проблема языка.amarao
09.11.2018 14:07Если темплейты нельзя проанализировать статически, то да, это проблема языка.
Я посмотрел на codegolf для питона — там совершенно милые и забавные выкрутасы, которые заставляют задуматься «о как», но смысл которых понятен без исполнения кода.Tangeman
09.11.2018 16:12Если темплейты (конкретный результат) не может понять любой человек, который знаком с языком — то это проблема этого человека.
Чтобы код был понятен всем, существуют style guide, никакой язык не заставит писать код который понятен всем (разве что там всего несколько строк).
Возьмите любой проект на js, пропустите через минимизатор (и оптимизатор) — и удачи в понимании его смысла, особенно если это библиотека типа jquery. И сейчас скажите что проблема в языке? Что примечательно, некоторые так пишут сами, на разных языках…amarao
09.11.2018 17:51синтаксис js полностью анализируемый статически. Вы просто не хотите прочитать про эту perl drama. А она есть. perl — единственный из употребимых языков, который не может быть разобран лексером/парсером.
Никакие примеры «глупых сравнений» из js, или «wtf» для темплейтов с++ близко не подходят к необъятности ужаса языка, чей синтаксис является контекстно-зависимым.
UPD: Ближайшим аналогом могут быть макросы в Си, но они, всё-таки, не си, а препроцессор.Tangeman
09.11.2018 19:39+1Я не вижу драмы — иначе бы не существовало кучи проектов на Perl и он бы не был популярен в принципе (никогда), а сам факт того что он использовался и используется говорит о том что невозможность статического парсинга вовсе не помеха.
Мне лично гораздо более неприятно то что в C/C++ неопределен порядок вычисления аргументов функций (да и вообще выражений) — вот это действительно драма, по сравнению с динамическим парсингом, потому что, в отличие от динамического парсинга, это вообще непредсказуемо, но это никого не смущает:
(a++)+(++a)+(a--)+(--a)
Такое выражение даст разные результаты в зависимости от платформы, компилятора, его версии или настроек оптимизации — но почему-то допускается, несмотря на возможность статического парсинга.
Вы можете возразить — «не надо такое использовать» — так что же мешает не использовать особенности Perl, в таком случае?
Bambr
07.11.2018 21:22Если критиковать язык только за то, что на нем можно вызвать Сатану, то Си тоже попадает под удар, но пока не слышно, чтобы ему пришел конец. Да, на перле Сатану можно вызвать. И можно сделать это гораздо интереснее, чем написано в Вашем примере. А можно не страдать фигнёй и вместо этого написать что-то работающее.
Для приведенного Вами фрагмента кода есть еще третий вариант: в дефолтном режиме whatever будет считаться просто строкой. Остальные два варианта, рассмотренные в цитате, полагаются на то, что где-то выше по коду есть объявление функции. Если дополнить фрагмент этим объявлением, неоднозначность исчезнет. Randal Schwartz был хитёр.saag
08.11.2018 08:18Да, на перле Сатану можно вызвать.
На Перле — Сатана появится мгновенно
На С — Сатана появится по частям
На Java чтобы призвать Сатану нужно прочитать длинную молитву
На Javascript Сатана появится, но возможно не тот…maxzhurkin
08.11.2018 10:32На Перле — Сатана появится мгновенно
nuff said
На С — Сатана появится по частям
С простреленной ногой, точнее. А ещё и вам прострелит
На Java чтобы призвать Сатану нужно прочитать длинную молитву
С перерывами на уборку мусора (эта шутка, возможно, несколько устарела)
На Javascript Сатана появится, но возможно не тот…
точно не тот
roscomtheend
08.11.2018 12:29Отличные системы, от которых впадает в ужас молодёжь. Сопляки, для них это слишком сильная магия.
amarao
08.11.2018 14:01Фон Нейман утверждал, что ассемблер для слабаков и waste машинного времени (ибо надо два прохода для обработки меток), а настоящие мужики сами способны адреса переходов в машинных инструкциях поставить.
Я даже не шучу. www.youtube.com/watch?v=nc2q4OOK6K8
wiwrel
07.11.2018 21:26Я джва года ждал такого курса!
Без шуток, два года назад попалась мне задача, реализованная на перле, а я ни бум-бум. Пришлось учить питон и пилить свой велосипед.
В общем хорошая новость, может после этого курса я смогу понять что там было «накОдено»g0rd1as
07.11.2018 22:16Я год переписывал легаси-тесты с Perl на Java, читать научился на Perl довольно быстро. Сначала, конечно, гуглил много, а потом само пошло. :)
Perl — хороший язык, мощный и выразительный, по-своему прекрасный, но он мало где нужен, если быть честным. Вот только уж если нужен, то за большую зарплату (и придется работать, как правило, с авгиевыми конюшнями легаси).codesign
08.11.2018 00:40Конечно, вы по большей части правы, но есть и новые проекты.
Есть такой Perl, который весьма похож на Golang (демоны на AnyEvent + Coro), только с удобной динамической типизацией и прочими удобствами скриптовых языков.RPG18
08.11.2018 11:56похож на Golang (демоны на AnyEvent + Coro)
В каком месте? AnyEvent построен на каллбеках. Соответственно привет callback hell.
shulyakovskiy
08.11.2018 12:43Смотрите в сторону Coro
RPG18
08.11.2018 13:16Если правильно понимаю coro, то это корутины и только одна корутина выполняется на CPU. Чем они похоже на Golang не понятно, там горутины могут выполнятся на разных ядрах.
Tangeman
08.11.2018 22:10js и dart тоже построены на callback, но, с другой стороны, для AnyEvent есть аналог await, так что не всё так плохо.
callback hell, впрочем, следствие непонимания или неправильного использования асинхронных фич, но всё можно делать правильно.
blind_oracle
07.11.2018 22:54Всё же цель, для которой изобретался язык оставляет отпечаток на нём. Ларри изобрёл Perl для ускорения создания отчетов — поэтому там встроенные в сам язык регекспы, прямое чтение из файлов через < > и прочие контекстные переменные ($_)
Perl по-своему прекрасен, особенно в нише работы с текстовыми данными, сам несколько лет на нём писал. Но новые проекты сейчас на нем начинать бы ни за что не стал.
shrimo
08.11.2018 01:30+1Пока вы будете учить Perl — нейронные сети под Python захватят весь мир.
TheAthlete
08.11.2018 10:17+1Для Perl тоже есть машинное обучение и нейронные сети)
AI::MXNet
Цикл статей:
Machine learning in Perl
Machine learning in Perl, Part2: a calculator, handwritten digits and roboshakespeare
Machine learning in Perl, Part3: Deep Convolutional Generative Adversarial network
Machine learning in Perl: Kyuubi goes to a (Model)Zoo during The Starry NightJekaMas
08.11.2018 11:15А теперь попробуем найти вакансии ML с Perl...
Tangeman
08.11.2018 22:16Поиск вакансий может быть проблемой, но если человек уже знает Perl и у него появляется задача ML, то Perl окажется ничуть не хуже Python.
shrimo
09.11.2018 22:31Думаю можно и на фортране NN запустить, и на ассемблере. Но зачем?
TIOBE Index for November 2018
melesik
08.11.2018 16:29Жду когда Mail.ru откроет вакансии для Perl программистов в Минске. Жить, работать в РФ нет никакого желания.
paulmann
08.11.2018 16:29Оооо, Perl! Свою первую программу на Perl я написал в 1999 году и занималась она тем, что преобразовывала дату рождения по квадрату Пифагора. Вывесил в общий доступ веб-морду (пришлось написать и обработчик шаблонов на Perl) и забыл до 2014 года. Разбирая файл со старыми паролями обнаружил, что сайтик все еще жив и имеет приличный поток посетителей (выбился на первое место и в гугл, и в яндекс, и в mail.ru по ключевому запросу). В среднем каждый пользователь делает расчет для четырех дат. Сайт все еще работает и все еще на первом месте в поисковиках. Приятно, когда, твоя первая программа оказывается таким долгожителем.
impwx
Видимо, самостоятельно выращивать новых специалистов оказалось дешевле и проще, чем портировать проекты на какой-нибудь более современный стек…
P6i
Это мэйл выращивает специалистов для букинга
urtow
Букинг вроде на Java переползает?
P6i
Не могу ни подвердить, ни опровергнуть это
urtow
habr.com/post/323094
Tangeman
Что «современный стек» умеет из того, чего не умеет Perl? И какой смысл портировать то что и так прекрасно работает — просто «чтобы было»?
К тому же, «современные стеки» имеют свойство устаревать очень быстро и часто несовместимы между своими мажорными версиями, и то что супер-пупер-круто сейчас, может стать несовременным уже через три-четыре года, а Perl как был так и будет есть ещё лет 30.
Разумеется, у Perl есть свои недостатки, но они есть у любого языка и любого фреймворка, но тот факт что Perl создан не один десяток лет назад не делает его устаревшим (к тому же он развивался всё это время), а наличие просто невероятного количества модулей и фреймворков действительно делает его вполне жизнеспособным и в наше время, и действительно для любых задач (кроме, разве что, чисто вычислительных, а также требующих нативной многопоточности).
MercurieVV
Находить разработчиков под него
Tangeman
Хороший разработчик на C/C++/Java/C#/JS/PHP без труда обучится Perl максимум за месяц — и это будет явно быстрее и дешевле чем портировать всё на новый стек.
IL_Agent
Хороший разработчик на перечисленных языках никогда не пойдёт на такую вакансию. Поэтому и надо переходить на актуальные инструменты.
Tangeman
А каким образом возраст языка определяет его актуальность?
PHP всего на 7 лет младше Perl, но ведь ещё актуален? И это несмотря на то что его ругают все кому не лень (причём за дело).
Си вообще почти древний (аж на 15 лет старше Perl) — и что, он уже неактуален?
Что касается «не пойдёт на вакансию» — это зависит от задачи и оплаты. Уверен, что если будет выбор между «CMS для порносайта» на C# за $50/час или «AI для робомобиля» на Perl за $75/час — то вряд ли многие выберут порносайты, даже если не знают Perl. Хотя, если это простые банальные кодеры — то да, выберут. А хорошие разработчики все же выберут второе.
IL_Agent
Актуальные — те, которые востребованы и на которые имеются разработчики без необходимости переучиваться.
RPG18
Количество вакансий под Perl видели? Теже Python и Go выглядят намного перспективней.
rkuvaldin
Назовите хоть одну РАЗУМНУЮ причину, почему ХОРОШИЙ разработчик на %s будет переходить на Perl?
Tangeman
Назову две — интересная задача и хорошая оплата. Интересность задачи с языком программирования редко коррелирует.
Хотя вообще-то хороший разработчик должен знать (т.е. уметь практически применять) несколько языков, и понимать намного больше (хотя бы со словарём), а также легко осваивать новые, иначе он просто узкоспециализированный кодер.
К несчастью, многие современные разработчики знают только один, любой другой (даже похожий) идёт с трудом, и шаг влево или вправо выбивает их из колеи. Печально.
rkuvaldin
Интересная задача может быть решена на любом Тьюринг-полном ЯП. Причем она будет решена быстрее на том языке, который ХОРОШИЙ программист уже знает.
Остается хорошая оплата :-) Да, копание в легаси-говнокоде это веская причина требовать удвоения рыночной зарплаты.
RPG18
Насколько хорошая оплата?
impwx
Perl не «плохой» и не «устаревший» язык. Однако у него есть определенная философия: динамическая типизация, TIMTOWTDI, краткость за счет неявных эффектов. Он не только позволяет, но поощряет всевозможную магию, благодаря чему хорошо подходит для одного круга задач, но плохо для другого. Например, писать однострочники для обработки всяких данных — сплошное удовольствие. Однако понимать код на Perl, написанный кем-то другим, а уж тем более его рефакторить — дело сложное и опасное.
Я также не сомневаюсь, что на Perl написано много полезных модулей и, возможно, даже качественных приложений. Авторы обычно отвечают — «просто нужно писать аккуратно, не использовать всякий сомнительный функционал, и все получится». Однако это говорит лишь о силе воли и навыке разработчика, а не о пригодности технологии.
Java и C++ существуют уже не меньше лет, устаревать не собираются, и о кардинальных несовместимостях между версиями я также не слышал. Сообщества крупнее и активнее, сил и денег вкладывается на порядок больше, сотрудников искать легче, инструменты совершеннее. Разве это не достаточная мотивация?
Bambr
В статье упомянуто несколько новых проектов, сделанных на perl. Это только самые крупные и/или известные. На самом деле таких проектов больше. Есть и примеры, когда сишные демоны спиливались и заменялись на асинхронную перловку с близкой производительностью (но более дешевой стоимостью поддержки). Так что не легаси единым.
RPG18
Тогда почему почту на go стали переводить?
shulyakovskiy
Потому, что это был их выбор. Но говорить о правильности/целесообразности и прочих аспектах такого выбора я бы не стал. Для таких решений взвешивается очень много за/против. И язык, как инструмент, это один из факторов, и как правило он не является решающим.
RPG18
Серьезно? Кому нужен язык Go и микросервисы — OH, MY CODE #18